Re: Fonctions non cycliques
Olivier Miakinen
Le 17/07/2009 20:51, Jean-marc m'a rï¿œpondu :
>
>> while (true) {
>> allume_led(r, v, b);
>>
>> if (inc_b) {
>> if (b < 255) { b++; continue; }
>> else inc_b = false;
>> } else {
>> if (b > 0) { b--; continue; }
>> else inc_b = true;
>> }
>>
>> if (inc_v) {
>> if (v < 255) { v++; continue; }
>> else inc_v = false;
>> } else {
>> if (v > 0) { v--; continue; }
>> else inc_v = true;
>> }
>>
>> if (r < 255) { r++; continue; }
>> else break;
>> }
>
> 5 fois l'instruction "continue" en 22 lignes de code.
Si tu veux, je peux le refaire sans while ni continue ni break, et avec
cinq fois l'instruction goto. ;-)
> Dijkstra a du aussi se retourner 5 fois dans sa tombe :o))
On peut bien sï¿œr le programmer autrement, mais le micro-contrï¿œleur de
Jean-Christophe semble limitￜ d'aprￜs ce qu'il expliquait, alors j'ai
essayￜ de faire le plus basique possible.
Cela dit, je veux bien que tu donnes la version la plus propre possible
selon Dijkstra, et du coup je fais suivre vers fr.comp.algorithmes (ce
que j'aurais dￜ faire bien plus tￜt).
Jean-marc
> Bonjour,
>>
>> 5 fois l'instruction "continue" en 22 lignes de code.
>
> Si tu veux, je peux le refaire sans while ni continue ni break, et
> avec cinq fois l'instruction goto. ;-)
Ce qui serait �quivalent, continue �tant un goto qui ne dit
pas son nom :-)
>> Dijkstra a du aussi se retourner 5 fois dans sa tombe :o))
>
> On peut bien s�r le programmer autrement, mais le micro-contr�leur de
> Jean-Christophe semble limit� d'apr�s ce qu'il expliquait, alors j'ai
> essay� de faire le plus basique possible.
J'avais bien compris ;-) C'�tait une innocente plaisanterie et un
simple clin d'oeil en r�f�rence au "Goto considered harmful" ...
--
Jean-marc
Olivier Miakinen
>>>
>>> 5 fois l'instruction "continue" en 22 lignes de code.
>>
>> Si tu veux, je peux le refaire sans while ni continue ni break, et
>> avec cinq fois l'instruction goto. ;-)
>
> pas son nom :-)
Ah non ! Pour un goto, on commence par positionner quelque part une
ￜtiquette, ￜ laquelle on peut se brancher par goto d'ￜ peu prￜs
n'importe oￜ. Ce n'est pas le cas de continue ou de break, qui ne
positionnent aucune ï¿œtiquette, et qui sont donc beaucoup moins
imprï¿œvisibles.
>>> Dijkstra a du aussi se retourner 5 fois dans sa tombe :o))
>>
>> On peut bien sï¿œr le programmer autrement, mais le micro-contrï¿œleur de
>> Jean-Christophe semble limitￜ d'aprￜs ce qu'il expliquait, alors j'ai
>> essayￜ de faire le plus basique possible.
>
> J'avais bien compris ;-) C'ï¿œtait une innocente plaisanterie et un
> simple clin d'oeil en rï¿œfï¿œrence au "Goto considered harmful" ...
Malgrￜ tout, j'ￜtais sￜrieux en te demandant une version qui soit
ￜ algorithmiquement plus correcte ￜ. J'aimerais bien savoir comment tu
l'ï¿œcrirais.
Tiens, un autre exemple. Soit le code suivant :
-----
for (int n = 0; n < 100; n++) {
int r1 = f1(n);
if (r1 < 0) {
Error("f1", n, r1);
continue;
}
int r2 = f2(r1,n);
if (r2 < 0) {
Error("f2", n, r2);
continue;
}
int r3 = f3(r2,n);
if (r3 < 0) {
Error("f3", n, r3);
continue;
}
...
/* une dizaine de tests plus tard */
Ok(n);
}
-----
Pour ï¿œviter les "continue", certains l'ï¿œcrivent comme ï¿œa :
-----
for (int n = 0; n < 100; n++) {
int r1 = f1(n);
if (r1 < 0) {
Error("f1", n, r1);
} else {
int r2 = f2(r1,n);
if (r2 < 0) {
Error("f2", n, r2);
} else {
int r3 = f3(r2,n);
if (r3 < 0) {
Error("f3", n, r3);
} else {
...
} else {
/* une dizaine de tests plus tard */
Ok(n);
}
...
}
}
}
}
-----
Personnellement, je trouve ï¿œa horrible et parfaitement illisible, alors
que la premiￜre version est trￜs facile ￜ suivre, sans complexitￜ
inutile. Quel est ton avis ? Y a-t-il une mï¿œthode plus lisible tout en
ï¿œvitant les "continue" que tu juges diaboliques ?
--
Olivier Miakinen
Jean-marc
>
> Personnellement, je trouve �a horrible et parfaitement illisible,
> alors que la premi�re version est tr�s facile � suivre, sans
> complexit� inutile. Quel est ton avis ? Y a-t-il une m�thode plus
> lisible tout en �vitant les "continue" que tu juges diaboliques ?
Je ne les juge en aucun cas diaboliques; Personnellement j'�cris aussi
comme tu l'as fait avec les continue. Je trouve �galement parfaitement
illisibles les indentations � rallonge. L'important c'est la lisibilit�
et la maintenabilit� du code; je ne souscris absolument pas aux
opinions talibanesques des pourfendeurs du "goto" ou du "continue"; elles
�manent bien souvent de gens dogmatiques, avec tout le "bien" que je
pense de ce genre d'individus :-)
--
Jean-marc
Olivier Miakinen
>
> [...] L'important c'est la lisibilitￜ
> et la maintenabilitￜ du code; [...]
Ah, nous sommes donc d'accord sur tout (y compris ce que je ne cite
pas). Tu m'en vois rassurￜ. ;-)
--
Olivier Miakinen
Olivier Miakinen
>
> Euh ... je reiterer ma question postee sur <fr.sci.maths> :
Quant � moi je fais suivre la question vers fr.comp.algorithmes.
> Comment trouver des triplets de fonctions r(t) v(t) b(t)
> dont le point representatif ne repasse pas par les memes
> points de l'espace, tout en le parcourant entierement ?
J'avais cru que zwim t'avait donn� la r�ponse dans un des liens
pr�c�dents (mais je n'avais pas eu le courage de le lire, �tant tout
en estranger).
> [...]
>
> Existe t'il une methode generique permettant
> de trouver de tels ensembles de 3 fonctions ?
Oui, forc�ment. Il suffit de prendre la 8e �tape de la construction
de la courbe de Hilbert 3D, et d'associer � chaque nombre entre 0 et
16777215 les trois coordonn�es du point correspondant.
Cf. <http://www.mathcurve.com/fractals/hilbert3d/hilbert3d.shtml>.
Qui plus est, si le nombre t entre 0 et 16777215 est repr�sent� en
octal, et si chacun des r(t), v(t) et b(t) est un entier entre 0 et 255
�crit en binaire, alors :
- le premier bit de r(t), v(t) et b(t) ne d�pend que du premier chiffre
de t en octal ;
- le deuxi�me bit de r(t), v(t) et b(t) ne d�pend que des deux premiers
chiffres de t en octal ;
- ...
- le p-i�me bit de r(t), v(t) et b(t) ne d�pend que des p premiers
chiffres de t en octal ;
- ...
Application :
<http://www.mathcurve.com/fractals/hilbert3d/hilbert3d01.gif>
Premier chiffre de t -> premier bit de r(t), v(t), b(t)
0 -> 0,0,0
1 -> 0,0,1
2 -> 0,1,1
3 -> 0,1,0
4 -> 1,1,0
5 -> 1,1,1
6 -> 1,0,1
7 -> 1,0,0
Deux premiers chiffres de t -> deux premiers bits de r(t), v(t), b(t)
00 -> 00,00,00
01 -> 01,00,00
02 -> 01,01,00
03 -> 00,01,00
04 -> 00,01,01
05 -> 01,01,01
06 -> 01,00,01
07 -> 00,00,01
10 -> 00,00,10
11 -> 00,00,11
...
77 -> 11,00,00
Il ne reste plus qu'� trouver la formule g�n�rale. Si je la trouve je
viendrai l'�crire ici.
--
Olivier Miakinen
Jean-Christophe
> > Euh ... je reiterer ma question postee sur <fr.sci.maths> :
> Quant à moi je fais suivre la question vers fr.comp.algorithmes.
Noooon, ma question porte sur certaines fonctions *mathematiques*,
devant presenter les proprietes dont je parlais, c'est des maths
pures,
et je ne cherche pas a recuperer un algo tout fait ...
> J'avais cru que zwim t'avait donné la réponse dans un des liens
> précédents (mais je n'avais pas eu le courage de le lire, étant tout
> en estranger).
Oui, je n'avais pas encore tout lu avant de poster (j'y vais)
> > Existe t'il une methode generique permettant
> > de trouver de tels ensembles de 3 fonctions ?
> Oui, forcément. Il suffit de prendre la 8e étape de la construction
> de la courbe de Hilbert 3D, et d'associer à chaque nombre entre 0 et
> 16777215 les trois coordonnées du point correspondant.
> Cf<http://www.mathcurve.com/fractals/hilbert3d/hilbert3d.shtml>.
> Application<http://www.mathcurve.com/fractals/hilbert3d/hilbert3d01.gif>
[snip]
> Il ne reste plus qu'à trouver la formule générale. Si je la trouve je
> viendrai l'écrire ici.
Ok, j'ai saisi l'idee ...
Merci encore pour ton feed-back.
Olivier Miakinen
>
> Noooon, ma question porte sur certaines fonctions *mathematiques*,
> devant presenter les proprietes dont je parlais, c'est des maths
> pures,
D'accord. Dans ce cas, tu prends n'importe quelle fonction passant par
le centre des 16777216 petites cubes et pour chacun des cubes tu poses :
r(t) = la t-i�me valeur de r
v(t) = la t-i�me valeur de v
b(t) = la t-i�me valeur de b
Il ne tient qu'� toi de choisir une fonction dans laquelle la distance
entre deux cubes successifs ne soit pas trop grande.
> et je ne cherche pas a recuperer un algo tout fait ...
Ok.
Cordialement,
--
Olivier Miakinen
Sylvain SF
> [...]
> Personnellement, je trouve �a horrible et parfaitement illisible, alors
> que la premi�re version est tr�s facile � suivre, sans complexit�
> inutile.
enti�rement d'accord.
> Quel est ton avis ? Y a-t-il une m�thode plus lisible tout en
> �vitant les "continue" que tu juges diaboliques ?
les exceptions ?... comment �a goto aussi ?
Sylvain.
Paris Hilton
> Olivier Miakinen wrote:
>
>>
>> alors que la premi�re version est tr�s facile � suivre, sans
>> complexit� inutile. Quel est ton avis ? Y a-t-il une m�thode plus
>> lisible tout en �vitant les "continue" que tu juges diaboliques ?
>
> Je ne les juge en aucun cas diaboliques; Personnellement j'�cris aussi
> comme tu l'as fait avec les continue. Je trouve �galement parfaitement
> illisibles les indentations � rallonge. L'important c'est la lisibilit�
> et la maintenabilit� du code; je ne souscris absolument pas aux
> opinions talibanesques des pourfendeurs du "goto" ou du "continue"; elles
> pense de ce genre d'individus :-)
>
Le probl�me de ce genre de solution est que au premier coup d'�il on ne
connait pas le chemin de la fonction. Et l'on peut ne pas voir un return
ou un break (ou continue) cach�. Les if imbriqu�s peuvent sembler lourd
mais on sait en 1 seconde par o� passe la fonction et l'on n'est pas
oblig� de regarder en d�tail s'il n'y a pas des interruptions. J'ai
d'exp�rience rat� pas mal de continue ou return au milieu de 30 lignes
de codes alors que le if then else ne trahit pas.