
Si on calcule par exemple argument(1+i) (ou angle(1+i) en anglais), la réponse est 45 en mode degrés, ou la valeur approchée de Pi/4 en mode radians, ce qui est normal.
Si jamais on calcule l'argument d'un nombre réel négatif avec argument(-5) (ou angle(-5) en anglais), la réponse est la valeur approchée de Pi, quel que soit le mode degré ou radians. Donc notamment, si argument(-5) vaut Pi degrés, c'est aussi Pi²/180 radians, ce qui est ridicule.
Visuellement, l'utilisateur comprend tout-de-suite qu'il s'agit de Pi radians, mais un programme aura besoin d'un test supplémentaire pour pallier à ce bug.
Exemple en anglais, qui répond toujours selon le mode de la calculatrice:
:angle(z) // calcul de l'argument avec bug
:If 1r!=1 and Ans=Pi // si on est en mode degrés, et que la réponse est Pi (mauvaise réponse)
:180 // on remplace par 180
D'autres solutions sont possibles selon les besoin du programme.
Pour mon programme, il s'agissait de répondre toujours un angle en radians.
Donc je faisais la convertion valeur/180*Pi si on est en mode degrés.
Il ne faut donc pas faire cette conversion si la valeur initiale vaut Pi, sinon on se retrouve avec la superbe valeur de Pi²/180 radians.
Exemple en anglais:
:angle(z) // calcul de l'argument avec bug
:If 1r!=1 and Ans!=Pi // si on est en mode degrés, et que la réponse n'est pas Pi
:Ans*Pi/180 // on fait la convertion
Donc ça, c'est en attendant que Texas Instruments corrige ce bug visible et grave (calcul faux) dans la prochaine version du système 83+/84+. On peut attendre...