KhiCAS: rajoute CAS + Python sur ta Graph 90+E

→ **MyCalcs** profile · by **parisse** » 28 Jun 2018, 19:51

Mise a jour avec une version alpha d'afficheur 2-d (portage de l'editeur d'expression de Xcas). Il n'est pas integre a l'historique, mais permet de defiler des resultats qui occupent plus d'espace. Il y a encore quelques problemes d'affichage.
Avec l'afficheur 2d, l'instruction tabvar (tableau de variations) devient utilisable.

→ **MyCalcs** profile · by AC » 29 Jun 2018, 15:08

ifactor(5412200360) donne comme résultat 2147483647.
Quelle est l'origine de ce résultat?
Bien sûr, 5412200360 est un grand nombre.

→ **MyCalcs** profile · by **parisse** » 29 Jun 2018, 18:33

Je pense qu'il s'agit de bugs lies a une optimisation que j'ai du faire pour liberer un peu de place en memoire pour l'affichage 2d, je m'en occupe.

→ **MyCalcs** profile · by **parisse** » 29 Jun 2018, 20:44

En fait c'etait un bug dans la librairie standard (libc), ca devrait marcher maintenant.

→ **MyCalcs** profile · by AC » 29 Jun 2018, 21:29

En effet, cela fonctionne,maintenant.

→ **MyCalcs** profile · by AC » 03 Jul 2018, 21:22

Dans le catalogue, l'aide de "si" paraît ne pas correspondre à l'instruction.

→ **MyCalcs** profile · by **parisse** » 04 Jul 2018, 06:51

Vu, merci!

Je viens de faire une mise a jour assez importante qui ajoute le support des graphiques (j'ai reussi a liberer une centaine de Ko en changeant une option de compilation, au prix d'une utilisation un peu plus importante de la RAM, place que j'ai mis a profit pour supporter les graphiques).
On peut dorenavant faire le graphe d'une fonction (plot), d'une courbe en parametriques (plotparam) ou en polaires (plotpolar) sans quitter KhiCAS, ce qui evite de devoir saisir a nouveau une expression a tracer et permet de tracer des fonctions non algebriques definies par un programme.
Plusieurs graphes statistiques sont egalement supportes (histogram, barplot : diagramme batons, nuage de points: scatterplot et polygonscatterplot) ainsi que les regressions (lineaire, exponentielle, logarithmiques, polynomiale, puissance). J'ai aussi ajoute les commandes median, quartile1, quartile3, correlation, covariance, je pense que les probas-stats sont raisonnablement supportees a present (il manque les chaines de Markov et les tests du type Khi2, Kolmogorov-Smirnov, Wilcoxon...). Le catalogue a ete un peu reorganise (il meriterait sans doute de l'etre encore).
Bon, cette fois-ci je crois qu'il n'y a vraiment plus de place et ca va etre tres difficile d'en trouver... Ce qui manque le plus je pense, c'est un editeur de programmes en syntaxe Xcas ou/et Python avec l'aide en ligne complete, mais ca pourrait faire l'objet d'un add-in distinct et ca pourrait etre implemente par quelqu'un qui ne connait pas les dessous de Giac.

→ **MyCalcs** profile · by **Lephe** » 04 Jul 2018, 07:33

Est-ce quelqu'un peut me rappeler d'où provient la limite de taille des add-ins ? Je suis fortement incité à penser que modulo la quantité de travail nécessaire (pas forcément beaucoup), c'est contournable ;

- En chargeant du code dans la RAM
- En contournant (un peu salement certes) le MMU comme le fait CGDoom
- En utilisant deux add-ins qui se font du va-et-vient

Si Giac a beaucoup à gagner à avoir plus de place ça vaut peut-être le coup d'essayer.

→ **MyCalcs** profile · by **parisse** » 04 Jul 2018, 08:05

C'est une simple observation, si la taille d'un addin depasse 2M, il n'apparait plus dans le menu donc impossible de le lancer.

→ **MyCalcs** profile · by **Lephe** » 04 Jul 2018, 08:29

Dans ce cas-là il y a peut-être une solution (relativement) élégante pour découper Giac en plusieurs morceaux. La plus grosse difficulté est de linker correctement l'application si on manque vraiment de RAM (troisième situation ci-dessous). Le principe général consiste à mettre du code (par exemple les fonctions graphiques) dans un fichier à part et de « charger » le fichier au démarrage de l'add-in.

- S'il y a assez de RAM disponible, on peut charger tous les fichiers additionnels dans la RAM.
- Sinon, on peut les charger sur demande et les libérer au fur et à mesure (coût temporel à évaluer).
- Enfin, on peut carrément ne pas les charger du tout et y accéder directement depuis la ROM.

La troisième situation est celle qui donne le plus de liberté, mais elle possède un inconvénient : les fichiers dans la ROM sont fragmentés. Quand il s'agit de données auxquelles on accède manuellement avec un pointeur, ce n'est pas très problématique parce qu'on peut construire une table d'association (en gros un MMU miniature) et y accéder en deux indirections au lieu d'une. Mais quand c'est du code, c'est plus compliqué. Je serais d'ailleurs curieux de connaître la répartition code/données dans Khicas. Un coup de objdump -h sur l'ELF révélerait ça.

Je pense être capable d'exécuter du code depuis à peu près n'importe où dans la mémoire ; on a la zone de RAM de l'add-in, le tas, peut-être les 6 Mo de C.Basic et toute la ROM. Si on arrive à charger du code de façon continue dans une de ces zones tout paraît jouable.

Pour la référence, le tas va certainement grossir de 128k à 3M quand l'extension Python de l'OS sortira. À ce moment-là, il n'y aura plus aucune question à se poser et on pourra certainement charger tout le code additionnel dans le tas. Il ne restera que quelques (solides) précautions à prendre au moment de linker l'add-in pour que tout se passe bien.