Forum TI-Planet.org

Je le vois "souvent" sur des strings, mais après tout ça doit dépendre du type d'algo que l'on fait... sur des maths, probablement que c'est courant sur des listes en effet.

La "multiplication" de listes (ou de chaines de caractères) est un raccourci facile, mais je doute qu'il soit très utilisé, même parmi ceux qui adorent la syntaxe "Pythonnesque".

Malheureusement, c'est plus difficile à remplacer, pour au moins deux raisons :
1) La syntaxe permet aussi bien d'écrire 5*l que l*5 où l est une liste... et renvoie le même résultat dans chacun des deux cas. Cela oblige à tester le type des deux variables, si c'est le parseur qui fait le remplacement.
2) On est obligé de remplacer par une boucle (ou par les pseudo-boucles que sont les descriptions de liste dites en "compréhension").

Pour le moment je mets un warning si c'est utilise dans Xcas en mode Python, en conseillant d'utiliser concat(seq(list,n)) mais ca ne sera pas compatible avec du vrai Python, alors que le warning list1.extend(list2) en cas d'addition de listes va marcher pour les deux. S'il n'y a pas de version Python sans ecrire * je ne peux pas creer la meme fonction dans Xcas, dommage.

D'ailleurs, c'est bizarre... Comment un tableau de longueur N rempli de 0 et de 1 peut-il prendre moins de N bits en mémoire ? Pire encore, comment se fait-il qu'un tableau numpy de type booléen prenne toujours 80 octets, quelque soit sa taille ?

Par compression algorithmique. Parce que certaines parties se répètent. Il est plus efficace de les stocker en mémoire dans une structure de données est de les sortir quand on en a besoin...

rentech7289 a écrit:

D'ailleurs, c'est bizarre... Comment un tableau de longueur N rempli de 0 et de 1 peut-il prendre moins de N bits en mémoire ? Pire encore, comment se fait-il qu'un tableau numpy de type booléen prenne toujours 80 octets, quelque soit sa taille ?

Par compression algorithmique. Parce que certaines parties se répètent. Il est plus efficace de les stocker en mémoire dans une structure de données est de les sortir quand on en a besoin...

Ben non, il est bien sur impossible de stocker un tableau de booleens decrivant si un nombre est premier ou pas en 80 octets! J'ai explique la raison ici https://tiplanet.org/forum/viewtopic.php?f=100&t=21065#p227217

La mémoire d'un tableau numpy est obligatoirement dans l'espace de visibilité de python puisque c'est une bibliothèque python. Comment python peut-il récupérer de la mémoire allouée par une de ses bibliothèque s'il n'a aucune visibilité dessus ? En conséquence, le compilateur a toute latitude pour effectuer cette compression...
De plus le type booléen en python est défini comme suit:

Operations and built-in functions that have a Boolean result always return 0 or False for false and 1 or True for true, unless otherwise stated. (Important exception: the Boolean operations or and and always return one of their operands.)

https://docs.python.org/3/library/stdtypes.html#boolean-operations-and-or-not
section "Truth Value Testing", c'est-à-dire un entier qui n'occupe que deux octets. Boolean est un sous-type de int.
Le reste dépend de la structure de données est de la façon dont l'utilisateur y stocke les données. Ce qui veut dire entre autres que le compilateur ne peut pas améliorer le mauvais usage d'une structure de données inadaptée à une situation donnée. De là, la nécessité de bien choisir cette structure dès le départ...

rentech7289 a écrit:La mémoire d'un tableau numpy est obligatoirement dans l'espace de visibilité de python puisque c'est une bibliothèque python. Comment python peut-il récupérer de la mémoire allouée par une de ses bibliothèque s'il n'a aucune visibilité dessus ? En conséquence, le compilateur a toute latitude pour effectuer cette compression...

???
numpy utilise une librairie C (lapack ou une implementation compatible) pour faire des calculs sur les matrices/vecteurs, numpy est une interface Python/C, ecrire une bibliotheque faisant de l'algebre lineaire directement en Python serait bien trop inefficace. La memoire allouee pour un tableau est liberee par les fonctions de la librairie C mais n'est pas visible directement depuis Python. Ce qui est affiche par les fonctions de gestion de la memoire en Python, c'est uniquement la taille memoire de la structure C de CPython qui sert a faire l'interface avec le vrai tableau, gere par lapack.

