HIPPOPOTAME
a écrit : le cosh est imposé quand on dérive f(x)=(e^x-1)/(e^x+1)
HIPPOPOTAME
a écrit : Non!! ça c'est ce que croit un naïf utilisateur lambda qui ne sait pas s'en servir.
Sur hp:
commandes de simplifications basiques comme EXPAND, COLLECT, SIMPLIFY, DISTRIB
versus
commandes qui permettent de décider de l'orientation des calculs, comme TRIG qui transforme exp(ix) en cos(x)+isin(x), TSIMP qui fait l'inverse.
le court terme
versus le long terme.
Sur les forums hp, *jamais* un débutant n'a de problème avec les flags. point barre.
Voire chez Casio. 
On a des algorithmes de simplification d'une expression polynomiale.
On a un formulaire de trigo.
On a des formules pour exp/ln. Ce sont des algorithmes et des formulaires indépendant les uns des autres.
>1. Qu'est-ce qu'une "question non trigonométrique"??? "dériver f(x)=(e^x-1)/(e^x+1)"
), pourquoi ne pas le mettre? Tous mes professeurs ont toujours jugé le meilleur élève comme étant celui qui reconnaît le plus de simplifications possible.
La réponse trigonométrique n'est pas la plus simple : cosh est une fonction plus complexe que exp.
Le choix d'introduire de la trigonométrie ne peut être fait que par un homme, un Cas ne peut pas juger de la pertinence de ce choix. Dans plus de 50% des cas, ce ne sera pas pertinent, comme pour prodige-tahoor.
Celui qui me corrige pourrait s'il est de mauvais poil sanctionner l'emploi d'un cosh dans cette question.
Et il aurait raison.
HIPPOPOTAME
a écrit : le cosh est imposé quand on dérive f(x)=(e^x-1)/(e^x+1)
Ce que tu n'as pas compris, c'est que la philosophie du CAS de AMS est totalement différente de celle du CAS de la HP-49.
TI essaye de faire de AMS une "boîte noire". HP essaye de faire de son CAS une "boîte d'outils", de laquelle il faut choisir les outils à utiliser. Personnellement, je pense que la stratégie de TI est la meilleure à long terme:
les ordinateurs deviennent de plus en plus "intelligents", donc ils seront de plus en plus capables de résoudre ce genre de problèmes tous seuls. Comme on peut voir, ça marche déjà assez bien actuellement.
Remets les pieds sur terre! C'est un microprocesseur 68k, pas un "ordinateur qui de nos jours devient de plus en plus intelligent".
Bon, maintenant que tu as défini "stratégie", je peux dire qu'un CAS est censé savoir quelle stratégie employer. Si les exp(ix) conviennent mieux, il devrait les utiliser. Si les cos(x)+i sin(x) conviennent mieux, il devrait les utiliser. Et tout ça en interne.
En externe, il devrait présenter la forme la plus simple, donc ici exp(ix).
Parce que tous ceux qui ont eu des problèmes avec les flags ont laissé tomber et sont partis chez TI. Voire chez Casio.
Mais on peut utiliser le formulaire de trigo pour un calcul d'exponentielles si c'est avantageux! Pourquoi le CAS ne devrait-il pas faire ça?
>1. Qu'est-ce qu'une "question non trigonométrique"???
"dériver f(x)=(e^x-1)/(e^x+1)"
Qu'est-ce qu'il y a de "non trigonométrique" ici?
On demande de dériver, c'est tout.
Donc on dérive de la manière qui convient le plus.
Si on reconnaît le tanh(x/2), pourquoi ne pas l'utiliser? Si on ne le reconnaît pas, mais qu'on tombe sur un résultat qu'on reconnaît comme étant 1/(2cosh²(x/2)) (je n'ai pas mis sech pour éviter une autre longue discussion sur le sech ), pourquoi ne pas le mettre?
Mais pas plus complexe qu'une somme de exp.
Je n'ai aucune idée d'où tu sors ton "plus de 50% des cas".
Le seul cas où ce n'est pas pertinent, c'est si l'utilisateur n'a pas vu les cosh.
Je ne vois pas pourquoi. On attend des réponses simplifiées au maximum. Si on laisse des exponentielles, ce n'est pas simplifié au maximum.
Il n'est pas imposé puisqu'il y a expand qui redonne des exponentielles.
HIPPOPOTAME
a écrit : Mais bon dès qu'on se met à gratter un peu, on sent les limitations. Sur ti il ne me parait pas très réaliste de faire des programmes de calcul formel en basic (je me trompe?).
Ne serait ce que parce que la simplification automatique bousille tout.
Remets les pieds sur terre! C'est un microprocesseur 68k, pas un "ordinateur qui de nos jours devient de plus en plus intelligent".
Rêve...
(D'après ce que j'ai pu constater, un débutant ne connaît tout simplement pas les flags, ou ne s'amuse pas à y toucher. Les flags par défaut sont bien réglés pour les débutants. Donc pas de problème, pas besoin d'y toucher)
Qu'est ce qu'il y a de trigonométrique?
Il n'y a pas de cos, sin, tan, cosh, sinh, tanh, sec, cosech, ..... Donc ce n'est pas trigonométrique, point.
Il n'y a grosso modo qu'une manière de dériver.
Mais parfois plus pertinente, parfois moins pertinente. Le Cas n'en sais rien.
Dans le doute s'abstenir.
C'est sans doute bien plus de 50% en France, et bien moins aux Usa.
Dans la plupart des cas, si.
... mais en effet le C est souvent plus pratique parce qu'on peut éviter la simplification automatique. Mais en composant les tokens à la main. Si on utilise push_sum et compagnie, AMS utilisera automatiquement push_internal_simplify là aussi.
Ce qui rend les ordinateurs de plus en plus "intelligents", ce sont surtout des améliorations au niveau algorithmique, pas seulement la puissance pure.
. La puissance autant que la mémoire disponible sont des limitations incontournables. On n'ira pas faire tourner un algo "intelligent" dernier cri sur un vieil Amstrad d'il y a 15 ans.
Sauf quand la HP-49 refuse de lui répondre parce que les flags ne sont pas bien mis...
Par exemple, j'ai lu des personnes se plaindre que les flags par défaut de la HP-49 sont l'équivalent du mode EXACT, ce qui veut souvent dire "pas de réponse".
Sur TI-89, on est normalement en AUTO: exact quand c'est possible, approché sinon.
>>>Qu'est ce qu'il y a de trigonométrique?
Il n'y a pas de cos, sin, tan, cosh, sinh, tanh, sec, cosech, .....
Donc ce n'est pas trigonométrique, point.
Ce n'est pas une raison de ne pas donner une réponse trigonométrique si c'est la plus adaptée.
Faux. Il y a souvent 2 solutions:
* simplifier, puis dériver (on convertit en tanh, puis on dérive)
* dériver, puis simplifier (on dérive, puis on convertit en cosh ou sech)
et ici, il y a une troisième: dériver sans simplifier, qui est celle que tu sembles préférer ici.
>>> Mais parfois plus pertinente, parfois moins pertinente. Le Cas n'en sais rien.
Je ne vois pas en quoi ce ne serait pas "pertinent".
Dans le doûte, simplifier au maximum.
Si on veut autre chose, on utilise expand.
La France n'est pas le centre du monde. Il y a nettement plus de personnes aux USA qu'en France. Donc ton pourcentage est faux.
Simplifier au maximum implique mettre des cosh quand ça rend l'expression plus courte.
HIPPOPOTAME
a écrit : Mais bon, c'est inutilisable en période normale d'utilisation du Cas (en DS) sauf à avoir un compilateur on-calc. et de toute façon ce n'est pas pratique.
Elle ne donne pas "pas de réponse". Elle renvoie une réponse exacte.
Si ces personnes sont trop faignantes pour ouvrir le manuel et faire un ->NUM, tant pis pour elles.
D'où l'anarchie dans les résultats : on ne sait pas si c'est juste ou approché.
Si c'est une raison. C'est une épouvantable aggression contre le pauvre utilisateur qui croyait naïvement qu'il allait avoir un résultat honnête.
On voit bien les ravages que cause la simplification automatique sur les pauvres tiusers.Comme tu ne t'en rends pas compte, il y a LA dérivation, qui ne se fait grosso modo que d'une manière, et la simplification, qui est un problème annexe.
Et l'esprit avec lequel AMS simplifie est très hautement criticable.
Je vais donner un exemple.
Il y a quelques mois, j'ai dû travailler sur une suite de fonctions de la forme Pn(e^x,x), où les Pn sont des polynômes. La suite était définie par récurrence, je ne me souviens plus trop de la formule, il faudrait que je remette la main sur ce papelard. Enfin bref....
J'ai rédigé en quelques lignes un petit programme pour automatiser le calcul, utilisant bien sûr le Cas.
Et bien il aurait été de fort mauvais goût que le Cas s'autorise à introduire des facéties comme des cosh ou sinh sans que je lui donne mon accord. Voilà.
La "simplification" proposée par les Cas est non injective. Elle détruit de l'information.
>>> Elle ne donne pas "pas de réponse". Elle renvoie une réponse exacte.
... qui souvent est inutilisable. Cf. factorisation. Si on veut une factorisation, on veut une factorisation. S'il n'y en a pas en exact, ben, l'approché est le seul choix pertinent.
>>> Si ces personnes sont trop faignantes pour ouvrir le manuel et faire un ->NUM, tant pis pour elles.
Et ->NUM factorise automatiquement en approché (en combinaison avec FACTOR)?
>>>D'où l'anarchie dans les résultats : on ne sait pas si c'est juste ou approché.
S'il y a un point décimal, c'est approché.
En quoi le cosh n'est-il pas "honnête"???
1. Souvent, il est judicieux de faire une transformation d'écriture avant de dériver. Ici, c'est le cas.
S'il est demandé de dériver, nulle part n'est-il dit que les simplifications d'écriture préalables sont interdites.
2. Après avoir dérivé, on se retrouve souvent avec un résultat assez lourd. Donc il est évident qu'on le simplifie. Sinon, on n'a fait que la moitié du travail.
Si les cosh et sinh rendent l'écriture des termes de la suite plus simple, pourquoi pas?
Beaucoup de simplifications sont non-injectives. Par exemple, en faisant (2x+x)->(3x), on a perdu de l'information. Mais ici, on n'a rien perdu. (e^x+e^(-x))/2<->cosh(x). Ça va dans les 2 sens.
HIPPOPOTAME a écrit :
* Vouloir une factorisation approchée est une affreuse faute de goût
* ->NUM s'obtient en faisant [shift droit]+[ENTER]
* On bascule en mode approché en faisant [shift droit]&[ENTER] (simultané) C'est un raccourci dont on se souvient immédiatement, grace au superbe design du clavier.
1)C'est facile à détecter d'un programme?
// If the result contains floating-point numbers, warn about rounding errors. int questionable_accuracy=!is_free_of_tag(top_estack,FLOAT_TAG);
2) En calculant 100!/99! , 200!/199!, ..... il arrive un moment où la ti raconte des salades. Pas très sérieux....
Ici, ce n'est pas le cas.
C'est à l'utilisateur de décider. Si l'utilisateur a arrangé l'expression dans une forme qui lui convient, la simplification détruirait cet arrangement. Sur Hp, l'éditeur d'équation permet de manipuler "à la main" les expressions. Si à chaque commande du Cas, tout était foutu en l'air, ça ne serait pas très utile....
PARCE QUE PAS, BOUGREDIOU!! J'écris les termes de ma suite sous une forme canonique de polynômes en x et e^x, et non pas sous la forme d'un salmigondi infâme où traînent toutes les fonctions rares et inusitées que le Cas a pu dénicher, ce qui donnerait une suite d'expressions totalement inhomogène et illisible.
ICI, on a rien perdu. C'est un cas particulier.
D'un côté, je suis plus ou moins d'accord. D'un autre côté, si tu as un algorithme qui a besoin de la forme factorisée et qu'il n'y a pas de factorisation exacte (du moins pas sous forme de radicaux), tu fais quoi?
C'est un design affreux! Les combinaisons de touches séquentielles ou simultanées, si elles sont reconnues toutes les deux, sont censées fonctionner de la même manière. Sinon, on surprend pas mal l'utilisateur.
Pour le BASIC, on peut en faire une chaîne Exec relativement courte.
100!/99! -> 100 (correct)
200!/199! -> 200 (correct)
300!/299! -> 300. (correct, mais calculé en approché)
400!/399! -> 400. (correct, mais calculé en approché)
500!/499! -> 500!/499! (correct, mais la simplification pourrait être meilleure en effet)
100000!/99999! -> 100000!/99999! (idem) Je ne vois pas où est ton problème.
Si. C'est judicieux parce que ça simplifie les calculs. Au lieu de faire des calculs compliqués avec la règle des quotients, tu prends une formule trigonométrique directement (ou presque: il y a la dérivée intérieure, mais elle est constante, donc très simple): tanh'=-sech².
Hail et EQW sur TI-89/92+/V200 permettent aussi d'évaluer des sous-expressions et de faire des factorisations/développements dessus. Et malgré la simplification automatique, c'est utilisable.
Question de goût. Le fait de reconnaître des cosh et sinh dans les termes de la suite pourrait révéler des caractéristiques interressantes de ta suite.
Bon, montre-moi un cas où la transformation de (e^x+e^(-x))/2 en cosh(x) perd de l'information qui n'a pas déjà été perdue avant.
HIPPOPOTAME a écrit :
du code binaire...
En tout cas on voit bien que la simplification d'AMS est très criticable
Si j'écris f(x)=e^x+2cosh(x), avec la volonté explicite d'utiliser cette forme (par exemple parce qu'une question suivante étudie e^x+n*cosh(x) ), le Cas perdra définitivement la forme de l'expression dès qu'il s'avisera de changer cosh<->exp.
Mais évidemment ce n'est pas avec cosh/sinh/tanh que les problèmes de simplification sont les plus aigus
>>> du code binaire...
Où est le problème?
Elle n'est pas parfaite, certes. Et là, elle rate vraiment une simplification toute bête. Mais elle n'est pas si mauvaise que ça. Et ici, tout d'un coup, tu râles parce qu'une simplification n'est pas faite, pas parce qu'une simplification est faite...
La transformation se fait dans les 2 sens:
e^x+2cosh(x)=e^x+2(e^x+e^(-x))/2=e^x+e^x+e^(-x)=2e^x+e^(-x)
2e^x+e^(-x)=e^x+(e^x+e^(-x))=e^x+2cosh(x) (On voit que le e^x est en trop - même un CAS peut voir ça, il suffit de comparer les coefficients -, donc on l'"épluche", puis le reste va tout seul.)
HIPPOPOTAME a écrit :
Quand on a décidé de simplifier, on simplifie. Mais là... un coup un entier, un coup un flottant, un coup rien du tout.... c'est se moquer du monde!
