Le forum de XCAS

A chaque fois quand on fait et/ou refait un graphique (disons plot(sin(x), x=-1..1)), xcas réinitialise certaines propriétés
(p.ex. le pointage en pixels). D'autres propriétés, telle l'auto-échelle ne sont pas réinitialisées.

Peut-on contrôler ce comportement? Je crois, par exemple, que ce serait souhaitable de réinitialiser à chaque fois l'échelle et pas forcément le pointage (d'ailleurs l'auto-échelle rétablit aussi le pointage; ne serait-ce souhaitable de découpler les deux? ).

Pa ailleurs, il paraît que la case "Pixels" dans la fenêtre de config graphique se comporte assez "librement": parfois pour faire disparaitre les pixels il faut cocher la case, parfois il faut la décocher...(il en est de même pour Framebox).
C'est assez perturbant pour des graphes de type "scatterplot".

La dernière ligne : et si je voudrais empêcher l'apparition de la fenêtre DispG une fois pour toutes?

Quelques explications sur les ticks et l'autoscale.
Les ticks servent a se reperer par rapport a l'echelle en x et en y, c'est pour ca que ce n'est pas tres robuste et ecrasable de maniere automatique (si on change d'echelle on n'a pas envie de changer aussi les ticksa chaque fois). Cfg permet de specifier l'espacement, en choisissant soit l'echelle x/y soit le nombre de pixels, mais quand on clique sur OK la valeur est traduite en x/y si on a coche pixels. Le choix de pixels est donc encore moins robuste, il sera immediatement invalide si on modifie la taille de la fenetre. Il est la uniquement pour une utilisation immediatement apres, par exemple pour situer une legende dont la position est donnee en pixels. Changer en quelque chose de plus robuste necessiterait pas mal de travail, en plus pas marrant, en fait ce serait une suggestion a suivre pour une nouvelle classe graphique si on passe a un nouveau toolkit graphique comme par exemple QT.
L'autoscale est execute lorsqu'on cree un nouveau graphique ou qu'on clique sur le bouton auto. Il n'est pas reexecute lorsque la commande a l'origine du graphique est modifiee, parce que l'utilisateur a peut-etre passe un certain temps pour modifier le cadrage (l'autoscale n'etant pas omniscient il peut manquer des proprietes interessantes de la figure) et ne souhaite alors pas devoir recommencer s'il modifie legerement son entree, d'autant plus que cliquer sur auto est tres facile si le cadrage precedent n'est pas pertinent.

Merci pour ces explications. Je comprends que dans le contexte actuel cela représente une approche optimale.
Je ne serais pas indifférent à un projet qui allait dans la direction d'une facilité d'usage/redesign de la partie graphique/GUI etc.
(pas sur sur si mes compétences seraient suffisantes). Mais c'est toute une autre discussion.

J'ai un autre problème, celui de compatibilité graphique de la version windows. Sur des machines différentes j'obtiens des résultats parfois différents et parfois assez surprenants (p. ex. la fenêtre xcas noire pour un graphe 3D basique; plantage pour une commande graphique erronée...et parfois ces choses ne sont pas évidentes à reproduire sur une autre machine...).
La version linux me paraît par contre plutôt stable. Je ne sais donc pas trop que faire ou dire à mes étudiants qui, à l'heure actuelle, travaillent sous linux et le jour d'exam (p.ex. capes) verront la version windows.

Peut-être, à terme, une machine VirtualBox ferait l'affaire? Qu'en pensez-vous?
Actuellement j'en ai une (ubuntu installé à la main). Si seulement je savais tout de suite comment préparer une telle machine prête-à-utiliser et avec xcas dedans... mais si vous trouvez une telle solution viable, je pourrais voir ce qui est possible

