Outils communautaires de programmation fx-92 SC+

→ **MyCalcs** profile · by **Krevo_** » 15 Oct 2019, 12:45

L'important est que le script utilisé pour évaluer les participations reproduise fidèlement le programme d'origine de l'auteur de la participation.

→ **MyCalcs** profile · by **critor** » 15 Oct 2019, 12:50

Krevo_ wrote:L'important est que le script utilisé pour évaluer les participations reproduise fidèlement le programme d'origine de l'auteur de la participation.

En terme de taille ça n'a pas une importance essentielle.
Car pour le score on retient la taille de ce que vous nous envoyez, et non pas la taille de ce qui est saisi dans l'émulateur.

Et en terme d'exécution, je doute que ça fasse une différence pour un tel écart.

→ **MyCalcs** profile · by **Krevo_** » 15 Oct 2019, 13:00

critor wrote:J'ai mis à jour le script lié en 1er post :
viewtopic.php?p=246387#p246387

Voici la dernière version qui marche avec ,3484525421→M, changé une décimale dans la détection d'erreurs d'approximation :

ça a l'air de fonctionner. Merci.

→ **MyCalcs** profile · by **Lephe** » 15 Oct 2019, 17:55

Pour information, ce problème vient du fait que mon lexer (comme on pourrait l'attendre d'un lexer) renvoie les tokens "constantes décimales" avec la valeur de la constante. Quand on régénère le texte associé, ce n'est pas une surprise qu'il soit différent.

Pour faire ça proprement , je devrais ajouter à chaque token une petite référence à la zone du code d'où il est tiré, comme ça on pourrait toujours reproduire le texte d'origine peu importe les traitements appliqués. Si le besoin existe encore, je peux le faire sans souci.

→ **MyCalcs** profile · by **Krevo_** » 16 Oct 2019, 09:18

Et là dans ma dernière version, j'ai

,686764678124212→A
,611124811184211→M

qui deviennent :

,686764678124212046839147660648450255393981933593→A
,611124811184211047532244265312328934669494628906→M

Et donc je veux pas envoyer ça, car ça fini par une erreur mémoire quand on joue la macro...

Donc, oui si ça peut se corriger, je suis preneur (avec effectivement le risque que ça m'intéresse que pour la durée du concours mais bon ... vous parliez aussi des années suivantes..)

→ **MyCalcs** profile · by **critor** » 17 Oct 2019, 00:40

Krevo_ wrote:Et là dans ma dernière version, j'ai

,686764678124212→A
,611124811184211→M

Là désolé mais tu exagères, tes nombres n'ont rien de remarquable, je n'ai pas de possibilité à mon niveau de corriger les approximations du format du Lexer sur ce genre de chose.

Mais quel peut bien être l'intérêt de saisir de tels nombres ?
La fx-92+ utilise 40 bits pour les mantisses en virgule flottante, soit au mieux 13 chiffres significatifs. Tu es déjà au-delà avec tes 15 chiffres significatifs (soit ~48 bits alors que Python en utilise 53, ce qui ne laisse que 5 pauvres bits pour le test d'approximations).

Notre convertisseur tu n'as pas besoin de t'en préoccuper, nous sommes attentifs à chaque script reçu et nous le faisons évoluer en fonction des besoins.

Mais avant de t'inquiéter des décimales inutiles qu'il pourrait nous faire saisir et de la mémoire qu'il pourrait gaspiller (et qui comme dit plus haut n'influent absolument pas sur le score et probablement pas sur le résultat), je crois qu'il y a également des caractères inutiles pour des économies évidentes de mémoire dans ton code.

→ **MyCalcs** profile · by **critor** » 17 Oct 2019, 00:51

Par contre pour te faire plaisir, j'ai mis à jour le script pour tenir compte de la limitation à 13 chiffres significatifs.
En cas d'approximation non détectée comme c'est le cas ici, ça évitera la tripotée de décimales.
viewtopic.php?p=246387#p246387

Prenons donc ton exemple :

Code: Select all: ,686764678124212→A ,611124811184211→M

Une fois converti en QR Code puis converti en macro puis ressaisi, ça donne ça maintenant :

Code: Select all: ,6867646781242→A ,6111248111842→M

→ **MyCalcs** profile · by **Krevo_** » 17 Oct 2019, 06:30

Bonjour,

critor wrote:Mais quel peut bien être l'intérêt de saisir de tels nombres ?

L'intérêt c'est de s'en servir de stockage des informations pour pouvoir dessiner (lors du concours de tracé par exemple). Donc oui chaque chiffre doit etre identique a l'original et s'il en manque , il manquera des pixels. C'est ce concours qui m'oblige à des ''extrémités' de ce genre

Voilà dévoilé un peu de mes astuces...

Après il me semble que le lexer envoi bien le bon nombre en entrée. Hier soir, J'étais en train de modifier convertiMacro pour sortir au + n Keys qu'il y a de décimales.

Je soumettrai mes prochaines participation avec leur macro je pense.

→ **MyCalcs** profile · by **Krevo_** » 17 Oct 2019, 06:34

Par contre tu parle de 13 chiffres significatifs, mais mes essais m'ont montré que je pouvais exploiter jusqu'au 15e chiffres après la virgule.

→ **MyCalcs** profile · by **ptijoz** » 17 Oct 2019, 08:22

Krevo_ wrote:Par contre tu parle de 13 chiffres significatifs, mais mes essais m'ont montré que je pouvais exploiter jusqu'au 15e chiffres après la virgule.

voila ce que dit la doc de Casio

Donc si tu travailles avec le 15eme chiffre, tu risques d'avoir des problèmes d'arrondi de temps à autre...

Edit Sinon pour l'outil pour récupérer les scripts dans l'émulateur c'est Python2 ou Python3 qu'il faut utiliser ?