Les bibliothèques en question sont Matlab et OpenBLAS et tout le code a été entièrement réécrit autour de ces différentes parties (numpy-1.21.1/numpy/core/include/numpy/ entre autres) en langage C. Ce qui ne veut pas dire que les fichiers C n'ont pas été réécrits lors de leur intégration à numpy. Sur le fond ça ne change absolument rien puisque tous les compilateurs utilisent ce type de compression...

Vous melangez.
Matlab n'est surement pas utilise dans un projet sous licence open-source vu que c'est un logiciel proprietaire. blas est la 1ere couche dans les libraires d'algebre lineaire (basic linear algebra), celle qui propose les operations de base (par exemple matrice*vecteur, ou matrice*matrice, avec des implementation plus ou moins efficaces, par exemple pour multiplier des matrices plus rapidement qu'en O(n^3)). Il faut ensuite une 2eme couche qui permet par exemple de faire le pivot de Gauss, calculer les vecteurs propres d'une matrice, ... cette couche est fournie par lapack (ou compatible). numpy est un module natif CPython qui fait l'interface entre l'interpreteur CPython et ces librairies C.

Il n'y a pas de compression quand on utilise des booleens, c'est juste une utilisation optimale de l'espace disponible: sur un octet on peut mettre 8 booleens, chacun sur un bit. Donc un tableau de booleen (par exemple cree avec le type std::vector<bool> de la libstdc++) occupe 32 fois moins de place qu'un tableau d'entiers 32 bits (int).

Vous melangez.

J'e reconnais mon erreur, la première bibliothèque s'appelle en fait Numeric. Toutes mes excuses pour cette erreur.

Il n'y a pas de compression quand on utilise des booleens, c'est juste une utilisation optimale de l'espace disponible: sur un octet on peut mettre 8 booleens, chacun sur un bit.

La compression algorithme ne s'attache pas à un type primitif en particulier mais à tout le code généré à la compilation, dans le cas de numpy, la source est:
https://numpy.org/doc/stable/reference/simd/simd-optimizations.html

sur un octet on peut mettre 8 booleens, chacun sur un bit

Un booleen n'est pas défini par un bit parce que cela impose d'avoir huit pointeurs sur un octet. Le premier problème avec un pointeur est de contenir une adresse mémoire (l'emplacement de l'octet) et non l'emplacement du bit dans l'octet, ce qui implique un second pointeur. Soit seize pointeurs sur un octet quand la moitié suffisent pour le type int (deux octets NDLR). Le second problème est que le microprocesseur doit amener le bit concerné à l'emplacement du bit 0 par décalage pour effectuer une comparaison logique avec la valeur 0 ou 1 en fonction du résultat recherché. Ce qui est une perte de temps.
Un autre problème que soulève ce fonctionnement est lié à la visibilité des données: quand le booléen n'est plus utilisé, il faut effacer les bits concernés dans les adresses mémoires avant d'effacer les pointeurs. Mais une telle opération ne peut être effectuée que manuellement, parce que aucun langage n'effectue d'opération bit à bit pour gérer un type de données primitif.
Je suis technicien en électronique de formation, avant d'avoir fait de l'informatique industrielle et je suis analyste-programmeur de métier. Je dirais que de ce point de vue je possède suffisamment d'expérience pour lire du code source et comprendre ce qui se passe dans l'ordinateur. Je ne remets pas en cause vos compétences mais je tiens surtout à remettre les bases de l'informatique à leur juste place.
Un compilateur fera tout pour ne pas avoir à recopier du code machine déjà écrit, c'est la version ultime de l'algorithme de Lemel-Ziv-Welch qui est à le principe de de tous les langages objets: réutiliser le code au maximum. Principe qui a été également repris par tous les systèmes d'exploitation. Le but étant toujours de ne pas recréer la roue à quelque niveau que ce soit...