Exact/Approx - Page 1

Dites, je viens de remarquer un truc curieux et utile pour tous ceux qui utilisent la fonction string avec des variables: Comment contourner les bugs d'approx:

Si vous êtes en mode approx ou si l'utilisateur lance bêtement vore prog avec [<>][ENTER], , ça plante assez facilement, et la fonction and bit à bit aussi.
Mais j'ai trouvé une parade (testée sur ams 1.05, 2.03 et 2.05):
Pour annuler le mode approx du au [<>][ENTER], il faut effectuer un changement de mode pendant le prog (avec setMode, mais cela ne marche pas si vous êtes déja en mode auto). En fait, pour être sur de supprimer cette néfaste combinaison de touches, il faut faire 2 setMode:

Local mode
Try
setMode("14","3")->mode //Passe en mode approx, multilingue
setMode("14","1")
Else
setMode("Exact/Approx","APPROXIMATE")->mode //Passe en mode approx, AMS non multilingue
setMode("14","AUTO")
EndTry

Et là, même avec [<>][ENTER], vos nombres entiers le seront vraiment, 1 and 128 fonctionnera tou comme RplcPic #("pic"&string(a))

Si vous connaissez d'autres astuces permettant d'éviter des Errors, postez-les ici!

Vertyos>Ces astuces doivent marcher dans toutes les langues, alors tu peux dégager avec tes Disp "Mets ta calc en anglais, blaireau!"

Edit: Un prob de smiley avec la parenthèse
Edit2 (Réponse à Vertyos, pour ne pas flooder): Ma calc est est déja en Anglais depuis des lustres, je n'ai même plus le Français installé dessus, Il encombrait trop
Edit3, pareil: Oui, ça sert à Eviter que string(1) réponde "1." ça évite aussi les "Arcument must be a boolean expression or integer" pour un 1 and 128 par ex (Au fait, je sais bien que ça répond Zéro, je ne suis pas à ce point-là non plus)

Ça sert à quoi ça ? À éviter que string(1) donne "1." ?

P.S : Met ta calc en anglais, blaireau

Maintenant ça ne marche plus?

Edit: De plus en plus bizarre... j'ai l'impression que ça vient du Try, car je mes des Disp string(1) dans le Try et dehors, et c'est seulement dans le Try que ça marche!
Je vais essayer en mettant mes setMode en dehors du Try...

Il y a une solution plus simple: ne jamais utiliser string(n), mais toujours string(exact(n)).

Et la encore tu vas y trouver un avantage par rapport faire un setmode(...)->var au début puis un autre setmode(...,var) à la fin ?

Oui, ça évite d'aller traffiquer les modes inutilement.

mais c'est plus lent et ça prend plus de place.
D'accord c'est pas super de traffiquer le mode, mais si l'utilisateur ne fait pas de break, il ne s'en rendra même pas compte...

Tout est dit par: "si" (et seulement si) "l'utilisateur ne fait pas de break".

Je suis d'accord.
Mais il faut que l'utilisateur choississe entre avoir un programme plus rapide et plus léger, ou faire des breaks...
De plus si (oui, encore un si...) le programme n'a pas de bug, il n'y a aucune raison de faire un break. ou alors il faut désactiver le break (mais là c'est carrément plus violent, je te l'accorde ).

Et plein de fonctions réactivent le break, faut faire ça toutes les 10 secondes.

Ah? bon bah dans ce cas...

Même avec la fameuse chaine exec? (parceque ça vaut pas la peine de rajouter une lib pour ça...)

Oui, la chaîne exec ferait pareil de toute façon.

Il n'y a pas à faire break dans un programme... Si l'utilisateur fais ça il est consient que ça modifie son déroulement normal, donc tant pis pour le mode il le remettra lui même...

Ximoon
a écrit : Mais il faut que l'utilisateur choississe entre avoir un programme plus rapide et plus léger, ou faire des breaks...

Le exact ne fait que 2 tokens de plus (EXACT_TAG==0xBF et END_TAG), on peut donc en avoir au minimum 10 pour le prix d'un setMode("14","1")->t et d'un setMode("14",t) (les autres variantes de setMode prennent encore plus de place).

mouais c'est jouable...
Ou alors mettre dans le readme:

"pour fonctionner de façon optimale, le présent programme doit être lancé alors que le mode 'exact' a été sélectionné dans la fenêtre 'mode', en appuyant sur la touche 'mode' de votre calculatrice"

Ximoon
a écrit : "pour fonctionner de façon optimale, le présent programme doit être lancé alors que le mode 'exact' a été sélectionné dans la fenêtre 'mode', en appuyant sur la touche 'mode' de votre calculatrice"

Alors là, le programme est carrément bon pour la poubelle... C'est très lourd de devoir changer les modes à chaque fois qu'on veut utiliser un programme.

Ah... j'avais oublié le smiley:
(je n'oserai jamais mettre ça, à la rigueur même si c'était vrai, .... tant pis! je suis en train de penser que mes progs basic doivent se comporter bizarement en approx...)

