Discussion :

[NairodDorian]

Un itoa c'est vite réécrit et les résultats sont corrects.
Sinon montre moi où y a des erreurs.

[Jean-Marc.Bourguet]

Un itoa c'est vite réécrit

Je suis prêt à parier que ton premier essai sera tout aussi erroné.

et les résultats sont corrects.
Sinon montre moi où y a des erreurs.

Ce qui saute aux yeux c'est que le résultat est faux pour toute valeur hors de l'intervalle MIN_INT, MAX_INT.

[NairodDorian]

Je suis prêt à parier que ton premier essai sera tout aussi erroné.

Faut vraiment être NUL pour ne pas réussir du premier coup une fonction aussi SIMPLE !!! Je la code à chaque fois pour mes projets perso car j'exclu tjr la crt de mes projets.

Ce qui saute aux yeux c'est que le résultat est faux pour toute valeur hors de l'intervalle MIN_INT, MAX_INT.

D'où mon message : Vérifiez que la valeur de double tiens dans un 'int' !

[darrylsite]

Personnellement, je suis curieux de voir la qualité et la fiabilité du code que tu pourrais écrire "en juste quelques minutes" pour convertir un double en une chaine de caractères sachant que cela doit s'exécuter de manière fiable et performante sur un micro-controleur.

Alors relèves tu le défi (puisque c'est si trivial) ?

Tu te chronomètres et nous poste le code ?

on peut tres bien coder ce code en juste quelques minutes. Ne me dite pas qu' il faut des jours pour pouvoir ecrire un code pareil. Personnellement, je l' avait dejà fait (mais en pascal) qu' on je debutais en programmation.
Et je ne vois pas en quoi il serait necessaire d' engager un prof de math, car tout ce qu' il faut c' est d' avoir un peu d' imagination.

[Jean-Marc.Bourguet]

Faut vraiment être NUL pour ne pas réussir du premier coup une fonction aussi SIMPLE !!! Je la code à chaque fois pour mes projets perso car j'exclu tjr la crt de mes projets.

J'attends.

D'où mon message : Vérifiez que la valeur de double tiens dans un 'int' !

Désolé, je n'ai lu que le dernier de tes 3 messages consécutifs. Les crashs pour les valeurs dans (-1, 0) -- la deuxième source de problèmes que j'ai vu -- tu prévenais aussi?

[NairodDorian]

Désolé, je n'ai lu que le dernier de tes 3 messages consécutifs. Les crashs pour les valeurs dans (-1, 0) -- la deuxième source de problèmes que j'ai vu -- tu prévenais aussi?

Lorsque j'ai posté ma seconde version j'ai oublié de poster la "correction" que j'avais apporté à length. Désolé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int length(int v) {
	return v == 0 ? 1 : log10(fabs(v)) + 1.0;
}

J'en profite pour apporter une légère retouche à la fonction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
void sd2str_v2(char *lpszDest, double value) {
	char *pDst;
	int i, j;
	pDst = lpszDest;
	i = value;
	value -= i;
	itoa(i, pDst, 10);
	if (i < 0.0) { pDst++; value = -value; }
	pDst += length(i);
	*pDst++ = ',';
	for (j = 0; j < 17; ++j) {
		value *= 10;
		i = value;
		value -= i;
		if (i < 0.0) i = -i;
		*pDst++ = '0' + i;
	}
	*pDst = 0;
}

Doit allé bon comme ça.

J'attends.

Ben tu vas pouvoir attendre longtemps. Je t'ai dit que je l'ai déjà fait pour mes projets perso car je vire la CRT systématiquement. Je n'ai rien à te prouver, dommage si tu reste dubitatif sur ce que j'affirme.

[Jean-Marc.Bourguet]

Je n'ai rien à te prouver, dommage si tu reste dubitatif sur ce que j'affirme.

