Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Découper un tableau

15 réponses
Avatar
ReM
Bonjour,

Je cherche à découper un tableau en n colonnes avec le choix du sens.

Exemple :
t = [1,2,3,4,5,6,7,8]

t1, t2, t3 = split_tab( t, n = 3, sens = "HORIZONTAL" )
#Résultat :
t1 = [1,2,3]
t2 = [4,5,6]
t3 = [7,8,None]

t1, t2, t3 = split_tab( t, n = 3, sens = "VERTICAL" )
#Résultat :
t1 = [1,4,7]
t2 = [2,5,8]
t3 = [3,6,None]

Quelqu'un aurait il déjà fait ça ?
Merci ;o)

5 réponses

1 2
Avatar
Alexandre Fayolle
Le 28-06-2006, ReM 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]

t1, t2, t3 = split_tab( t, n = 3, sens = "VERTICAL" )
#Résultat :
assert t1 == [1,4,7]
assert t2 == [2,5,8]
assert t3 == [3,6,None]
except AssertionError, exc:
print "Failure", exc
except Exception, exc:
print "Error", exc
else:
print 'OK'


--
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

Avatar
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
Avatar
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

Avatar
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
Avatar
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

1 2