Cassiopee Forum
CFD python modules
S'il vous plaît connectez vous ou Enregistrement'.
Date et heure en ce moment : mardi, 12 décembre 2017, 07:43

Cassiopee Forum :: Discussions, suggestions, bug report :: General :: [RESOLU] Discussion : pour ou contre les numpy string  ::
ChristopheBenoit
Administrator
Image


Messages: 169
[RESOLU] Discussion : pour ou contre les numpy string (jeudi, 17 mars 2011, 15:32)  
Bonjour,
Ce post est pour ouvrir la discussion :
Dans la norme, il est prévu que les valeurs de noeuds string
soient stockés en numpy string, c'est a dire en tableau de caracteres.
Avantage : ca permet de traiter les noeuds sans trop se poser de question
Inconvenient : c'est pas beau a l'affichage et c'est moins facile a manipuler pour un utilisateur qui n'aurait pas d'outil sous la main.

Doit on faire évoluer la norme python/CGNS pour accepter les 2 ou bien interdit on les strings dans l'arbre pour les champs de valeur?


Ip enregistré Statut: déconnecté Profil | Site Web 
Ordre des réponses: Première réponse en dernier :: Première réponse en premier
Sylvain Mouton
Junior Member
Image


Messages: 66
RE: Discussion : pour ou contre les numpy string (jeudi, 24 février 2011, 11:49)  
Pour ce qui est de l'affichage concrètement en utilisant XTree.Print() on obtient actuellement :
* avec un numpy string (tableau de caractère) :
['BC_on_SF236',array('UserDefined',dtype='|S1'),[4 sons],'BC_t']
* avec une string python
['BC_on_SF236','UserDefined',[4 sons],'BC_t']
Précisons qu'il serait très simple d'afficher les choses sous la forme 2 en modifiant légèrement la fonction Print()

Pour l'utilisateur les inconvénients du tableau de caractère sont :
* il faut utiliser systématiquement la fonction setValue() pour rentrer une valeur 'string' dans l'arbre (au lieu de node[1] = 'toto' il faut XTree.setValue(node,'toto') )
* pour bénéficier des fonctions standard de manipulation de string de python (comparaison, remplacement de caractère, etc.), il faut convertir la valeur en string par la commande : node[1].tostring()

Ces inconvénients me paraissent extrêmement légers et peu pénalisants. Si jamais il existe une bonne raison pour que la norme impose d'utiliser des tableaux de caractères numpy, alors je propose de ne pas modifier la norme. Il faudra alors prendre l'habitude des quelques manip ci-dessus et mettre à jour les outils pour qu'ils la respectent.

Ip enregistré Statut: déconnecté Profil | Site Web 
Benoit Rodriguez
Newbie
Image


Messages: 42
RE: Discussion : pour ou contre les numpy string (lundi, 28 février 2011, 19:05)  
De mon point de vue, je préfère l'homogénéité dans les valeurs, soit : "toutes les valeurs des numpy". Après, on peut proposer que la norme présente quelques exemples de fonctions pour créer les noeuds à valeurs des caractères.

Remarque:

La norme ne met pas de restriction sur le type de buffer mémoire pour les numpy (C ou F). De mon point de vue, il serait plus intéressant que Cassiopee supporte les 2 types de buffer même si cela veut dire faire une copie dans le cas de buffer 'C' (avec un warning si cela semble nécessaire).


PS :
Pour moi "XTree" est juste un module interne DAAP et il ne doit pas entrée en compte dans nos discussions sur la norme encore moins sur le forum Cassiopée







Ip enregistré Statut: déconnecté Profil | Site Web 
ChristopheBenoit
Administrator
Image


Messages: 169
RE: Discussion : pour ou contre les numpy string (jeudi, 10 mars 2011, 16:38)  
Bonjour,
Pour etre donc conforme à la norme, nous avons passé toutes les valeurs stockées dans les noeuds en numpy. C'est vrai pour les float, int, ou string.

Ceci impacte:
- le noeud version
- les noeuds connectivités ou le nom du bloc donneur est stocké,
- les noeuds CL où le nom de la CL est stocké.
Pour l'essentiel.

Merci de reporter toute incompatibilité.


Ip enregistré Statut: déconnecté Profil | Site Web 
Benoit Rodriguez
Newbie
Image


Messages: 42
RE: Discussion : pour ou contre les numpy string (jeudi, 10 mars 2011, 16:54)  
Merci pour ce travail.



Ip enregistré Statut: déconnecté Profil | Site Web 
Nouvelle discussion - Discussion barrée, pas de réponse possible

Software PBLang 4.65 © 2002-2003 by Martin Senftleben
Image