choze bizarre avec element

[loic]

J'en apprends tous les jours!
Bon, ceci vient réparer un léger décalage que j'observais également avec la fonction carrée. C'est parfait!

En revanche, je viens de tester de déplacer un point sur la courbe de x-> tan(x), et là, je dois avouer que cela devient très aléatoire. Le point ne cesse de "sauter" d'une branche à l'autre.

[loic]

Tiens, nouveau truc qui semble pas normal (ah.... la fonction inverse ):

Chez moi, plot(1/x,nstep=6) gèle l'interface...
Pas de segmentation fault, surement une boucle infinie ou quelque chose du même genre.

[parisse]

j'essaierai demain, mais ici ça semble marcher, peut-etre un problème avec l'autoscale?
Sinon, la projection sur une courbe, ça marche si on peut résoudre l'équation tangente au point de la courbe perpendiculaire au segment joignant le point au point de la courbe. Ce qui explique les messages dans la console à propos de Schur (appelé pour résoudre une équation polynomiale pour la projection sur x->1/x) ou sans doute le cas de la fonction tan (où on ne peut pas se ramener à une équation polynomiale, et c'est donc le solver numérique qui doit être appelé).

[loic]

En fait, ce que j'ai ici est surprenant:

Code : Tout sélectionner

a:=plot(tan(x)):;
coordinates(element(a)+(0.772727+i*2.36279))

Voici trois résultats obtenus en validant ces deux lignes plusieurs fois de suites

Code : Tout sélectionner

"Done",[-5.0,3.38051500625]
"Done",[5.78006163551,-0.550365356483]
"Done",[1.272727,3.25497425083]

D'où mon phénomène aléatoire... ça vient de chez moi ou y a-t-il une explication rationnelle??

[parisse]

Je n'ai pas tracé ce cas particulier, mais ça n'a rien d'étonnant, le solveur numérique doit être appelé, or il utilise le générateur aléatoire pour avoir un point de départ lorsque le point de départ par défaut ne s'approche pas d'un bassin d'attraction d'une racine.

[loic]

Si je comprends bien, ça déconne parce que pour trouver le projeté, le CAS est amené à résoudre ici une équation qui va faire intervenir des tan

