Posté le 21/10/2020 11:13
tandis que (-27)^π pose un petit soucis et non (-27)^(-1/3) = -1/3 ). Je ne peux donc malheureusement pas utiliser la relation a^b = e^(b.ln a)......
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 251 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 22/11/2020 21:21 | #
Je te réponds assez rapidement, car je n'ai pas bcp là maintenant (et ça permettra de bien faire avancer les choses).
C'est-à-dire que la première fois que j'ai écrit le message je ne l'avais pas oublié
• Est-ce que tu veux tout les nombres qui s'écrivent comme un rationnel p/q avec q qui fait moins de 10 chiffres ?
• Est-ce que tu veux tout les nombres qui ne sont pas un multiple rationnel de π, √2 ou ln 3 ?
Au début, je suis parti du principe que l'on allait considérer π, ln 2 et √5 comme irrationnel sur la calto. Je suis énormément tenté par les considéré comme rationnels, et comme ça l'affaire est dans le sac. Posons H∈R (irrationnel comme rationnel), il sera donc rationnel sur la calto (15 chiffres significatifs). Mais est-ce que changer sa forme décimale en quotient "p/q" ne changerait pas la valeur de (-27)^H? Je veux dire par là serait-il possible de trouver une réponse réelle à ce calcul alors que H est irrationnel (rationnel à 15 chiffres sur la calto) donc n'aurait pas de solution réelle ? S'il n'y a aucune différence ni aucun risque alors bien sûr je vais foncer direct là dedans.
Je préfère garder q sans condition. Malheureusement s'il dépasse 10^99 on obtient une erreur math je me suis dis "limitons-le à 10^60 comme ça pas d'erreur de math et on a aucune chance de sauter de 10^60 à plus de 10^99". Donc voilà haha
J'ajoute ça aussi à la TODO list, pas trop le temps la maintenant...
Comme dit précédemment (je ne sais pas vraiment comment bien expliquer), on recherche avec une entrée A une sortie p/q. Si on pose directement que A peut s'écrire en quotient, l'algo (en tout cas de mon point de vue/de mon côté) devient plus facile à gérer et il devient dès lors facile de dire que A n'est finalement pas un quotient. Un peu comme une démonstration par l'absurde si tu veux
Il me semble que j'ai réussi à répondre à ceci juste au-dessus (dans ce message-ci), même si j'ai répondu avec une question
Pourquoi toujours utiliser des termes alors que leur signification est si simple ?
OK on va faire ça haha
Oufti... Le "petit" message a légèrement muté on dirait
Citer : Posté le 23/11/2020 21:53 | #
Une fois que tu as ramené ton entrée entre 1 et 10 tu as D=1 donc 10^(-D-E) c'est en gros 10^-E donc en fait c'est la valeur de la plus petit décimale de ton entrée. Ça a pas l'air mauvais. Mais comme pour l'instant on n'a pas d'invariant on ne sait pas quoi déduire de Ans < 10^-E. À voir.
Ah oui mais non. Il y a déterminer si oui ou non A^B va renvoyer un résultat, et remplacer B par ce que tu penses être B en espérant que ça renvoie le même résultat. Pour moi il n'est pas question de modifier le calcul.
Pour moi la question est : trouver tous les A^B pour lesquels la calculatrice renvoie une racine réelle. Mais tu vois, autant j'ai prouvé qu'une racine réelle existe pour les rationnels p/q si GCD(2p,q)=1 et est tordue à définir pour les irrationnels, autant personne n'a dit que la calculatrice faisait ça.
Si tu t'intéresses à ce que la calculatrice fait, tu remarques que A^B (A<0) renvoie un résultat réel si et seulement si B tout seul a une approximation fractionnaire avec F/D dans RUN/MAT. Donc sans vouloir remettre en cause tout le but de cette conversation... ce que tu calcules depuis tout à l'heure n'est pas bien spécifié. Par exemple ton programme ne devrait pas trouver de décomposition à 1÷3-ᴇ-5 = 99997/300000 même si c'est une fraction raisonnable.
Citer : Posté le 23/03/2021 12:00 | #
Maintenant que tu le dis, c'est vrai qu'on peut remarquer que A^B avec A<0 et B fractionnaire ne donne de résultat sur la calculatrice que si B "a une approximation fractionnaire avec F/D dans RUN/MAT".
J'ai réfléchi assez longtemps sur les conditions pour avoir cette fraction, j'en suis arrivé à trois possibilités d'avoir exactement les approx fractionnaires données par la calto (ie pas "1/3 - 1E-5") :
- Faire du reverse engineering : cela permettrait de savoir de quel façon cette approx fract est faite, mais je n'ai clairement pas les compétences/connaissances à ce niveau-là. Donc pour moi on oublie.
- Faire des tables de correspondance ("lookup table") : on pourrait dire pour chaque dénominateur quel numérateur maximal peut être trouvé. Prendrait beaucoup de temps (et sûrement de stockage), mais j'ai déjà remarqué que si B>1E6, alors B n'aura jamais d'approx fract. À envisager.
- OCR sur l'écran de la calto (la moins rigoureuse de toute je pense) : afficher le nombre B sur l'écran avec "◢", attendre que l'utilisateur appuie sur "F/D" puis tester les pixels pour retrouver le numérateur et dénominateur (si approx fract il y a). Fonctionnerait car "1÷3◢" affiche "0.333333333", en pressant sur F/D on obtient "1┘3". Par contre, j'estime qu'on peut oublier car c'est vraiment une perte énorme de temps de calcul...
Je veux encore bien faire avec la 2e méthode, même si toutes les conditions (qu'il pourrait y avoir afin d'obtenir une approx fract) seraient sans aucun doute lourdes.
J'en ai donc conclu que, même en modifiant/améliorant les performances du programme R2FRC, il serait impossible (ou alors extrêment dur) d'être fidèle à ce que RUN/MAT peut renvoyer. J'ai donc pensé à "tricher" (ça me ressemble bien, ça... j'ai l'impression de ne faire que ça quand je programme
Si A^B peut être écrit comme A^(P/Q), et que Q est impair, alors nous obtenons Q*√(A^P) (appelons cette expression T).
Dans un sens, avec cette toute dernière technique, j'ai bien conscience de faire des choses "illégales" (encore une fois...), comme tu dis :
Le but complet de ce thread était de pouvoir, à partir d'une fonction Y1 donnée, calculer des points de cette fonction sans jamais avoir d'erreur math. La technique que je propose est bien sûr bourrine, mais permet (dans un premier temps) de contourner le problème en question, à savoir l'exacte condition d'existance de l'exponentielle. Il suffirait donc, dans la fonction entrée, de remplacer l'exponentielle par T (qui sera, à chaque calcul d'une image, changé). Le problème n'est donc pas réglé (loin de là)...