Je cherche à découper un tableau en n colonnes avec le choix du sens.
D'autres ont répondu, je propose "ma" version pour ne pas être en reste, qui utilise Numeric (mais ça marche aussi avec numarray ou numpy), qui fait des choses très bien dès qu'on veut manipuler des tableaux de données :
# -*- coding: iso-8859-15 import Numeric as N
def split_tab(values, n, sens='HORIZONTAL'): values = values + [None] * (n - len(values)%n) values = N.reshape(values, (n, -1)) if sens == 'VERTICAL': values = N.transpose(values) return values.tolist()
# Test de validation t = [1,2,3,4,5,6,7,8] try: t1, t2, t3 = split_tab( t, n = 3, sens = "HORIZONTAL" ) #Résultat : assert t1 == [1,2,3] assert t2 == [4,5,6] assert t3 == [7,8,None]
-- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Python et calcul scientifique: http://www.logilab.fr/science
Le 28-06-2006, ReM <rmREMOVE@advanceupREMOVE.com> nous disait:
Bonjour,
Je cherche à découper un tableau en n colonnes avec le choix du sens.
D'autres ont répondu, je propose "ma" version pour ne pas être en reste,
qui utilise Numeric (mais ça marche aussi avec numarray ou numpy), qui
fait des choses très bien dès qu'on veut manipuler des tableaux de
données :
# -*- coding: iso-8859-15
import Numeric as N
def split_tab(values, n, sens='HORIZONTAL'):
values = values + [None] * (n - len(values)%n)
values = N.reshape(values, (n, -1))
if sens == 'VERTICAL':
values = N.transpose(values)
return values.tolist()
# Test de validation
t = [1,2,3,4,5,6,7,8]
try:
t1, t2, t3 = split_tab( t, n = 3, sens = "HORIZONTAL" )
#Résultat :
assert t1 == [1,2,3]
assert t2 == [4,5,6]
assert t3 == [7,8,None]
Je cherche à découper un tableau en n colonnes avec le choix du sens.
D'autres ont répondu, je propose "ma" version pour ne pas être en reste, qui utilise Numeric (mais ça marche aussi avec numarray ou numpy), qui fait des choses très bien dès qu'on veut manipuler des tableaux de données :
# -*- coding: iso-8859-15 import Numeric as N
def split_tab(values, n, sens='HORIZONTAL'): values = values + [None] * (n - len(values)%n) values = N.reshape(values, (n, -1)) if sens == 'VERTICAL': values = N.transpose(values) return values.tolist()
# Test de validation t = [1,2,3,4,5,6,7,8] try: t1, t2, t3 = split_tab( t, n = 3, sens = "HORIZONTAL" ) #Résultat : assert t1 == [1,2,3] assert t2 == [4,5,6] assert t3 == [7,8,None]
-- Alexandre Fayolle LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Python et calcul scientifique: http://www.logilab.fr/science
Michel Claveau
Bonjour !
Je me doutais que ce genre de module aurit des fonctions/méthodes bien adaptées.
Ceci dit, entre Numarray, Numeric, SciPy, NumPy ; avec l'un succédant, ou dérivant, à/de l'autre, mais qui est en train d'être remplacé par un troisième, sans reprendre toutes les fonctionnalités, etc. On ne sait plus trop où on en est, ni ce qui va rester...
-- @-salutations
Michel Claveau
Bonjour !
Je me doutais que ce genre de module aurit des fonctions/méthodes bien
adaptées.
Ceci dit, entre Numarray, Numeric, SciPy, NumPy ; avec l'un succédant,
ou dérivant, à/de l'autre, mais qui est en train d'être remplacé par un
troisième, sans reprendre toutes les fonctionnalités, etc. On ne sait
plus trop où on en est, ni ce qui va rester...
Je me doutais que ce genre de module aurit des fonctions/méthodes bien adaptées.
Ceci dit, entre Numarray, Numeric, SciPy, NumPy ; avec l'un succédant, ou dérivant, à/de l'autre, mais qui est en train d'être remplacé par un troisième, sans reprendre toutes les fonctionnalités, etc. On ne sait plus trop où on en est, ni ce qui va rester...
-- @-salutations
Michel Claveau
Nicolas Limare
Ceci dit, entre Numarray, Numeric, SciPy, NumPy ; avec l'un succédant, ou dérivant, à/de l'autre, mais qui est en train d'être remplacé par un troisième, sans reprendre toutes les fonctionnalités, etc. On ne sait plus trop où on en est, ni ce qui va rester...
Numeric est mort (d'un point de vue developpement) Numarray va mourrir dans un delai reduit (d'apres ses developpeurs) NumPy est bien vivant, construit sur les deux precedents, et compatible. SciPy est basé sur NumPy.
NumPy gère toutes les opérations sur les tableaux en n dimensions. Les données, quoi. SciPy est varié, stats, integration, traitement d'images, etc etc., et il utilise naturellement NumPy pour ses données.
Pour moi, c'est clair.
-> http://www.scipy.org/
A+
-- Nico
Ceci dit, entre Numarray, Numeric, SciPy, NumPy ; avec l'un succédant,
ou dérivant, à/de l'autre, mais qui est en train d'être remplacé par un
troisième, sans reprendre toutes les fonctionnalités, etc. On ne sait
plus trop où on en est, ni ce qui va rester...
Numeric est mort (d'un point de vue developpement)
Numarray va mourrir dans un delai reduit (d'apres ses developpeurs)
NumPy est bien vivant, construit sur les deux precedents, et compatible.
SciPy est basé sur NumPy.
NumPy gère toutes les opérations sur les tableaux en n dimensions. Les
données, quoi. SciPy est varié, stats, integration, traitement d'images,
etc etc., et il utilise naturellement NumPy pour ses données.
Ceci dit, entre Numarray, Numeric, SciPy, NumPy ; avec l'un succédant, ou dérivant, à/de l'autre, mais qui est en train d'être remplacé par un troisième, sans reprendre toutes les fonctionnalités, etc. On ne sait plus trop où on en est, ni ce qui va rester...
Numeric est mort (d'un point de vue developpement) Numarray va mourrir dans un delai reduit (d'apres ses developpeurs) NumPy est bien vivant, construit sur les deux precedents, et compatible. SciPy est basé sur NumPy.
NumPy gère toutes les opérations sur les tableaux en n dimensions. Les données, quoi. SciPy est varié, stats, integration, traitement d'images, etc etc., et il utilise naturellement NumPy pour ses données.
Pour moi, c'est clair.
-> http://www.scipy.org/
A+
-- Nico
Michel Claveau
Bonjour !
Je comprend ton point de vue.
Néanmoins, NumPy, même s'il est plus complet que les autres, ne les remplace pas complètement (ou pas encore ?).
Ainsi, un import numpy as numeric fonctionne, disons, rarement.
Idem avec numarray.
Alors, il faut rentrer dans les modules, pour se taper, à la main, de nombreuses adaptations. Donc, si l'on doit se plonger dans les sources de tous les modules que l'on utilise, cela enlève beaucoup d'intérêt à l'utilisation de librairies/modules tiers, et réduit les avantages de la programmation modulaire que permet Python.
Et, quand on voit que la dernière version de numarray date de février 2006, on se demande si cette librairie va vraiment mourir dans un délai réduit. D'autant plus que de nombreux exemples/tutoriaux basés sur ce module ne sont toujours pas obsolètes.
Alors, certes, pour l'avenir, il vaut mieux miser sur numpy. Mais, sauf à mépriser les développements réalisés chez les clients/utilisateurs, on est bien obligés d'utiliser les différents modules.
Dernier point, les rapports entre numpy et SciPy sont limités au simple mot "compatible".
Je pense que, si numpy est intégré un jour à la librairie standard de Python, cela éclairira beaucoup mieux les choses.
-- @-salutations
Michel Claveau
Bonjour !
Je comprend ton point de vue.
Néanmoins, NumPy, même s'il est plus complet que les autres, ne les
remplace pas complètement (ou pas encore ?).
Ainsi, un import numpy as numeric fonctionne, disons, rarement.
Idem avec numarray.
Alors, il faut rentrer dans les modules, pour se taper, à la main, de
nombreuses adaptations.
Donc, si l'on doit se plonger dans les sources de tous les modules que
l'on utilise, cela enlève beaucoup d'intérêt à l'utilisation de
librairies/modules tiers, et réduit les avantages de la programmation
modulaire que permet Python.
Et, quand on voit que la dernière version de numarray date de février
2006, on se demande si cette librairie va vraiment mourir dans un délai
réduit.
D'autant plus que de nombreux exemples/tutoriaux basés sur ce module ne
sont toujours pas obsolètes.
Alors, certes, pour l'avenir, il vaut mieux miser sur numpy. Mais, sauf
à mépriser les développements réalisés chez les clients/utilisateurs,
on est bien obligés d'utiliser les différents modules.
Dernier point, les rapports entre numpy et SciPy sont limités au simple
mot "compatible".
Je pense que, si numpy est intégré un jour à la librairie standard de
Python, cela éclairira beaucoup mieux les choses.
Néanmoins, NumPy, même s'il est plus complet que les autres, ne les remplace pas complètement (ou pas encore ?).
Ainsi, un import numpy as numeric fonctionne, disons, rarement.
Idem avec numarray.
Alors, il faut rentrer dans les modules, pour se taper, à la main, de nombreuses adaptations. Donc, si l'on doit se plonger dans les sources de tous les modules que l'on utilise, cela enlève beaucoup d'intérêt à l'utilisation de librairies/modules tiers, et réduit les avantages de la programmation modulaire que permet Python.
Et, quand on voit que la dernière version de numarray date de février 2006, on se demande si cette librairie va vraiment mourir dans un délai réduit. D'autant plus que de nombreux exemples/tutoriaux basés sur ce module ne sont toujours pas obsolètes.
Alors, certes, pour l'avenir, il vaut mieux miser sur numpy. Mais, sauf à mépriser les développements réalisés chez les clients/utilisateurs, on est bien obligés d'utiliser les différents modules.
Dernier point, les rapports entre numpy et SciPy sont limités au simple mot "compatible".
Je pense que, si numpy est intégré un jour à la librairie standard de Python, cela éclairira beaucoup mieux les choses.
-- @-salutations
Michel Claveau
Nicolas Limare
Bonjour,
Ainsi, un import numpy as numeric fonctionne, disons, rarement. Idem avec numarray.
Alors, il faut rentrer dans les modules, pour se taper, à la main, de nombreuses adaptations. Donc, si l'on doit se plonger dans les sources de tous les modules que l'on utilise, cela enlève beaucoup d'intérêt à l'utilisation de librairies/modules tiers, et réduit les avantages de la programmation modulaire que permet Python.
Effectivement. Je n'ai que le point de vue de quelqu'un qui a commencé à s'y mettre il y a quelques mois, et pour qui la question di choix ne s'est pas vraiment posée, vu que tout ce dont j'ai besoin est dans SciPy
Et, quand on voit que la dernière version de numarray date de février 2006, on se demande si cette librairie va vraiment mourir dans un délai réduit. D'autant plus que de nombreux exemples/tutoriaux basés sur ce module ne sont toujours pas obsolètes.
Oui. Et la politique de documentation de Scipy, qui consiste à diffuser la source essentielle de doc, à savoir le manuel rédigé par le développeur principal, sous une licence temporairement restreinte et à accès payant, n'aide pas vraiment.
Dernier point, les rapports entre numpy et SciPy sont limités au simple mot "compatible".
?? Dire que SciPy utilise NumPy (ex-SciPY-core) pour ses données es-il une erreur? Tes éclaircissements m'intéressent, vraiment.
-- Nico
Bonjour,
Ainsi, un import numpy as numeric fonctionne, disons, rarement.
Idem avec numarray.
Alors, il faut rentrer dans les modules, pour se taper, à la main, de
nombreuses adaptations.
Donc, si l'on doit se plonger dans les sources de tous les modules que
l'on utilise, cela enlève beaucoup d'intérêt à l'utilisation de
librairies/modules tiers, et réduit les avantages de la programmation
modulaire que permet Python.
Effectivement. Je n'ai que le point de vue de quelqu'un qui a commencé à
s'y mettre il y a quelques mois, et pour qui la question di choix ne
s'est pas vraiment posée, vu que tout ce dont j'ai besoin est dans SciPy
Et, quand on voit que la dernière version de numarray date de février
2006, on se demande si cette librairie va vraiment mourir dans un délai
réduit.
D'autant plus que de nombreux exemples/tutoriaux basés sur ce module ne
sont toujours pas obsolètes.
Oui. Et la politique de documentation de Scipy, qui consiste à diffuser
la source essentielle de doc, à savoir le manuel rédigé par le
développeur principal, sous une licence temporairement restreinte et à
accès payant, n'aide pas vraiment.
Dernier point, les rapports entre numpy et SciPy sont limités au simple
mot "compatible".
?? Dire que SciPy utilise NumPy (ex-SciPY-core) pour ses données es-il
une erreur? Tes éclaircissements m'intéressent, vraiment.
Ainsi, un import numpy as numeric fonctionne, disons, rarement. Idem avec numarray.
Alors, il faut rentrer dans les modules, pour se taper, à la main, de nombreuses adaptations. Donc, si l'on doit se plonger dans les sources de tous les modules que l'on utilise, cela enlève beaucoup d'intérêt à l'utilisation de librairies/modules tiers, et réduit les avantages de la programmation modulaire que permet Python.
Effectivement. Je n'ai que le point de vue de quelqu'un qui a commencé à s'y mettre il y a quelques mois, et pour qui la question di choix ne s'est pas vraiment posée, vu que tout ce dont j'ai besoin est dans SciPy
Et, quand on voit que la dernière version de numarray date de février 2006, on se demande si cette librairie va vraiment mourir dans un délai réduit. D'autant plus que de nombreux exemples/tutoriaux basés sur ce module ne sont toujours pas obsolètes.
Oui. Et la politique de documentation de Scipy, qui consiste à diffuser la source essentielle de doc, à savoir le manuel rédigé par le développeur principal, sous une licence temporairement restreinte et à accès payant, n'aide pas vraiment.
Dernier point, les rapports entre numpy et SciPy sont limités au simple mot "compatible".
?? Dire que SciPy utilise NumPy (ex-SciPY-core) pour ses données es-il une erreur? Tes éclaircissements m'intéressent, vraiment.