Erreur mémoire incompréhensible - SolveN
Posté le 21/04/2021 15:04
Voici le morceau de code que je suis en train de tester :
0→A~Z
√3×π^5→T
"entre fonction"?→Y1
Y1(T)→M
SolveN([b]Y[/b]1-M, X, T, 9ᴇ99
Ce morceau de code marchait parfaitement il y a 1 heure, et voilà que maintenant il ne fonctionne plus !
Avec n'importe quelle fonction entrée (aussi bien X² que sin log X), la calto affiche "Erreur mémoire" et place le curseur sur le SolveN(. La mémoire principale libre est de 45 ko, donc pas de prob à ce niveau-là.
Par contre, en remplaçant "entre fonction"?→
Y1 par "X²"→
Y1, le code fonctionne (je vous prie de croire qu'il n'y a vraiment aucun soucis pour la borne supérieure 9ᴇ99). Ou alors, juste après avoir obtenu l'erreur, copier la ligne de SolveN et la coller dans RUN/MAT, et voilà que ça fonctionne de nouveau.
Franchement ça m'ennuie un peu... Est-ce possible que ce soit dû à mon niveau de batterie (je n'ai pas d'autres piles pour pouvoir tester) ? J'ai 1 barre de batterie sur 3 depuis quelques temps déjà, mais je n'ai pas encore eu le message "Veuillez remplacer les piles !". Je propose ça comme cause, mais j'en sais rien hein (j'avais déjà remarqué une fois que la calto n'arrivait plus à se connecter à FA-124 avec des piles presque vides), donc proposez-moi vos idées
.
Merci d'avance !
Citer : Posté le 21/04/2021 16:41 | #
Pour référence ça marche chez moi donc le comportement exceptionnel semble être l'erreur.
Citer : Posté le 21/04/2021 16:52 | #
Coucou,
Vérifie si tu as encore de l'espace disponible sur ta calculatrice dans la mémoire principale (parfois quand il reste moins de 1000 otctets les programmes ne se lancent plus et affichent "erreur mémoire").
Citer : Posté le 21/04/2021 16:56 | #
Psst, c'est mieux de lire le post en entier avant de répondre !
Citer : Posté le 21/04/2021 21:51 | #
En effet, cette erreur est très mystérieuse...
J'ai réussi à trouver des piles chargées, mais cette erreur de malheur est toujours là (même après avoir redémarrer la calto)
Donc si je récapitule :
-j'ai effacé tout de la calto sauf les programmes (45 ko libres)
-j'exécute le code dans un prog -> erreur
-juste après, je copie la ligne SolveN, l'exécute dans RUN/MAT ou dans un nouveau prog, et cette fois-ci la calto donne une bonne réponse sans erreur.
-l'erreur persiste dans le programme d'origine (aussi en diminuant la borne sup)
Est-ce que ça pourrait être dû à un grand nombre d'appels à SolveN ?
Tout ce que je vois que je pourrais faire c'est réinitialiser ma calto (et ça marchera peut-être !)...
...
.........
Bon, j'ai fait plein de tests (j'écris ce message au fil de ceux-ci), et apparemment c'est normal que vous n'ayez pas d'erreur. J'ai cru comprendre que le problème venait de là vu que le curseur est mis sur "SolveN(" après l'erreur, mais finalement non. L'erreur n'apparaît que avec ce qu'il y a après.
Je viens de tester : je n'obtiens l'erreur que si j'ai au moins 241 octets après le retour à la ligne du SolveN. Je ne comprends absolument pas pourquoi (encore moins pourquoi ce chiffre précisément - et encore encore moins pourquoi avoir mis le curseur sur le SolveN). Ces 241 octets peuvent être de tout genre : du code normal (ce que j'avais avant), ou 9 alphabets (celui qui m'a permis de connaître le nbr d'octets min) - dans des string différentes.
Si quelqu'un pourrait me dire ce qu'il ce passe ce serait vraiment super sympa, s'il vous plaît (ou au moins me dire si cette erreur peut-être reproduite avec une autre calto).
Je comprendrais parfaitement si vous ne voulez pas m'aider, car c'est un problème vachement précis et qu'il pourrait vous prendre pas mal de temps...
P.S. :
Ma calto est une Graph 75 (GRAPHIQUE USB 2), avec l'OS 02.05.2201 que j'ai installé moi-même (avec fxRemote).
Citer : Posté le 21/04/2021 21:56 | #
J'ai l'erreur aussi. Peut-être que SolveN() enregistre une fonction dans la mémoire fn ou ce genre de trucs. (Quand tu fais un enregistrement dans la mémoire fn ça prend le programme entier).
Ça l'air de marcher si je mets le SolveN() dans un sous-programme.
Citer : Posté le 21/04/2021 22:40 | #
Oui, en effet : pour moi aussi ça marche dans un sous prog. (c'est quand même ennuyant, mais bon on doit faire avec haha.)
On dirait que j'ai le don - ou le malheur - pour trouver toute sorte d'erreurs bizarres renvoyées par la calto (comme l'erreur saut avec la boucle For et une instruction).
Que veux-tu dire par là ? En remplaçant SolveN par quelque chose pour enregistrer une fonction dans fn, je n'arrive pas à obtenir d'erreur mémoire.
Aussi, après l'exécution de solveN je ne vois pas de "mem-f" dans ma mémoire principale.
Ceci dit, je viens d'y penser maintenant, se pourrait-il qu'il y ait un rapport entre les 241 octets et les 255 max d'une chaîne de caractères ?
Et puis, à quel moment est-ce possible d'avoir fait une fonction qui puisse faire ce genre d'erreur inattendue ? Je trouve que le Basic Casio est quand même mal foutu pour pas mal choses...
Aurais-tu une autre idée pour pallier cette erreur (que d'avoir un sous-programme) ? J'ai essayé avec seulement Y1 comme premier argument, mais toujours la même erreur.
Citer : Posté le 21/04/2021 22:43 | #
Je parle de OPTN, FUNCMEM, STORE. Je comprends toujours pas pourquoi ça capture tout le programme de la ligne sélectionnée à la fin. Je l'ai mentionnée parce que c'est la seule fonction que je connais qui est impactée par le code autour.
Le Basic Casio n'est pas un langage de programmation avec une sémantique propre, c'est beaucoup de hacks. Ce genre de choses est assez inhérent à PRGM et on n'y échappera pas.