C.Ret, ton programme pèse 5 octets de moins que le mien, soit 56 octets.
Si je n'ai pas fait le calcul dans l'autre sens, c'est sans doute parce que j'ai suivi le processus de réflexion habituelle : test de la divisibilité par 4, puis test de la divisibilité par 100, etc.
Je suis donc parti de mon avant-dernier programme - qq lignes plus haut - de 135 octets (!) que j'ai amélioré essentiellement en supprimant la variable locale, tout en lui conservant une certaine lisibilité.
Après, au jeu du « MPO », il y a bcp de « Siliciens » globalement meilleurs que moi. Si si… Non seulement je programme peu, mais MPOïser n'est probablement pas ma "faculté" la plus développée.
Non, ce que j'aime, c'est la clarté dans la confusion… ou dans le RPL, c'est pareil !
Cependant, en suivant tes observations, j'ai pu très facilement descendre à 58,5 octets (au lieu de 61) :
Code : Tout sélectionner
«
DUP
4 MOD NOT
OVER
100 MOD
AND
OVER
400 MOD NOT
OR
»
Rmq : OR ou XOR ⇒ même résultat
Puis en réfléchissant, càd en tâtonnant avec mes doigts sur le clavier (… une réflexion garantie 100% digitale ), à "mes" opérateurs logiques (surtout aux "négatifs" ), je suis arrivé à ceci :
Code : Tout sélectionner
«
DUP
4 MOD NOT
OVER
100 MOD
AND
OVER
400 MOD
XOR
»
Mais - car il y un mais - quand ce programme dit "oui" (1) il faut comprendre "non" (0) et inversement !
Bin oui…
J'ai alors pensé qu'on ne ferait sûrement pas bcp mieux - voire pas mieux du tout - que ce nos 56 octets, vu que les nombres et instructions
"4 MOD 100 MOD 400 MOD" réunis dans un même prgm représentent déjà 41 octets. C'est alors que je me suis remémoré une saine lecture…
« Et voilà » comme disent nos amis de langue anglaise :
Code : Tout sélectionner
«
DUP
4 MOD NOT
OVER
2 ALOG MOD
AND
OVER
2 ALOG * 4 MOD
XOR
»
"plus" c'est "moins" ! C'est étrange le RPL, voire un peu vicieux, non ?