Ce programme est sous licence Creative Commons 2.0 BY
Description en français :
/!\ Les versions précédentes sont obsolètes ! Cette mise à jour est un programme réécrit de A À Z (plus dans Historique des versions) /!\
This description is available in English.
N'hésitez pas à envoyer des commentaires, questions, ou encore notes !
Le programme fonctionne parfaitement sur Casio Graph 35+E, Graph 75(+E), et Graph 90+E (Dites-moi si le programme fonctionne aussi sur des autres modèles !)
Le programme sert à calculer les limites de fonctions en ± ∞, en un réel - et calcule automatiquement toute asymptote horizontale, verticale ou oblique !
Les réponses obtenues peuvent être exprimées sous forme fractionnaire - avec ou non un facteur π (en appuyant sur F1). Par exemple lim (x→-∞)(arctg x) = -π/2.
N'hésitez pas à regarder le menu Help.
Utilisation (LISEZ-MOI)
Cliquer pour enrouler
Ce programme utilise les variables A~P & X, Y1, f1~f2, et le radiant.
Dans le menu du programme "LIMITES", entrez une nouvelle fonction afin de calculer sa limite. Si cette fonction est déjà présente dans Y1, appuyez sur (2) dans le menu . Vous pouvez donc utiliser des constantes dans vos fonctions qui ne sont pas utilisées par le programme, et les sous-appels à d'autres fonctions (graphiques) sont bien évidemment possibles.
Vous devrez toujours sélectionner les limites à calculer : à gauche et/ou à droite d'une abscisse; en + et/ou - ∞. Après la résolution de celle(s)-ci, il vous est possible d'exprimer la réponse obtenue sous forme fractionnaire, avec ou non un facteur π, en appuyant sur la touche (F1). Cela peut être 23/25 comme -2π/9. Utilisation du programme Number to Fraction. N'hésitez pas à en abuser, car une réponse "1.1" peut cacher la fraction "7π/20" ! Ce résultat fractionnaire n'est pas affiché automatiquement, car peut créer quelques pépins pour des valeurs entières.
Les limites en un réel se calculent quasi instantanément (et prend en compte les "sauts" possible de la fonction dus à la précision de calcul), et les asymptotes verticales sont détectées et affichées automatiquement.
Les limites en l'infini demandent plus de temps : environ 15~20 secondes pour les fonctions normales/classiques (par exemple sin log x) contre ~50 secondes (voire plus) pour des méchantes.
Le programme gère les erreurs math - dépassements arithmétiques ! Par exemple la limite de la fonction X^X^X donne une bonne réponse en + et -∞ (le dépassement arithmétique se faisant à X=10).
Fonctions non supportées (LISEZ-MOI)
Cliquer pour enrouler
Toutes les fonctions présentes dans le menu OPTN→CALC (excepté Int÷ et Rmdr) ne peuvent être utilisées pour une limite en ∞, ou une Erreur Syntaxe arrêtera le programme.
Ces fonctions sont donc : Solve, d/dx, d²/dx², ∫dx, SolveN, FMin, FMax, Σ, logab.
Les limites en un réel quant à elles fonctionnent avec absolument toutes les fonctions.
Malheureusement, quelques - très - rares limites ne sauraient être résolues correctement, ce qui est le cas par exemple de lim (x → +∞) (tan x). Le problème vient du fait que cette fonction effectue des sauts de trop grande ampleur en des abscisses fort rapprochées.
N'hésitez pas à me dire si vous trouvez une autre limite dans le même cas !
Algorithmes
Cliquer pour enrouler
- Limites en un réel :
Appelons R l'abscisse vers laquelle tend x, et f(x) la fonction sur laquelle porte la limite. On itère à partir de f(R-ln 0.97) - ln 0.97 ~= 0.03 - en divisant par 2 le logarithme chaque fois, jusqu'à ce que :
# cette division (ln/2) atteigne 1E-9
# les images de 2 itérations successives ont une différence inférieure à 1E-5 (la réponse à la limite sera donc un réel)
# la valeur absolue d'une image est supérieure à 1E20
# un saut a été détecté (=erreur de la calculatrice) : si la différence des images de 2 itérations décroît, puis que la nouvelle différence est plus grande d'un facteur 6/5 et enfin que la différence des images de la prochaine itération est strictement nulle, alors la boucle est arrêtée avec les infos d'avant ce saut (image et différence). Cela est utile par exemple pour la fonction "(1-cos x)/x²" (qui n'est pas la seule !) : f(1E-6) donne 0, alors que ~ 1/2 est attendu
Une fois sorti de la boucle, la dernière différence définit si le résultat de la limite est un réel (<0.1) ou un infini (>0.1).
- Limites en l'infini :
Ici on procède par étapes :
# on établit d'abord l'abscisse maximale de la fonction à ne pas dépasser (avant une Erreur Math).
# on calcule si la limite a un sens/existe (pas comme sin x) grâce à une série de FMax FMin sur 2 domaines : un réduit (typiquement de 34 à 35k), qui nous sert à délimiter les bornes des images, et l'autre à sa suite jusqu'à l'abscisse max du point précédant. Si un minimum ET un max sont plus importants (ou ont une image égale) (à une erreur près), alors on considère la limite comme inexistante (elle ne possède donc pas de réponse)
# on passe quelques calculs si au plus un extremum a été retrouvé (à une erreur près) à une plus grande abscisse - sinon, les 2 extrema du domaine plus grand sont moins importants que ceux du réduit. La résultat de la limite sera un réel
# les cas encore non traités sont : les fonctions (dé)croissantes tendant vers un réel, et les fonctions tendant vers un infini. Pour les différencier, définir un seuil sur la pente (ou différence entre 2 images) n'est vraiment pas l'idéal (voir log log log x et 1E9/x). On va donc utiliser cette différence pour définir un seuil au niveau des images : si la fonction "passe de l'autre côté" de celui-ci, alors elle tend vers un infini
# des étapes supplémentaires sont nécessaires pour calculer : le réel vers lequel tend la fonction (dont je passe les détails) / l'asymptote horizontale possible / l'asymptote oblique possible.
# pour le calcul des 2 asymptotes, on considère chacune leur équation (avec des arrondis uniquement pour l'oblique). En gros on regarde si la fonction reste du même côté, et si oui alors il y a bien asymptote.
- Affichage arrondi du résultat :
J'utilise une fonction spécifique pour arrondir les valeurs à 1E-4 et ne garder que les 4 premiers chiffres significatifs. Il faut juste savoir que les E11 servent uniquement à jouer avec la précision des résultats temporaires de la calculatrice. Vu qu'elle n'enregistre que 15 chiffres significatifs, le E11 permet de "supprimer" les décimales trop petites. Vous n'aurez pas plus de commentaires de ma part . 10^Intg log Abs (X+Not X)×(RndFix(X,3)×10^-Intg log Abs (X+Not X)+E11-E11
- Affichage fractionnaire du résultat :
J'utilise aussi mon autre programme dans celui-ci Number to Fraction, avec une plus grosse erreur permettant de trouver la majorité des fractions sans pour autant avoir la valeur exacte de la limite. Crée quelques rares pépins qu'on ne voudrait pas forcément, mais je ne trouve pas ça dérangeant car ça se voit tout de suite qu'il y a eu un souci, et c'est l'utilisateur qui a cliqué sur le bouton pour effectuer cet affichage. On peut donc espérer qu'il le fasse uniquement sur des valeurs décentes !
Améliorations possibles
Cliquez pour recouvrir
Le programme, bien qu'il réponde correctement à énormément de limites, a ses propres faiblesses. Des idées pouvant possiblement améliorer son fonctionnement (des plus importantes aux moindres) :
- Ne plus le baser sur du calcul, mais sur une analyse de chaîne de caractères. Devrait être une très grosse amélioration. +: tan x ne poserait plus de problème; -: très long et compliqué à faire, car le but de mon programme est de supporter toutes les fonctions disponibles sur Casio (y compris les opérateurs booléens, les fonctions quasi jamais utilisées etc).
- Remplacer les arrondis effectués (par quoi, je ne sais pas x)
- Changer les facteurs d'itération (des limites en un réel = 1/2; et des limites en l'infini tendant vers un réel = 2) et les seuils d'erreurs. Je ne pense pas que cela apporte tellement de changement, et en plus les 2 se complètent l'un l'autre - (si un doit être changé, alors l' autre aussi).
Très certainement plein d'autres choses, mais j'ai oublié, vu le temps que la version A m'a prise ...
Historique des versions
Cliquer pour enrouler
Versions obsolètes
Versions obsolètes
Beta 3.0 Toute première version "publiée".
Les limites en ± ∞ sont séparées, une en + ∞ et une en - ∞
A 1.0
Les limites en ± ∞ sont ensembles
A 1.1
Possibilité de calculer les asymptotes obliques
2.0 (4444 octets)
Possibilité de calculer une limite en un réel seulement à droite ou seulement à gauche (lorsque la fonction contient √ ou *√ )
3.0 (env. 3200 / 3584 octets)
Possibilité de calculer une limite en ± ∞ seulement en + ∞ ou seulement en - ∞ (lorsque la fonction contient √ ou *√ )
Possibilité de calculer les asymptotes obliques seulement en + ∞ ou seulement en - ∞ (lorsque la fonction contient √ ou *√ )
Possibilité de copier la fonction entrée en Y1 (première fonction dans le menu Graph de votre calculatrice) !
Optimisations.
3.1 (env. 3200 / 3588 octets)
Si on calculait une asymptote oblique sans écrire de √ ou de *√ on obtenait seulement le résultat en -∞ en 3.0, mais plus maintenant.
4.0 (4188 / 4544 octets)
Possibilité de contourner les erreurs math avec les fonctions exponentielles.
5.0 (3352 / 3684 octets)
Support des fonctions exponentielles (plus de "contournement") sauf pour les asymptotes obliques.
Plus facile d'utilisation.
Reconnaissance de limites impossibles (ex : lim (x → +∞ ) (sin x) ).
5.1 (3536 / 3880 octets)
Support des fonctions exponentielles dans le menu asymptotes obliques.
Correction de quelques bugs de la 5.0.
6.0 (4096 octets)
Un peu de réaménagement au niveau du rendu (maintenant, tous les menus donnent d'abord en x →-∞ puis x → +∞), et aussi au niveau du code.
Le menu Lim x → ±∞ est beaucoup plus précis pour les asymptotes horizontales qu'avant, ce qui permet d'exprimer enfin les résultats obtenus avec des π en appuyant sur [F1] à la fin du calcul (par ex Lim (x→+∞) (arctg x) = 0+π.(1/2) ). Sous forme a+π.(b/c), a varie de -9 à 9; b de -11 à 11; et c de -12 à 12.
N'utilise plus que la fonction graphique Y1 - plus de chaînes de caractères - et demande maintenant à chaque fois s'il faut calculer la limite à gauche, à droite ou les 2.
Bonne reconnaissance des asymptotes horizontales (Lim (x→+∞) (sin x / x) ne possède pas d'A.H mais tend bien vers 0).
Plus de problème des limites en un réel (par ex Lim (x→0) (e^(1/x)) n'a plus d'erreur math ).
6.1 (4144 octets)
Corrections de multiples erreurs de calculs de la 6.0.....
6.2 (4168 octets)
Version 6.1 corrigée (on ne savait pas calculer les asymptotes obliques dû à une erreur de calcul… ).
On n'obtient plus d'erreur argument quand on utilise la fonction d'affichage avec des π (le texte dépassait de l'écran).
Besoin d'un peu moins de précision dans la fonction d'affichage avec des π (sans augmenter le risque d'erreur).
6.3 (4148 octets)
L'unique changement de cette version est la diminution de précision lors du calcul de limites en réel pour éviter les erreurs (ou plutôt fausse réponse) de la calculatrice elle-même. Ex. : calculer la fonction f(x) = (1 - cos x) / (x^2) avec x = 1E-6. Et la calculatrice vous donnera comme réponse 0 au lieu d'une valeur proche de 1/2 (qu'il faudrait obtenir). Le problème vient donc bien de la calculatrice et non du programme (celui-ci ne savait d'ailleurs pas comment interpréter ce résultat...).
Version A (3664 octets)
On peut bien considérer ça plus comme un nouveau programme qu'une mise à jour. En effet celui-ci a été réécrit totalement, jouant avec de nouveaux algorithmes. Les anciennes versions (devenues dès lors obsolètes - et de loin - par rapport à ce nouveau programme) reflétaient mon grand manque d'expérience et ma naïveté. Les études allant avec cette "mise à jour", j'ai acquis assez de connaissance à mon impression pour faire un programme décent. Veuillez m'excuser pour les bourdes commises auparavant. Notez que cette version A utilise maintenant les String afin de gérer les erreur math des dépassements arithmétiques (voir mon tuto). Il y a besoin de 6000 octets libres - seulement en mode x→∞ - (3k dans RECURRENCE et 3k pour Mat Ans). Si ceci n'est pas possible, on peut laisser appuyer la touche lors du choix du signe de ∞, cela prendra des abscisses par défaut d'abscisses pour calculer la limite. Notez que cette méthode est tout de même déconseillée.
Pour les limites en ∞, prend environ 15 secondes de calcul pour les fonction "classiques" et 55 sec pour les méchantes. Donne automatiquement tout ce qu'il y a à savoir sur une limite : asymptote horizontale, verticale, oblique, et possibilité d'obtenir la réponse à ces limites sous forme de fractions avec - ou non - un facteur π (petite modification du programme Number to Fraction).
Bien évidemment les limites en un réel se font quasi instantanément, et supportent aussi les sauts causés par la précision des calculs de la calculatrice (comme la fonction (1-cos x)/x² qd x→0).
Pour donner une idée, log log log x, sin log x, sin x*e^x et 1E9/x qd x→∞ donnent tous les 4 une bonne réponse .
Utilise les variables A~P, Str 1~2, Y1, f1~f2, et le radiant.
Version B (3520 octets)
Du plus important au moindre changement :
Beaucoup plus facile d'utilisation ! L'utilisateur ne doit plus tapoter ou maintenir suivant si la calto a 6 ko de mémoire libre. Finies les crampes
N'a plus du tout besoin des 6 ko ! En effet les fonctions de récurrence ont été jetées par-dessus bord ! Tout simplement : pour détecter les dépassement il y a plus simple et beaucoup moins lourd.
Résultat grandement affiné pour les limites en ∞ tendant vers des réels.
Plus de changement de priorité des opérations (le seul problème était les multiplications implicites).
N'utilise plus de String !
Plus d'Erreur math (limites en ∞) lorsque l'abscisse maximale (avant dépassement arithmétique de la fonction) est ≤ 5, fallait la vouloir celle-ci...
Les limites en ∞ sont considérées sans réponse si l'abscisse maximale est < 1.
Utilise une variable en plus : X. Saviez-vous que jusqu'ici le programme ne changeait pas sa valeur ?
Version B2 (3396+112 octets)
Correction d'une petite gaffe de la précédente version pour les limites en ∞ qui ont un dépassement arithmétique très petit (<10).
Toute limite ∞ de fonctions non définies au dessus d'une abscisse = 1 sont considérées indéfinies. Dès lors vous pouvez sélectionner les 2 signes ∞ (par ex pour log x) sans vous soucier d'une Erreur math (qui survenait dans les précédentes versions).
Je tiens à remercier LePhenixNoir, Manolo, Sentaro21 pour leur aide sur ce topic
Et merci à Totoyo pour son cours de programmation qui m'a bien aidé
Faites absolument ce que vous voulez de ce prog, tant que vous mettez un lien vers cette page-ci ! Merci ! CC 2.0 BY
English description:
Feel free to send comments, questions, or notes!
The program works perfectly on Casio Graph 35+E, Graph 75(+E), and Graph 90+E (Let me know if the program works on other models too!)
The program is used to calculate the limits of functions in ± ∞, in a real - and automatically calculates any horizontal, vertical, or oblique asymptote!
The answers obtained can be expressed in fractional form - with or without a π factor (by pressing F1). For example lim (x→-∞)(arctg x) = -π/2.
Feel free to look at the Help menu
Usage (READ ME)
Click to roll
This program uses the variables A~P & X, Y1, f1~f2, and the radiant.
In the "LIMITS" program menu, enter a new function to calculate its limit. If this function is already present in Y1, press (2) in the menu . You can use constants in your functions that are not used by the program, and sub-calls to other (graphical) functions are of course possible.
You will always have to select the limits to be calculated: to the left and/or right of an abscissa; in + and/or - ∞. After solving these, you can express the answer obtained in fractional form, with or without a π factor, by pressing the (F1) key. This can be 23/25 as well as -2π/9. Using my Number to Fraction program. Feel free to abuse it, because an answer "1.1" can hide the fraction "7π/20"! This fractional result is not displayed automatically, as it can create some glitches for integer values.
The limits in one real are computed almost instantaneously (and takes into account the possible "jumps" of the function due to the computation precision), and the vertical asymptotes are detected and displayed automatically.
Limits in infinity require more time: about 15~20 seconds for normal/classical functions (e.g. sin log x) versus ~50 seconds (or more) for nasty ones.
The program handles math errors - arithmetic overshoots! For example the limit of the function X^X^X gives a good answer in +and -∞ (the arithmetic overshoot being at X=10)
.
Unsupported functions (READ ME)
Click to wrap
All functions present in the OPTN→CALC menu (except Int÷ and Rmdr) cannot be used for a limit in ∞, or a Syntax Error will stop the program.
These functions are therefore: Solve, d/dx, d²/dx², ∫dx, SolveN, FMin, FMax, Σ, logab.
As for the limits in a real, they work with absolutely all functions.
Unfortunately, some - very - rare limits cannot be solved correctly, which is the case for example of lim (x → +∞) (tan x). The problem comes from the fact that this function makes jumps of too large a magnitude at very close abscissas.
Don't hesitate to tell me if you find another limit in the same case!
Algorithms
Click to wrap
- Limits in a real:
Let's call R the abscissa to which x tends, and f(x) the function to which the limit relates. We iterate from f(R-ln 0.97) - ln 0.97 ~= 0.03 - dividing the logarithm by 2 each time, until :
# this division (ln/2) reaches 1E-9
# the images of 2 successive iterations have a difference lower than 1E-5 (the answer to the limit will thus be a real)
# the absolute value of an image is greater than 1E20
# a jump has been detected (=error of the calculator) : if the difference of the images of 2 iterations decreases, then the new difference is bigger by a factor 6/5 and finally the difference of the images of the next iteration is strictly null, then the loop is stopped with the information of before this jump (image and difference). This is useful for example for the function "(1-cos x)/x²" (which is not the only one !) : f(1E-6) gives 0, while ~ 1/2 is expected
Once out of the loop, the last difference defines whether the result of the limit is a real (<0.1) or an infinity (>0.1).
- Limits in infinity :
Here we proceed by steps:
# we first establish the maximum abscissa of the function not to be exceeded (before a Math Error).
# we calculate if the limit has a sense/exists (not like sin x) thanks to a series of FMax FMin on 2 domains : one reduced (typically from 34 to 35k), which is used to delimit the limits of the images, and the other one following it until the max abscissa of the previous point. If a minimum AND a max are larger (or have an equal image) (within an error), then the boundary is considered non-existent (so it has no answer)
# we pass some calculations if at most one extremum has been found (to within one error) at a larger abscissa - otherwise, the 2 extrema of the larger domain are less important than those of the reduced one. The result of the limit will be a real
# the cases not yet treated are: (de)increasing functions tending to a real, and functions tending to infinity. To differentiate them, defining a threshold on the slope (or difference between 2 images) is really not ideal (see log log log x and 1E9/x). So we will use this difference to define a threshold at the level of the images: if the function "passes on the other side" of this one, then it tends towards an infinity
# additional steps are necessary to compute : the real towards which the function tends (I skip the details) / the possible horizontal asymptote / the possible oblique asymptote.
# for the calculation of the 2 asymptotes, we consider each one their equation (with rounding only for the oblique one). Basically we look if the function stays on the same side, and if yes then there is an asymptote.
- Displaying the rounded result :
I use a specific function to round the values to 1E-4 and keep only the first 4 significant figures. You just have to know that the E11 are only used to play with the precision of the temporary results of the calculator. Since it only stores 15 significant digits, the E11 is used to "remove" decimals that are too small. You won't get any more comments from me . 10^Intg log Abs (X+Not X)×(RndFix(X,3)×10^-Intg log Abs (X+Not X)+E11-E11
- Fractional result display:
I also use my other program in this one Number to Fraction, with a bigger error allowing the majority of fractions to be found without having the exact value of the limit. Creates some rare glitches that you wouldn't necessarily want, but I don't find it annoying because you can tell right away that there was a glitch, and it was the user who clicked the button to make this display. So we can hope that he only does it on decent values!
Possible improvements
Cliquez pour recouvrir
The program, although it responds well to many limitations, has its own weaknesses. Ideas that could possibly improve its functioning (from the most important to the least):
- No longer base it on calculation, but on string analysis. Should be a very big improvement. +: tan x would not be a problem anymore; -: very long and complicated to do, because the goal of my program is to support all functions available on Casio (including boolean operators, functions almost never used etc).
- Replace the rounding done (by what, I don't know x)
- Change the iteration factors (limits in a real = 1/2; and limits in infinity tending to a real = 2) and the error thresholds. I don't think this makes that much of a change, and besides the 2 complement each other - (if one needs to be changed, then so does the other).
Most likely a lot of other things, but I forgot, since version A took me so long ...
If you want to see the version history, sorry but you'll have to see the page in French!
Do absolutely anything you want with this prog, as long as you link to this page! Thank you! CC 2.0 BY
Oki, je ferai de toute façon quelques tests comme toujours (plus de tests, et plus poussés aussi dès que j'aurai fini de mettre le prog au propre) sur les 2 méthodes différentes pour voir ce que ça donne aussi.
Ce que je peux faire aussi, c'est dans un premier temps mettre un seuil assez faible (pour éviter tous les problèmes pour lesquels la calto renverrait qqch inattendu) pour déterminer la divergence, puis pousser ce seuil (si la fonction converge) afin d'affiner le résultat jusqu'à la précision voulue ou jusqu'à ce que la valeur "saute". Ça permet par ailleurs de mettre plus de côté (ne pas calculer des points trop loin) des fonctions comme ln x, etc.
P.S. J'avance bien pour le moment, je viens tout juste de finir la partie Limite vers Réel. Je regrouperai Asymptotes Obliques et Limite vers Infini en un seul écran pour plus de facilité.
Dans les limites en l'infini, certaines fonctions ne converge vers rien du tout (c'est le cas de sin x). Dès lors (dans "l'ancienne" version), à partir de l'abscisse où le prog a déterminé si la fonction tendait vers ∞ ou un nombre, je vais calculer les images jusqu'à 10 abscisses plus loin avec un pas fractionnaire et voir si ces images sont fort éloignées ou non. Cela permet d'écarter la fonction sin x.
Malheureusement, ceci pose un autre problème : qu'en est-il de sin x + √x, qui tend bien vers +∞ malgré ses nombreuses "vaguelettes" ?
J'ai pensé à séparer ces 2 cas grâce à une minoration (ou majoration) : par exemple, on prend le minimum local suivant, et on regarde si on peut retrouver cette valeur.
Comment s'assurer que le prog, ne connaissant que des valeurs discrètes, sache si la même image peut être retrouvée avec des abscisses plus grandes ?
Si trop compliqué, essayer en utilisant SolveN() (pour ne pas recevoir d'erreur) et les bornes appropriées ? Mais est-ce que cette méthode trouvera toujours une réponse s'il y a ?
Peut-être implémenter d'une autre façon, mais pour le moment je sèche un peu...
Je sais, ça fait beaucoup de question en un message
Qu'on soit bien d'accord, ce que tu demandes est impossible : on peut créer un algorithme adversaire qui génère la fonction selon les requêtes que tu demandes et t'induis systématiquement en erreur.
sin(x) + √x est pas particulièrement méchante, il n'y a pas de raison que ton algorithme se plante sauf s'il panique dès qu'il voit un peu de décroissance. Par contre un truc comme sin(x²) qui change de signe arbitrairement souvent vers +∞, ou sin(x) · √x qui est plus sympa mais toujours pas uniformément continu, va te poser un problème bien différent. Note que l'inverse est piégeux aussi, eg. sin(ln(x)).
Comment s'assurer que le prog, ne connaissant que des valeurs discrètes, sache si la même image peut être retrouvée avec des abscisses plus grandes ?
Je sais que je me répète mais le problème c'est qu'il est facile de construire des fonctions tordues qui poseront problème. Tu pourras continuer à chasser des contre-exemples pendant des années en prenant toujours plus de propriétés tordues. Peu importe ce que tu fais, les valeurs que tu mesures ne déterminent pas la fonction donc sans hypothèse assez costaud sur la fonction rien ne marchera. Au mieux tu n'auras aucun contre-exemple en tête... pendant quelques temps.
La question devrait donc être : « quelles fonctions peuvent me donner des garanties à partir d'une valeur discrète », et là c'est tout de suite beaucoup plus productif, tu sais par exemple que la continuité uniforme de sin(x) + √x te permet de garantir l'absence de "vaguelettes" si tu prends des points assez serrés, tu sais aussi que la croissance est un facteur donc tu peux étudier lim sup et la lim inf de ta suite de points, etc. N'oublie que tendre vers l'infini ça nécessite de dépasser tout seuil mais ça n'empêche pas la fonction de varier violemment, donc un calcul qui "lisse" les mesures est sans doute nécessaire...
J'ai eu 4 différents moyens pour déterminer si une limite est définie ou non en l'infini, allant de 40 (pour la 1e) à 12 secondes (pour la dernière) de calcul (en moyenne).
J'en suis arrivé à la conclusion que la fonction SolveN() est super importante : en effet, celle-ci gère les erreurs que pourrait retourner Y1, comme sin 1E9. Alors que pour les fonctions FMin() et FMax() (tout de même utiles), même les bornes passées en argument ne doivent pas provoquer d'erreur/de dépassement arithmétique. Il faut donc un compromis entre ces 2 méthodes pour des fonctions comme sin x et sin log x, où la 1e aura un "dépassement arithmétique" bien plus tôt que la 2e.
Ce que je fais donc maintenant, c'est FMin() et FMax() (de ≈100 à ≈100²), puis utiliser SolveN() pour savoir si les images retournées par FMin() FMax() peuvent être retrouvées avec des abscisses plus grandes. En fonction du nombre de points trouvés, on détermine si la fonction est périodique (limite non définie) ou pas. Les fonctions que j'ai testées (et pour lesquelles le prog donne la bonne réponse) : sin x, sin x ÷ x, sin x + √x, sin log x, x * (x<150) + (sin x + 150) * (x>=150). Tout ça, c'est bien beau, mais le prog dit que sin x² converge vers une valeur... Sûrement à cause de SolveN qui n'a pas trouvé de points car trop rapprochés... Je me pencherai plus sur ça, il fallait juste que je l'écrive quelque part .
J'avais essayé (juste pour tester et pour ne pas avoir de problème avec SolveN qui doit être placé dans un sous-prog) de n'utiliser que des FMin et FMax, mais comme dit avant si la borne sup est ≈100² alors ce n'est pas assez grand pour pouvoir déterminer qqch avec sin log x. J'ai déjà pensé à un moyen pour déterminer l'abscisse max supportée par la calto pour une fonction Y1, et ça marche - sans donner d'erreur ! Seul problème, le SolveN qui permet de faire ça prend littéralement 2 minutes (= temps max que cette méthode peut atteindre bizarrement ). Je vais donc éviter.
J'avance j'avance, lentement mais sûrement. J'adore écrire des pavés que peu de personnes lisent, donc je continue encore un peu pour donner une idée d'avancement.
Différents points à faire :
- Augmenter vachement la précision pour les limites convergentes (pcq par ex 1E-4 pour les limites en 1 réel c'est trop, d'ailleurs X^X en 0 donne 0.9994...). En profiter pour mettre au point un moyen permettant de savoir si la calto a renvoyé une mauvaise réponse (en remarquant que ça converge puis il y a un saut) - et si c'est le cas reprendre la dernière bonne valeur. Faire cette 2e partie dans les réels car par encore fait (moi qui croyais trop vite avoir fini ).
- Asymptotes obliques calculées automatiquement si limite = ∞ (= x aussi).
- Exprimer les résultats obtenus en fraction, puis essayer avec une fraction de π (plus de terme additionnel) - tout automatiquement.
- Possibilité de passer complètement 2 étapes : la convergence de la fonction et la représentation fractionnaire; en maintenant n'importe quel bouton de la calto. Je peux comprendre qu'on ait pas envie d'attendre 10 secondes de calculs alors qu'on sait que la limite est définie . Aussi, laisser quand même la possibilité d'avoir les résultats en fraction (F1) - si jamais l'utilisateur a appuyé trop longtemps . Voili voilou !
PROGRAMME DE CONVERGENCE FINI !!!
Bon pas encore de màj, mais tout vient à point à qui sait attendre
D'abord des petites questions (à propos de l'analyse de fonction vers l'infini) si jamais qqn s'y intéresse et saurait me répondre :
- est-ce que démarrer à une abscisse ln 3 x π^3 = T peut être problématique ?
- est-ce que mettre comme borne maximale (pour savoir si f converge) T^2 peut être problématique ? Cela fait env 400, mais le principal "atout" c'est que cette valeur, elle, est supportée par sin x^3...
L'algo que j'ai mis en place a l'air de bien fonctionner (utilise qlq fmin, fmax, et 2 solveN), et je pense qu'il faut prendre en compte dans les questions précédantes que le prog fonctionne même si un extremum trouvé est en fait à une des bornes de l'intervalle de recherche.
Maintenant quelques remarques :
SolveN m'a posé quelques soucis : max 240 octets après l'appel, peut ne pas renvoyer de réponse (même si une des bornes en est une !), et d'autres fois, si une borne (≈150) est une réponse, solveN peut ne retourner qu'une valeur (alors que donnerait 10 valeurs _ toutes ≥ 150 _ avec borne = 1)... Bref il m'a fallu aussi du temps pour gérer tous ces problèmes assez pénibles si on les accumule. Pour éviter les problèmes avec la borne (qui est toujours solution, je l'ai défini ainsi), j'ai juste fait borne + 1. Cela force solveN à aller regarder autre part, même si de nouveau on obtient que 1 réponse (au lieu des 5 voulues). D'un autre côté, je préfère n'avoir qu'une réponse, car 10 sec max au lieu de 2 min (littéralement) c'est vite choisi. Après faut voir si ça pourrait ne rien renvoyer alors qu'il y a qqch, même si ça m'étonnerait (et puis, c'est bon quoi, j'ai envie de passer à autre chose ).
L'algo pour déterminer la convergence pèse 364 octets au total (x2 car ±∞), j'ai pas encore trop regardé pour alléger ça mais il ne doit pas y avoir gd chose à faire. Petit plus : l'algo dit maintenant si une fonction tend vers un infini pour ne pas devoir recalculer ça par la suite (quelque lignes de code en plus pour moins de temps de calcul me paraît pas mal ).
Benchmark
Cliquer pour enrouler
Voici un petit benchmark des différentes fonctions testées (toutes les réponses de l'algo sont correctes) :
"3" : 3 sec
"x" : 4 sec
"x^2" : 5 sec
"1/x" : 8 sec
"log x" : 8 sec YESSSSS
"sin log x" : 14 sec
"sin x + √x" : 24 sec
"sin x" : 26 sec
"(sin x) /x" : 36 sec
Pour les longs messages, je pense que je vais adopter plus de menus déroulants, pour faciliter la navigation entre messages
Petit truc en plus à savoir sur les méthodes FMin et FMax
Cliquer pour enrouler
Petit truc en plus à savoir sur les méthodes FMin et FMax : si la fonctionne donnée en argument est constante, les méthodes retourneront l'abscisse la plus grande.
Ça m'embête pour 2 choses (uniquement en -∞) : Int x tend bien vers -∞, ce qui me gêne par contre c'est que le FMin (même s'il répond correctement) ne renvoie pas la borne inférieure... On pourrait dès lors se dire "Pourquoi la fonction tend-elle vers -∞ alors que le minimum de la fonction n'est se trouve pas à l'abscisse la plus petite ?".
2e chose : +/- la même chose, mais avec Y1="3" par ex : j'aimerais mieux que les méthodes me renvoient l'abscisse la plus grande (en valeur absolue).
J'en suis arrivé à conclure que je peux arranger le prog : ne faire qu'une analyse en +∞ sur la fonction Y2 pour éviter ces "problèmes", d'abord avec "Y1"→Y2 puis "Y1(-x)"→Y2. En plus, trop génialissime : je n'ai plus besoin de 2 sous-prog (±∞), et on récupère environ 350 octets ! Pourquoi n'y avais-je pas pensé plus tôt ?
Petit avis : je ne pense vraiment pas pouvoir publier une nouvelle version d'une programme avant les grandes vacances...
Je suis en effet maintenant en bloque, et vous connaissez la chanson : "priorité aux études"
En plus, plus je teste de fonctions avec l'algo de convergence, plus j'en trouve des méchantes qui détruisent tout... Bien évidemment, cet algo continue à être complété, par exemple pour "Int .1X" l'algo renvoyait convergence vers un réel, car la fonction se fait par paliers... Maintenant même Int .01X est supporté
Mais si on essaie avec des fonctions vraiment méchantes, on peut avoir sin Int X, pour laquelle l'algo renvoie convergence vers réel si en radiant, et divergence si en degré (compréhensible car multiple de 360 plus aisé que multiple de 2π ).
Bref, faut encore que je peaufine cette partie-là (ça ne devrait pas prendre longtemps non plus), mais après il y a tout le reste du prog qui doit suivre.
Et ça, j'ai pas assez de temps avec mes exams.
On continue le progrès, encore et toujours ! toujours pas de màj, c'est "normal"
Encore une modif de l'algo
Cliquer pour enrouler
Eh oui, encore...
J'ai maintenant complètement fini l'algo de limite pour x→±∞ Donc cela veut dire que non seulement l'existence de la limite de la fonction existe (ou non), mais aussi donner son résultat (R ou ∞), et si ==∞ alors affiche l'équation de l'asymptote oblique (s'il y a !). Bien évidemment, "x" n'a pas d'asymptote oblique tout comme "0" n'a pas d'asymptote horizontale
Petite nouveauté : l'enchaînement de tous ces calculs peut être long (≈37 secondes x→±∞ avec f(x)=x). C'est beaucoup, et un moyen d'accélérer tout ça est de demander à l'utilisateur si la limite existe (ie pas "sin x" en x→∞). On arrive à diviser par 2 le temps d'exécution et d'affichage des résultats . Je suis conscient que cela peut représenter un temps conséquent, mais j'ai refait le programme dans l'optique d'être le plus fidèle possible à la réalité, quitte à prendre du temps. Rien ne dit que les choses ne pourraient pas être encore accélérées, mais je commence à ne plus trop avoir d'idée (d'autant plus que ça fonctionne comme il le faut ).
Différencier log log log x (=∞) de 1E9/x (=0) lorsque x→∞
Cliquer pour enrouler
Tout le monde sait (enfin j'espère ) que log log log x tend vers +∞, et 1E9/x tend vers 0. Le problème a été de le faire comprendre à la calto...
En effet, si on fait une bête différence entre les images de 2 abscisses, l'on constate tout de suite que pour la première fonction la différence est plus petite que celle de la 2e, alors qu'elle tend vers +∞ et la 2e vers 0. On peut donc en conclure qu'on ne peut pas se baser là-dessus.
Mon idée est donc : ajoutons (/retirons) à l'image max (/min) la précédente différence calculée (suivant la dé-croissance de la fonction). Cette nouvelle image nous servira à séparer les 2 cas : si elle existe (qu'elle peut être retrouvée avec des abscisses plus grandes), on dira que la fonction tendra vers ∞, sinon vers un réel. Dans les 2 cas un travail supplémentaire est nécessaire afin de déterminer soit l'asymptote oblique (s'il y en a), soit la valeur vers laquelle la fonction tend.
Pam papapapaaaaaam .... Et oui, rejoignez-nous en ces temps de fête,....
Car oui, la mise à jour est enfin tombée !!!!!!!!!!!!
Ça m'aura pris du temps, mais la voilà...
Comme il faut marquer le coup (car ceci n'est pas une petite mise à jour, tout le programme a été réécrit de A à Z), le nom de version est donc "A".
Beaucoup plus de réponses qu'avant, beaucoup moins de problèmes,... 'fin le topo habituel quoi !
Toutes les améliorations de cette version-ci : support des sauts de fonction pour les limites en un réel (comme "(1-cos x)/x²" qd x→0), support des erreurs math dues à des dépassements arithmétiques, affichage du résultat sous forme de fraction (avec ou sans facteur π), et j'en passe (remaniement complet des algos pour différencier log log log x→+∞ tandis que 1E9/x→0)....
Pour donner une idée, log log log x, sin log x, sin x*e^x et 1E9/x qd x→∞ donnent tous les 4 une bonne réponse .
Je vous conseillerais bien de regarder la description du prog, mais celle-ci m'a l'air quelque peu,... incomplète... Est-ce qu'un admin peut regarder ce qu'il s'y passe ? J'ai mis la description voulue dans le fichier joint ici. J'ai aussi changé le gif
@RDP , euhhhh, je ne sais vraiment pas si ça se fait de demander une telle chose, mais j'adorerais voir mon programme dans la prochaine RDP
Et aussi je propose mon programme au Label Planète Casio ! Faut-il que j'envoie un message aussi où redirige le lien du bouton "Proposer ce programme au Label" ?
J'ai corrigé le BBCode dans la description. Oui pour la RDP ça marche comme ça, pour le label tu peux aussi demander, et oui il faut poster un message sur le topic lié
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