mirror of
https://github.com/UpsilonNumworks/Upsilon.git
synced 2026-05-09 08:25:44 +02:00
[GH-ISSUE #173] [ Calculs ] (x^n)^p => x^(n*p) pour x réel et (n et p) entiers relatifs #59
Labels
No labels
bug
duplicate
easy
enhancement
enhancement
fixed
fixed
good first issue
hard
invalid
pull-request
wontfix
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Upsilon#59
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @fmOOmf on GitHub (Mar 3, 2022).
Original GitHub issue: https://github.com/UpsilonNumworks/Upsilon/issues/173
Bonjour à toute l'équipe Upsilon.
Problème rencontré :
Dans l'application "Calculs", je désire illustrer la propriété :
(x^n)^p = x^(n*p)
Or l'entrée (x^4)^2 reste identique : (x^4)^2 affiché. x^8 attendu.
Proposition d'évolution :
Serait-il possible de simplifier les résultats dans le cas de calcul formels simples :
(x^n )^p pourrait donner x^(n*p).
A minima dans le cas de n et p entiers naturels (= positifs).
Attention dans le cas où n et p ne sont pas entiers, il y a des subtilités qui peuvent amener à des résultats inexacts si on n'y prend pas garde.
Copie d'écran de l'exemple :
Observé sur :
Upsilon 1.0 beta (Simulateur et N0110)
@fmOOmf commented on GitHub (Mar 7, 2022):
Correction : une erreur de frappe dans mes essais.
(x^4)*(×^4)/(×^2) donne bien x^6.
Seul (x^n)^p n'est pas simplifié.
J'ai corrigé le post initial en le restreignant au seul cas (x^n)^p.
Désolé.
Il y a néanmoins un volet à traiter (bug) concernant (x^n)*(x^p) = x^(n+p) lorsque n et p ne sont pas entiers. Préférez-vous un ticket séparé ?
@Oreig403 commented on GitHub (Mar 9, 2022):
Un bug à corriger serait aussi:
@Oreig403 commented on GitHub (Mar 9, 2022):
à simplifier en x
@Yaya-Cout commented on GitHub (Mar 9, 2022):
I think https://github.com/Omega-Numworks/Omega/pull/435 fixes it
Je crois que https://github.com/Omega-Numworks/Omega/pull/435 corrige ceci
@fmOOmf commented on GitHub (Mar 9, 2022):
Bonjour.
Attention ce sont precisement les subtilites des cas oû les exposants ne sont pas entiers.
sqrt(x^2) doit être simplifié en abs(x).
Je voulais faire un ticket dédié pour cette amélioration, et pour corriger un bug.
@Yaya-Cout commented on GitHub (Mar 9, 2022):
Comme ceci ?
Like this ?
@fmOOmf commented on GitHub (Mar 9, 2022):
Oui.
Autre cas :
(sqrt(x))^2 se simplifie en x mais n'est défini que pour les réels positifs (si on n'a pas activé les résultats complexes).
Donc pour le calcul formel : on peut simplifier [sqrt(x)]^2 par x (application "calculs")
=> amélioration à implémenter, dans les cas complexes ou réels indifféremment. On passe sous silence le domaine de définition restreint dans le cas des réels.
Mais lorsqu'on manipule des valeurs dans les applications "calculs" et "fonction" :
lorsque les complexes ne sont pas activés : il faut respecter le domaine de definition. Le calcul/tracé doit se restreindre aux "x" positifs.
lorsque les complexes sont activés : le calcul peut se faire pour toutes les valeurs. Le tracé theoriquement aussi ... si on sait gérer les affichages en complexe...
Sur ce point, Upsilon se comporte bien. Donc pas de changement.
@fmOOmf commented on GitHub (Mar 9, 2022):
Enfin :
Sqrt(x)*sqrt(x) est quant à lui bien simplifié en x dans "calculs". Et il est bien géré concernant les calculs (défini sur les positifs seulement, quand les complexes ne sont pas activés).
Par contre il y a un BUG dans l'application "fonctions" : le tracé se fait pour tous les réels au lieu d'être restreint aux nombres positifs lorsque les complexes ne sont pas activés.
C'est un peu fastidieux mais ce bug est vraiment à corriger.
@fmOOmf commented on GitHub (Mar 9, 2022):
Prudence donc lorsque les exposants ne sont pas entiers.
ex : simplification de root(x^n, n).
@Yaya-Cout commented on GitHub (Mar 10, 2022):
I just tested, and
sqrt(x²)=abs(x)is wrong in case of an imaginary :x=𝐢 sqrt(x²)=sqrt(𝐢²)=sqrt(-1)=unreal, but ifsqrt(x²)=abs(x),sqrt(x²)=sqrt(𝐢²)=abs(𝐢)=1, that is wrong…Je viens de tester, et il s'avère que
sqrt(x²)=abs(x)est faux dans le cas d'un imaginaire, en effet :x=𝐢 sqrt(x²)=sqrt(𝐢²)=sqrt(-1)=unreal, mais sisqrt(x²)=abs(x),sqrt(x²)=sqrt(𝐢²)=abs(𝐢)=1, ce qui est faux…@fmOOmf commented on GitHub (Mar 10, 2022):
Exact. C'est abs(x) quand on n'a pas activé les imaginaires pour le cas soulevé par oreig403.
-1 donne abs(-1) = 1
Dans un cas imaginaire la racine carrée restreint l'argument à ]-pi/2 pi/2].
(-i) donne donc bien i par exemple.
Et -1 donne bien toujours 1.
C'est pour cela qu'il faut être prudent : entre les cas sans complexe et les cas avec complexes, les domaines de definition et le fait qu'il y a plusieurs applications dans Upsilon, la combinatoire devient vite importante et on peut facilement oublier des cas de figure.
Je peux moi-meme être inexact. Il faut sans doute se conformer à des sources documentaires qui font référence.
@Yaya-Cout commented on GitHub (Mar 10, 2022):
Si on se fie à XCas PC, c'est bon, malgré les imaginaires :
@fmOOmf commented on GitHub (Mar 10, 2022):
Oui et dans le cas imaginaire on attend i pour i donc ce n'est pas "abs" qu'il faut implémenter.
Le "abs" est un raccourci pratique dans le cas des réels. Dans le cas complexe peut être ne faut il rien simplifier sur ce cas précis.
Pour gagner du temps, une bonne référence biblio sera un juge de paix rassurant.
@fmOOmf commented on GitHub (Mar 10, 2022):
Je viens de regarder : l'argument est ramené modulo 2pi dans ]-pi pi ] donc l'argument après racine carrée est dans ]-pi/2 pi/2].
J'ai corrigé le post plus haut.
@fmOOmf commented on GitHub (Mar 10, 2022):
Re-Bonsoir
J'ai l'impression qu'en fait il n'est pas possible d'activer ou inactiver les nombres complexes.
L'option "complexe" semble n'être qu'une option d'affichage ("réel" ou "a+ib" ou "module et argument").
Si c'est cela, cela change tout : cela signifierait que le firmware calcule en complexe tout le temps. Il indique seulement "unreal" quand :
Cela expliquerait pourquoi sqrt(x^2) n'est pas simplifié en abs(x) : ce n'est vrai qu'en réel.
Et cela explique pourquoi sqrt(×)*sqrt(x) est tracée pour les valeurs de x<0 malgré l'option "réel". Ce n'est pas un bug : c'est calculé en complexe, mais comme le résultat est réel, l'application "fonction" peut le tracer.
C'est par contre juste extrêmement dommage parce que les nombres complexes ne sont abordés qu'en terminale de mémoire, et encore uniquement pour les élèves qui font spécialité math.
Comment expliquer à 95% des élèves (collège + lycée) qu'ils doivent être extrêmement vigilents sur les domaines de définition des fonctions, mais qu'il y a des situations où leur calculatrice a un comportement différent, pour des raisons qu'ils ne verront peut être jamais ? Dans ces cas là, ils auront faux s'ils font comme la calculatrice, puisqu'ils sont censés travailler uniquement en réel.
Il y a de quoi perdre confiance dans les résultats calculés je trouve.
J'espère me tromper mais si c'est bien l'explication, alors la vraie évolution à demander serait peut être la mise en place d'un choix du mode de calcul : réel/complexe.
Cela permet de s'assurer que la calculatrice à le comportement attendu pour tous les niveaux d'études, et cela permet des simplifications d'expression qui aideront les élèves au quotidien.
A vous de finaliser ces réflexions. Vous avez plus d'information avec votre connaissance du firmware, et surtout, vous portez les choix stratégiques pour la saga Upsilon.
Bon courage a toute l'équipe.
@devdl11 commented on GitHub (Mar 11, 2022):
Et encore ! Uniquement par les élèves faisant maths expertes x)
@M4xi1m3 commented on GitHub (Mar 11, 2022):
Je ne pense pas, sinon
sqtr(-1)^2retournerais -1 en réel et en complexe, alors que non.Je crois que le format de complexes utilisé est passé à poincaré lors de l’évaluation d'une expression mathématique. Il serait possible de conditionner ces simplifications au fait qu'on soit en mode réel.
@fmOOmf commented on GitHub (Mar 11, 2022):
Oui c'est bien indiqué "unreal" dans "calculs" (donc complexe détecté ?) mais c'est tracé avec la valeur -1 dans "fonction ". C'est pour cela que je pensais à un bug au début.
Effectivement il suffit peut être d'aligner l'application "fonctions" (pas d'affichage) lorsque "calcul" affiche "unreal.
Vous pouvez par contre simplifier sans état d'âme (x^n)^p par x^(n*p) dans le cas où n et p sont des entiers 👍
@LukasMFR commented on GitHub (Mar 30, 2022):
Salut l'équipe,
J'ai eu ce bug sur Omega 1.22.1, alors que j'étais sûr que (x^2)^4 renvoyait x^8.
Du coup j'ai juste fais des calculs random dans la calc et changé des réglages et là ça remarche j'ai donc essayé dans le simulateur d'Upsilon et ma "technique" fonctionne :
Sur le sim c'est Upsilon 1.0.0-dev, Omega 1.22.1 et Epsilon 15.5.0 (le build est 5b4c1dd).
@fmOOmf commented on GitHub (Mar 30, 2022):
Hello. Quels réglages as-tu changé ?
@LukasMFR commented on GitHub (Mar 30, 2022):
Vraiment au hasard, donc format d'angle : radian, forme complexe : algébrique, police Python : petite
Mais ça ne s'est pas débuggé tout de suite
@LukasMFR commented on GitHub (Apr 3, 2022):
En fait j'ai l'impression qu'il faut juste activer "Forme algébrique" dans les Options pour que ça simplifie.
@fmOOmf commented on GitHub (Apr 3, 2022):
Ah super.
Une piste à suivre pour comprendre comment faire pour que :
- dans le cas de nombres "réels"
- pour n et p entiers (naturels ou relatifs)
(x^n)^p puisse se simplifier en x^(n*p) comme actuellement pour les nombres complexes.
Cela permettra de clore ce post.
J'en ouvrirai un spécifique aux cas où n et p ne sont pas entiers, qui sont plus délicats à gérer.
Merci LukasAppleFan !
@LukasMFR commented on GitHub (Apr 3, 2022):
Y'a pas de quoi !
D'ailleurs c'est bizarre la fonction racine cubique de trace que de 0 à +oo en mode complexe.
Et aussi c'est normal que la racine cubique renvoie un complexe (en mode complexe) ?
Par exemple (-1)^1/3 renvoie -1 en Réel et 1/2 + (sqrt(3)/2)*i en mode complexe (Algébrique).
@fmOOmf commented on GitHub (Apr 5, 2022):
Hello.
Normal : oui et non. En tout cas cela s'explique.
Le "problème" c'est que x^3 et racine cubique(x) ne sont pas bijectives (pour employer un gros mot) pour les nombres complexes.
En clair, plusieurs nombres peuvent donner le même x^3.
... donc il y a plusieurs solutions à la racine cubique de -1.
Tu en attendais une (-1) mais il y en a 2 autres.
Tu les trouves facilement en choisissant la forme
mod*exp(i*arg).Racine cubique(-1) = exp(i*[pi +k×2pi])^(1/3)= exp(i*[pi/3 +k×2pi/3])Tu as tes 3 solutions pour k = -1, 0 et 1.
Tu peux t'en persuader en les élevant au cube.
Upsilon choisit d'afficher :
Par analogie, c'est pareil pour les racines carrées dans les réels.
Il y a 2 solutions pour sqrt(1) : 1 et -1.
Pour autant,
Calculsn'en affiche qu'une :sqrt(1) = 1et cela ne choque pas.Bref : pour un calcul, cela ne me choque pas d'afficher une seule des solutions possibles.
Reste à déterminer laquelle afficher. La réelle, s'il y en a, serait effectivement un bon choix.
Je te suggère de créer un ticket dédié, ce post commence à partir en branches et les équipes Upsilon vont attraper des migraines.
Par contre dans une résolution d'équation (app
Equations) il faut être complet et proposer toutes les solutions.Ce sera précisé dans une suggestion d'amélioration pour résoudre les équations d'ordre 3.
@fmOOmf commented on GitHub (Apr 5, 2022):
Et pour le tracé sur [ 0 +inf [ :
Le pb est l'impossibilité de représenter sur un repere (Oxy) les solutions choisies par Upsilon (qui sont complexes pour les x négatifs comme tu l'as vu).