En faisant appel au solveur numérique (c'est un fsolve en qq sorte??), il y a une erreur introduite au final, d'où le fait qu'il se goure de branche.

Bon, bon, bon ... Plusierus questions me viennent alors à l'esprit:

1) ça marche vraiment nickel avec la fonction inverse. (Dès qu'on passe sous la première bissectrice, il y a changement de branche)
C'est dû au fait que le solveur reste en symbolique et qu'ensuite, on choisit parmi l'ensemble des points solutions le plus proche de notre position actuelle?

2) Dans le cas de la fonction x->tan(x) et de la commande "coordinates(element(a)+(0.772727+i*2.36279))"
Plutôt que de prendre un nombre aléatoire dans l'initialisation, il y aurait pas moyen plutôt de refiler au CAS l'abscisse 0.5+0.772727?
(le 0.5 correspondant à l'abscisse du point renvoyé par "element(a)")

[parisse]

en effet, en relisant le code je m'apercois que je n'ai pas pris le point a projeter comme valeur initiale de la suite recurrente. Il suffit de changer la ligne 4326 de plot.cc en
vecteur eqv(makevecteur(eq,v[1],re(p,contextptr)));

[loic]

Effectivement, cela améliore nettement les choses.
Lorsqu'on déplace un point sur une branche, il y a nettement moins de saut, mais il y a encore des moments d'instabilité:

Par exemple:

Code : Tout sélectionner

a:=plot(tan(x))
A:=element(a)+(-4.61364+i*-3.11448)

Qui renvoie un point d'affixe -8.83139323617+0.674468911937*i ce qui n'est pas du tout sa place en théorie...

Ne pourrait-on pas commencer, avant la résolution, par rechercher dans le path de la courbe les deux abscisses consécutives x_1 , x_2 qui encadrent la position actuelle afin de refiler au solver un intervalle de recherche [x_1,x_2]?

[loic]

Au fait, pour:

Code : Tout sélectionner

plot(1/x, nstep=6)

ça venait de chez moi ... oups

[parisse]

Je ne pense pas que ce soit possible d'ameliorer. Parce que comment connaitre un intervalle qui n'aurait qu'une solution pour faire de la dichotomie par exemple? (et meme si on pouvait pour une fonction, comment faire pour une courbe parametree?). On peut se convaincre de la sensibilite de Newton aux conditions initiales sur ce probleme de projection en faisant:
f(x):=-x-4.11364+(1+tan(x)^2)*(-tan(x)-2.56817751016); g:=id-f/f':;
u:=-4.10; for j from 1 to 100 do u:=g(u); print(u); od;
puis en changeant la valeur de u (la valeur esperee est -4.33707692712)
ou en faisant plot(f(x),x=-5..-3), la courbe est presque plate pres de -4.11 donc la tangente ne donne pas beaucoup d'info sur la racine...

[loic]

Oui, je vois le problème en effet.
Ceci conduit d'ailleurs au paradoxe suivant:

Code : Tout sélectionner

a:=plot(tan(x),x=-pi/2,pi/2);
A:=element(a);

avec un point A qui se ballade en dehors du graphe....

En conclusion de tout cela, c'est la méthode de projection qui est à remettre en cause en cas d'objet at_curve.

Bon, reprenons...
On place un point sur un objet. Si j'ai bien compris, le problème va survenir lorsqu'il y a plusieurs branches (essentiellement) c'est à dire que l'objet initial est un VECT
ce que je préconiserai (mais c'est peut-être une idiotie... ):

On parcourt les SYMB de sommet pnt qu'il y a ds le VECT
** Si ce qu'il y a en dessous est un SYMB de sommet at_curve et que la méthode symbolique échoue, on ne cherche pas à projeter mais on parcourt le PATH des points et on repère tous les points su PATH où le saut d'abscisse fait intervenir notre abscisse actuelle. A la fin on sélectionne le point le plus proche sur cette branche.
** Sinon, on conserve l'ancienne méthode.

Sur chacune des branches on a ainsi localisé le point le plus "proche" de notre position actuelle, on ne garde que le meilleur.

J'espère avoir été clair ....

[parisse]

En prenant la discretisation du graphe? Ca pose deux problemes, le 1er c'est qu'il faut retravailler element pour prendre en compte plusieurs branches, ce qu'il ne fait pas actuellement (il prend uniquement l'equation de la 1ere branche), le 2eme c'est que ce ne sera pas tres precis si la discretisation est un peu lache. Bref, je n'ai pas specialement envie de destabiliser tout ce code, en tout cas pour le moment, sachant qu'il est toujours possible d'utiliser un curseur de valeur t et de faire element(a,t).

[loic]

Ok Bernard, je comprends.
Une discrétisation un peu lâche pourrait toutefois être compensée par une petite interpolation mais bon...

Sinon, je suis entièrement d'accord avec toi, la meilleure méthode (et le plus formatrice selon moi) pour parcourir un objet est l'utilisation d'un curseur.
Malheureusement, côté utilisateur, ce n'est pas aussi ergonomique et peu employé dans la pratique....

[alb]

sachant qu'il est toujours possible d'utiliser un curseur de valeur t et de faire element(a,t).

C'est la méthode que j'utilise avec mes élèves dès la seconde.
f(x):=1/x;
C:=plot(f(x));
t:=element(-10..10);
M:=point(t,f(t)) ou M:=element(C,t)
La version instable n'a pas été mise à jour ? M:=element(C,t) me renvoie par exemple plotparam(1.0+i,1.0=-10.0..7.64666108211e-15)

[parisse]

Je n'ai pas mis à jour les versions instables, car je compte les transformer en stable 0.9.8 finales jeudi, je mettrai de nouvelles instables vendredi avant de partir en vacances.
Voila, sinon pour Loic, désolé, c'est juste que je suis à peu près sur que pour faire ce genre de changements, meme si ça semble relativement simple, il faut réécrire entièrement le code de element et projection, avec à la clé un paquet de bugs à corriger pour retrouver la fonctionnalité actuelle. C'est juste trop chronophage pour moi!
Peut-etre qu'il existe une solution intermédiaire qui consisterait à réécrire l'équation donnant le point de projection pour avoir une convergence correcte de Newton?