Moi, de toute façon, je suis toujours en exact.

Tu peux être en mode exact et exécuter^connement ton prog avec [<>][ENTER], tu sera en approx de toute manière

Kevin> On ne dira pas que je suis toujours d'accord avec toi! Je préfère trafiquer les modes, car dans les progs que j'utilise, un exact() ralentirait trop le prog (Songe qu'il faudrait en faire un à chaque cycle de Cool Racer II, la mort)

De plus, je suis un manique des programmes qui quittent "proprement": Je ne supportais pas les progs qu'on quittait uniquement avec [ON] sur CASIO, et je suis allergique à ce genre de progs sales sur TI.
Moi qui fait des progs propres, c'est justement pour qu'on n'ait pas à faire de Break. Alors si l'utilisateur fait un Break, C'est de sa faute!
tant pis pour lui, il n'avait qu'à pas breaker...
Et si le jeu quitte suite à une Error, On n'est pas à cela près... Et je me débrouille pour éviter les Errors, alors dès qu'on tombe sur une, on me la signale et je la corrige

Edit: En plus, il n'y a pas que les string, mais aussi les opérateurs bit à bit qui foirent! (1 and 128, je l'ai déja dit)
Finalement, je l'ai trouvée, cette fameuse réponse!
Le bug venait bien du Try, donc voici le code que j'ai trouvé en remplacement:
Local mode,notexist
If getType(notexist)=/="NONE"
setMode("14","3")->mode //Passe en mode approx, multilingue
setMode("14","1")
Else
setMode("Exact/Approx","APPROXIMATE")->mode //Passe en mode approx, Anglais
setMode("14","AUTO")
EndIf
Et là, mes progs marchent maintenant!
Puisque TI-Fr ferme, je crois que je mettrai mes progs avec mes images...

Ps: Cool, kombat est le jeu basic 89 le plus DL sur TI-Fr! (Et je ne l'ai envoyé que sur ce site-là...)
Et Rallye en 3e position! (+ Cool Racer II, bon 13e... Enfin sur 103 c'est pas sur deux mille...)

En plus, ce sont des vielles version, qui buggent sur Approx, Il va être temps que j'uploade mes nouvelles versions chez moi... Sans bug Approx!

Edit: C'est fait!
Kombat
Rallye
Cool Racer II

Edit2: Ooooooooups! Il y avait une erreur dans CoolRacer II!
Voilà c'est réparé...

Link a écrit :
Le bug venait bien du Try, donc voici le code que j'ai trouvé en remplacement:
Local mode,notexist
If getType(notexist)=/="NONE"
setMode("14","3")->mode //Passe en mode approx, multilingue
setMode("14","1")
Else
setMode("Exact/Approx","APPROXIMATE")->mode //Passe en mode approx, Anglais
setMode("14","AUTO")
EndIf

Attention, il y a un bogue:
Dans la partie censée être compatible AMS 1, tu as mis setMode("14","AUTO"), alors qu'il faut mettre setMode("Exact/Approx","AUTO"). (AMS 1 ne comprend pas "14".)

Apparment il manque un "then" après le if, et puis je ne comprends pas pkoi il passe au mode Approx puis immédiatement après au mode Auto ?

Bah, pour faire un break dans un prog, sauf bug (C rare si l'auteur est tant soit peu méticuleux), il faut vraiment être , car si il y a un local, on est sur de perdre de la RAM... Beaucoup de RAM.

Vertyos
a écrit : Apparment il manque un "then" après le if,

En effet.

et puis je ne comprends pas pkoi il passe au mode Approx puis immédiatement après au mode Auto ?

À cause de ça:

Link a écrit :
Pour annuler le mode approx du au [<>][ENTER], il faut effectuer un changement de mode pendant le prog (avec setMode, mais cela ne marche pas si vous êtes déja en mode auto). En fait, pour être sur de supprimer cette néfaste combinaison de touches, il faut faire 2 setMode

En d'autres mots, si l'utilisateur exécute ton programme avec [DIAMOND]+[ENTER] alors qu'il est en mode AUTO ou EXACT, il faudra changer le mode 2 fois, parce qu'il faut au moins un vrai changement de mode (c'est-à-dire qu'il faut passer d'un mode à un autre différent) pour que celui-ci prenne la précédence par rapport au [DIAMOND]+[ENTER], et que pour être sûr qu'au moins un des changements est un vrai changement, il en faut au moins 2.

Arf ok... Décidement voilà ou on en arrive...

J'aimerais bien voir la tête d'un petit programme basic, une fois qu'on lui a rajouté toutes vos astuces pour le rendre compatible avec je ne sais quoi

Double-K> Merci de m'avoir signaler le bug! Bon heureusement, il n'est pas dans mon code TI.
Quant au Then, dsl, je suis un peu mélangé entre le TI-Basic et le C8086, 'faut dire que IE d'a pas de menu déroulant pour les fonctions du TI-Basic!