Ben, ce que tu montres n'est pas très concluant... tu as mis plus que quelques minutes pour ne pas résoudre un problème bien simplifié (ne pas traiter toutes les valeurs des doubles) par rapport au problème de départ (il y a au moins toujours un problème d'arrondi). Sans compter que si on veut une fonction qui n'a pas de contrôle sur le format, on va plutôt aller vers l'équivalent de %g ou même un format demandant le nombre minimal de décimales pour permettre une lecture sans perte d'information.

Mais bon, ce n'est pas moi qui ai prétendu que c'était faisable en quelques minutes. Les petits problèmes de gestion de précision qui vont s'inviter si on veut un résultat correctement arrondi nécessite une analyse qui nécessite de comprendre les flottants mieux que la moyenne des programmeurs, et un peu de temps aussi.

Quant aux entiers, ce n'est pas tellement compliqué, mais le traitement de INT_MIN va poser problème aux personnes les plus naïves. Que tu n'y ait pas fait allusion me laisse craindre que tu n'en étais pas conscient.

[NairodDorian]

tu as mis plus que quelques minutes pour ne pas résoudre un problème bien simplifié (ne pas traiter toutes les valeurs des doubles) par rapport au problème de départ (il y a au moins toujours un problème d'arrondi). Sans compter que si on veut une fonction qui n'a pas de contrôle sur le format, on va plutôt aller vers l'équivalent de %g ou même un format demandant le nombre minimal de décimales pour permettre une lecture sans perte d'information.

Lorsque j'ai posé mon premier code je n'ai réfléchis qu'une minute. (ça à son importance )
Il faut savoir aussi que les processeurs x86 travail avec des double (64 bits) par défaut sinon il faut modifié le champ PC (Precision Control bit 8 et 9).
Le contrôle de l'arrondi (RC) peut-être aussi modifié en modifiant le bit 10 et 11.
Bref tout ça pour dire que c'est le genre de fonction qui doit-être programmé en ASM, la faire en C revient à faire de la bidouille car on n'a pas un contrôle total et surtout il ne faut pas s'attendre à qqch de parfait beaucoup de nombres ne sont pas représentables de manière exacte.

Quant aux entiers, ce n'est pas tellement compliqué, mais le traitement de INT_MIN va poser problème aux personnes les plus naïves.

La fonction assure un fonctionnement sous certaines conditions c'est au programmeur de vérifier que tout va bien se passé à l'exécution comme quand tu programmes en ASM sinon tu vas avoir des exceptions ou alors l'exécution ne sera pas garanti. C'est l'appelant qui doit toujours être prudent jamais celui qui se contente de fourni un travail.

[dapounet]

Il faut savoir aussi que les processeurs x86 travail avec des double (64 bits) par défaut sinon il faut modifié le champ PC (Precision Control bit 8 et 9).

Je n'ai pas compris ce que ça vient faire dans l'histoire mais par défaut c'est sur 80 bits donc plutôt long double (la mantisse fait 64 bits par contre).

La fonction assure un fonctionnement sous certaines conditions c'est au programmeur de vérifier que tout va bien se passé à l'exécution comme quand tu programmes en ASM sinon tu vas avoir des exceptions ou alors l'exécution ne sera pas garanti. C'est l'appelant qui doit toujours être prudent jamais celui qui se contente de fourni un travail.

"It's not a bug, it's a feature."

[Vincent Rogier]

on peut tres bien coder ce code en juste quelques minutes

Non, non et encore non dans le cadre d'une fonction qui doit être exécutée dans un micorocontroleur et doit donc être fiable à 100 % et cela pour toute la plage de valeurs du double.

Certes le principe d'une telle fonction est relativement simple mais la production d'une fonction efficace et fiable ne prends pas 1 ou 2 minutes mais beacoup plus entre le temps de code, tests et améliorations.

[NairodDorian]

Je n'ai pas compris ce que ça vient faire dans l'histoire mais par défaut c'est sur 80 bits donc plutôt long double (la mantisse fait 64 bits par contre).

C'est ce que je voulais mais le l'ai mal exprimé.

Il faut savoir aussi que les processeurs x86 travail avec des double (64 bits)

Fallait comprendre 64 bits pour la précision.

[Jean-Marc.Bourguet]

Lorsque j'ai posé mon premier code je n'ai réfléchis qu'une minute. (ça à son importance )

Oui... c'est toi qui a écrit que ça suffisait, pas moi. Vu que j'ai déjà fait l'exercice en tentant de le faire correctement, je sais qu'il est plus compliqué qu'il n'y en a l'air.

Il faut savoir aussi que les processeurs x86 travail avec des double (64 bits) par défaut sinon il faut modifié le champ PC (Precision Control bit 8 et 9).
Le contrôle de l'arrondi (RC) peut-être aussi modifié en modifiant le bit 10 et 11.
Bref tout ça pour dire que c'est le genre de fonction qui doit-être programmé en ASM, la faire en C revient à faire de la bidouille car on n'a pas un contrôle total et surtout il ne faut pas s'attendre à qqch de parfait beaucoup de nombres ne sont pas représentables de manière exacte

.

Mince alors... je l'ai fait sans assembleur. Pire, je ne vois pas en quoi l'assembleur aide beaucoup -- enfin, un peu les perfs du calcul entier multiprécision qui est nécessaire, mais les drapeaux de controles de la FPU n'aident pas beaucoup pour cela.

La fonction assure un fonctionnement sous certaines conditions c'est au programmeur de vérifier que tout va bien se passé à l'exécution comme quand tu programmes en ASM sinon tu vas avoir des exceptions ou alors l'exécution ne sera pas garanti. C'est l'appelant qui doit toujours être prudent jamais celui qui se contente de fourni un travail.

Tu as l'air de bien aimer de changer les specs quand ça te convient toi.

[NairodDorian]

Tu vis dans un autre monde si tu crois que c'est la fonction qui doit te torché les fesses pcq t'as fais de travers.

[Jean-Marc.Bourguet]

Tu vis dans un autre monde si tu crois que c'est la fonction qui doit te torché les fesses pcq t'as fais de travers.

C'est quoi faire de travers? Utiliser des doubles plus grands que INT_MAX, vouloir formater un entier qui vaut INT_MIN ou désirer que ce formatage soit correctement arrondi?

[Vincent Rogier]

Bon, la discussion peut très bien continuer longtemps comme ca...

@NairodDorian

En relisant le topic, on peut voir que la fonction que tu pouvais en coder 'en 1 minute" :

• a pris plus qu'une 1 minute à écrire à moins que tu n'écrives 20 mots à la seconde
• tu a du poster plusieurs exemplaires du code
• ce code est toujours pas exploitable car entre autre il ne gère pas toute les valeurs possible d'un double...

Donc, au final, au risque de me répéter, ce genre de fonction ne se code pas en "1 minute" car le temps total comprends la conception, le codage, les tests, les corrections, tuning...
Cela sachant que cela doit tourner sans faille sur un micro-controleur (donc faire des tests ultra complets, donc du temps....)
Au final le temps pour coder ce genre de fonction n'est pas 'quelque minutes'
ET cela n'a rien à voir avec la complexité de la fonction...
Du code de qualité prends toujours du temps à produire.

Tout çà pour dire que arriver dans un topic et dire :

"Fais le à main, il ne faut que quelque minutes...", ben c'est archi faux pour un développeur consciencieux...

[Obsidian]

"Fais le à main, il ne faut que quelque minutes...", ben c'est archi faux pour un développeur consciencieux...

Hmm. Ça dépend. Une minute, c'est exagéré, bien sûr, mais ce n'est pas pour autant que ça ne vaut pas le coup, parfois, de faire ce genre de fonctions de conversion soi-même. Et là, encore, on parle d'un double, mais alors sur les int, ça peut devenir des oneliners.

L'exercice en lui-même est très intéressant d'ailleurs.