Re: un petit peu plus (de divisions)

[3615 mavie]

soit 41/30/99 fois plus de temps...
[...]
Plus qu'à l'optimiser.

J'ai pu optimiser un peu en essayant de réduire les calculs qui étaient refaits plusieurs fois : maintenant on stocke ces valeurs (échange d'un peu de temps CPU par un chouia de RAM ahha) et ça porte son fruit.

arguments	real	user	sys
1 2 3 8 old	0’31.546"	0’16.209"	0’26.335"
1 1 3 8 new	2’34.099"	1’15.180"	2’07.548"
1 2 7 7 old	0’31.369"	0’16.186"	0’26.573"
1 2 7 7 new	2’34.225"	1’15.134"	2’07.486"
1 5 7 8 old	0’31.556"	0’16.218"	0’26.919"
1 5 7 8 new	2’34.688"	1’15.529"	2’07.782"
1 4 5 6 old	0’31.442"	0’16.191"	0’26.819"
1 4 5 6 new	2’33.411"	1’15.030"	2’06.635"

À noter que je n'ai pas fait plusieurs exécutions et tiré les moyennes ; je ne suis pas dans un contexte de benchmark mais un contexte d'optimisation de code. Justement, une étape suivante serait de faire du profilage (un vaste débat pour du shell...)
Bien. On note un effondrement des performances... /o\ Pourtant, j'ai réduit les appels à dc :

id	type formule	avant	après
b1	Ax(ByC)zD	2+1	3
b2	(AxB)y(CzD)	2+2	3
b3	AxByCzD	2+1	3
l1	(AxB)yCzD	2+1	3
l2	(AxByC)zD	2+1	3
r1	AxBy(CzD)	2+2	3
r2	Ax(ByCzD)	2+2	3
all	total	24	21

Certes pas de beaucoup... Surtout qu'en contrepartie j'ai augmenté les appels à tr (via une sous-évaluation du shell) :

id	type formule	avant	après
b1	Ax(ByC)zD	1	2*2
b2	(AxB)y(CzD)	0	2*2
b3	AxByCzD	1	2*2
l1	(AxB)yCzD	1	2*2
l2	(AxByC)zD	1	2*2
r1	AxBy(CzD)	0	2*2
r2	Ax(ByCzD)	1	2*2
all	total	5	28

Le mieux est vraiment l'ennemi du bien... /o\ Et comme on dit, faut pas chercher à optimiser trop tôt, et le script évolue encore.
Par ailleurs, j'ai revu les tests de garde-fous et ai viré ce qui n'avait de sens que lorsqu'on travaillait en \textbb{N}. Donc on calcule plus de cas qu'avant... (un élément en plus de l'augmentation de consommation de ressource, et je n'ai refait les mesures qu'après avoir fait toutes ces modifications.)

id	type formule	1 2 3 8	1 2 7 7	1 4 5 6	1 5 7 8
b1	Ax(ByC)zD	10/1536	2/1520	0/1536	4/1536
b2	(AxB)y(CzD)	10/1488	0/1480	0/1488	4/1488
b3	AxByCzD	8/1536	2/1536	0/1536	4/1536
l1	(AxB)yCzD	8/1536	2/1536	0/1536	4/1536
l2	(AxByC)zD	8/1536	2/1536	0/1536	4/1536
r1	AxBy(CzD)	10/1536	0/1520	0/1536	4/1536
r2	Ax(ByCzD)	8/1530	0/1520	1/1524	4/1530
all	totaux	62/10698	8/10648	1/10692	28/10698

Et là on a une petite surprise...

Si on prend le cas soumis par le_poney, il n'y a qu'une seule solution qui est trouvée dans deux branches branches mais en deux ou quatre fois pour chacune...

Eh non, il y a une seconde solution...
console
$ trouve24.sh 7 7 1 2
2/7=.28; 7/.28=25.00; 25.00-1=24; B1
7*7=49; 49-1=48; 48/2=24; B3
7*7=49; 49-1=48; 48/2=24; L1
7*7=49; 49-1=48; 48/2=24; L2
2/7=.28; 7/.28=25.00; 25.00-1=24; B1
7*7=49; 49-1=48; 48/2=24; B3
7*7=49; 49-1=48; 48/2=24; L1
7*7=49; 49-1=48; 48/2=24; L2
Found 8 solutions for 10648 computations.


...qui, un peu similaire à un autre cas, se traduit par 7/(2/7)-1 (forme B1) ou... $\frac{7}{\frac{2}{7}}-1$

Bon, faudra peut-être augmenter la précision de calcul ?

$ dc -e '2k2 7/p'
.28
$ dc -e '18k2 7/p'
.285714285714285714

En fait c'est 0.\underline{285714}
et on peut sentir que c'est faux même si ça tombe juste malgré les erreurs qui s'annulent (est-ce lié à l'usage de la virgule fixe dans dc ?) En effet,

On ne peut rien contre ce genre de truc à partir du moment où le site lui-même travaille en flottants et non en entiers. C'est marrant/intrigant...

(p.s. Je mettrai à jour le snippet plus tard)

Je l'ai faite hier pour la monture dont je parle présentement (y a eu depuis d'autres améliorations dont je parlerai une autre fois).

Plus de résultats mais pas mal de duplications... Arriver à les anticiper et donc ne pas calculer inutilement (ce qui aurait quand même été le cas si on stockait les résultats pour au final n'en afficher que les occurrences uniques...) C'est une piste d'amélioration qui pourrait impacter positivement le temps d'exécution.

Je ferai un autre topo sur ce point plus tard.

"It is seldom that liberty of any kind is lost all at once." ― David Hume