Les problemes de graphique 3-d que vous decrivez sont tres certainement dus a une mauvaise configuration de l'acceleration graphique de la carte. D'habitude c'est plutot sous linux qu'on a ce type de problemes. Malheureusement je ne peux rien y faire.
Pour le concours, je suppose que le parc est homogene et qu'un certain nombre de tests ont ete fait, je ne pense pas qu'il faille craindre un probleme de configuration graphique 3-d. Par contre, je ne peux malheureusement pas garantir l'absence de bugs (d'autant plus que la version du concours est deja figee depuis plus d'1 mois): je pense que le risque existe d'autant plus qu'il s'agit de fonctionnalites qui sont moins utilisees (le calcul formel est probablement le plus robuste, la geo 2d et le tableur un peu moins et la geo 3d encore un peu moins). J'espere qu'il n'y en aura pas trop, et s'il y en a, un candidat qui tombe sur un bug ne doit pas hesiter a le montrer et je suis convaincu que le jury en tiendra compte (et apres tout ca fait aussi partie du metier d'enseignant de savoir reagir dans ce cas).
Personnellement, je compile xcas windows avec virtual box sur mac os. Par contre un deploiement de xcas sous windows a base de virtualbox linux ne me parait pas une bonne idee, car ca rebuterait beaucoup d'utilisateurs (taille du telechargement, lancement plus complexe, integration differente) meme si le xcas utilise serait surement plus stable que sous windows.
Pour le redesign de l'interface, c'est un projet de longue haleine, je ne pense pas etre le meilleur pour m'en occuper car c'est d'abord le developpement de fonctionnalites mathematiques qui m'interesse, ce serait bien d'avoir des contributeurs exterieurs qui sont prets a s'y investir sur une longue duree (afin de retrouver les fonctionnalites actuelles de xcas en les rendant plus intuitives).

Merci, ne serait-ce que pour la patience...


Je comprends. Pour tout avouer, j'y songe de temps à l'autre. Mais je suis bien conscient qu'il s'agit d'un projet de longue durée et que l'investissement initial est important. S'il y avait deja un toolkit sur la table, je pourrait essayer de voir... Mais lancer un projet "from scratch" me depasse un tout petit peu... au moins en ce moment...

Pour l'instant je travaille sur un projet relativement simple, une traduction python de pgiac.
J'ai écrit une classe basique qui communique avec giac via un terminal imaginaire (sous linux; d'ou d'ailleurs mes idées d'une machine virtuelle), p.ex.
g=GiacSession()
g.compute("2+2; int(x^2,x):;")
Ce n'est rien, mais à partir de cela on peut ecrire assez facilement quelques applications.
A+.

PS. Incroyable, le forum n'accepte apparemment pas le mot "python" apres un point-virgule Sans blague 501 "Method not implemented".

une interface avec python, ce serait certainement un gros plus!

Je la mettrai en ligne (je posterai un lien cette semaine, j'espere).
A.

Voici une simple interface de giac en python. Plutot basique et incomplete en ce moment...
En revanche, j'ai trouve enfin un moyen de la faire fonctionner sous windows aussi.
Le probleme (sous windows) c'est que je ne sais pas comment laisser la session giac ouverte apres avoir effectue un premier calcul. Pour le moment il n'y donc pas de "vraie" session giac, seulement des calculs separes. Mais pour certains applications ca suffit. Je pense ici a une interface latex de giac comme pgiac (qui suivra).

j'ai rajoute un lien depuis mon site. Pour le cas de windows, il faudrait sauver le contexte et le restaurer, mais cela necessite de modifier icas.cc (et cela aura un impact puisque icas sera charge a chaque commande) ou alors d'ecrire une interface avec le source, ce qui serait evidemment bien plus efficace.

Wow. (j'ai l'intention de maintenir/developper ce code.)



Dans l'etat actuel des choses, ce serait probablement plus efficace si l'utilisateur sauve ses resultats partiels cote python et
reintroduise eventuellement a la main ce dont il a besoin. En fait par defaut GiacSession stocke les resultats.
Sinon, on peut toujours utiliser le mode batch.
Puis, un jour je trouverai peut-etre un moyen de communiquer comme sous linux, mais il faudrai que je regarde un peu plus loin...


Une communication directe serait aussi bien plus elegante. Je reflechie un peu a la question, mais en ce moment je travaile sur des applications ou la vitesse n'est pas critique et la ligne de commandes est suffisante.


Mise à jour : en fait, j'ai enfin trouvé un moyen de communiquer avec giac sous windows; à présent donc, juste pour s'amuser un peu, pygiac.py lancé d'une ligne de commande DOS simule bien une session giac/icas (ce qui est, semble-t-il, impossible en lançant directement giac exe). Sinon, comme avant, "import pygiac.py" donne bien accès au calcul formel en python.