Conséquence erreur d'écriture entre StrF et StrD

[SULREN]

Bonjour,
J’utilise PB depuis bon nombre d’années pour réaliser des codes qui me permettent de résoudre mes problèmes de calculs de trains d’engrenages, de réalisation d’outils de taillage d’engrenages, de traçage de cames de profil complexe, de résolution de systèmes d’équations non linéaires, etc.

C’est essentiellement du calcul scientifique, donc facile à programmer, et je n’utilise qu’une infime partie des ressources de BP. Voici pourquoi je n’interviens que rarement sur ce Forum, même à la rubrique débutant. Par contre j’ai besoin d’une grande vitesse d’exécution (calculs itératifs) et d’une très grande précision (par toujours obtenue dans les versions de PB antérieures à la version 4.4).

Je viens de faire dans un code une erreur de syntaxe par manque d'attention, que le correcteur syntaxique ne m’a pas signalée. Comme j’utilisais le Print d’un résultat de ce code pour l’introduire manuellement dans un autre code, j’aboutissais à une erreur inexplicable dont j’ai recherché la cause pendant une bonne heure. Le correcteur pourra t il signaler ce type d'erreur dans les versions futures? Merci.

Petit illustration en V 4.41 de cette erreur de syntaxe (grossière, il faut bien le reconnaître et détectable par une relecture du code).

Code : Tout sélectionner

OpenConsole()

;Déclaration variable en flottant double précision
a.d= 1.11111111
;Syntaxe correcte
av$=StrD(a,10): PrintN("Vraie valeur:     av=" +av$)
;Syntaxe incorrecte,en écrivant StrF au lieu de StrD
af$=StrF(a,10): Print("Valeur trompeuse: af=" +af$)

Input()
CloseConsole()
End

PS : Exemple d’outil que je réalise avec PB :
http://www.usinages.com/clonage-engrena ... 16143.html

[Backup]

il ne me semble pas qu'il y ait une erreur !
c'est a toi de faire attention a ce que tu veux obtenir comme résultat
et donc a prendre la bonne fonction en consequence !

comment veux tu que le compilateur sache ce que tu veux ...

de plus jongler entre strD() et strF() peut etre voulu par le programmeur ...

[SULREN]

Re,
Tout à fait d'accord sur le fait qu'il faut toujours être vigilant dans l'écriture du code et se relire avec attention, car le temps gagné à vouloir aller vite est perdu 10 fois en débuggage ensuite.

Par contre je ne vois pas pourquoi le programmeur aurait à jongler entre les deux. Si la variable a été déclarée en double précision elle doit être convertie en String par la commande Str double précision. D'ailleurs dans la doc on dit bien StrF pour flottant simple et StrD pour double. On ne donne pas de choix.
Y a t'il une différence sur le temps d'exécution? ou d'autres avantages à appliquer l'un plutôt que l'autre? Quant à l'encombrement, il est défini par le nombre de décimales indiqué.

Je voulais juste signaler la chose pour le cas où, car de mon côté j'ai décidé de travailler désormais toujours en double, d'une part parce que j'en ai en général besoin et d'autre part pour éviter les erreurs d'inattention.
Merci.

[SPH]

Ouai, dis donc, ca crains !
Mefiance sur les StrF

[Backup]

Si la variable a été déclarée en double précision elle doit être convertie en String par la commande Str double précision. .

non ce n'est pas implicite et ne dois pas le devenir !!

tu peux tres bien avoir envie de transformer un double en flottant
par ce moyen là justement

par exemple pour tronquer un quad pour une exploitation graphique

ça donnerai

Code : Tout sélectionner

a.d=467467467467467.5
b.f=ValF(StrF(a.d))

Debug Bin(a.d,#PB_Quad) ; valeur intact
Debug Bin(b.f,#PB_Float) ; valeur modifié par le StrF()

apres le 19 em bit B.f est mis a Zero
avant, il est identique a A.d

encore heureux qu'on puisse bidouiller avec les bits
pour faire des masks graphique, ou d'autre genre de tests
la manipulation du binaire est une priorité

[djes]

Je suis plus circonspect. Je trouve que les fonctions nommées telles que StrD et StrF qui servent à convertir un type en un autre devraient prévenir quand on ne leur fournit pas le type attendu, ou au moins émettre un warning à la compilation : ça aiderait bien à éviter ce genre de bug qui nous arrive à tous.

[SULREN]

Bonjour,
Je suis d’un trop bas niveau en programmation pour prendre position sur le fait qu’on puisse jongler avec StrF() et StrD() pour une même variable de format a.d

Deux remarques :
- Ce qui m’a quand même surpris dans la petite illustration que j’ai donnée, c’est que la variable :
a.d = 1.11111111 donne la chaîne de caractères
a$ = 1.1111111641 après traitement par StrF(a,10).
J’aurais mieux compris s’il y avait eu 099 à la place de 641
Avec StrD(a,10) c’est OK car cela donne a$=1.1111111100

- S’il s’agissait juste d’afficher la chaîne de caractères, la différence de valeur n’aurait pas été gênante en pratique. Il se trouve que dans le travail que je faisais l’erreur se cumulait à chaque pas de calcul, car j’utilisais les valeurs lues sur l’écran pour les introduire dans un autre applicatif de type boucle et évidemment au bout d’un certain nombre de pas l’erreur devenait lourde.
(Je testais ma méthode de calcul du périmètre de l’ellipse par intégration, afin de diviser ensuite ce périmètre en tronçons d’égale longueur, pour faire du taillage d’engrenages elliptiques. Il n’existe pas de formule de calcul exact du périmètre de l’ellipse, mais des approximations comme celle de Ramanujan

[Backup]

a$ = 1.1111111641 après traitement par StrF(a,10).

le mystere des retenues qui ont fait les choux gras de Hebdogiciel