NumWorks, 1ère graphique française programmable en Python

[Zezombye]

J'avoue que la calculatrice est en version beta, mais bon ça nous permet de proposer des corrections avant la full release. Mais pour l'instant perso j'achèterais une calto "terminée" (graph 75 ou TI 83) plutôt que la numworks, parce que j'ai pas trop envie d'avoir une calto version beta pour mon bac (enfin, je l'ai déjà passé le bac, je dis ça pour les autres qui le passent cette année scolaire).

L'année prochaine la numworks devrait être finie et, si tout se passe bien, devrait même concurrencer le haut de gamme étant donné qu'on fera un port d'Eigenmath (ou un autre moteur de calcul formel). Par contre il faudrait effectivement agrandir un peu la RAM/flash.

[parisse]

Eigenmath c'est mieux que pas de calcul formel du tout et ca doit probablement tenir en 200 ou 300K de flash, mais ca reste quand meme un peu limite, meme au niveau du lycee, sauf erreur il n'y a pas de commande limite par exemple.
D'ici l'annee prochaine, il me semble probable que les 526K de app.bin auront bien grossi, si il y a en plus un tableur, une application solve, un moteur de calcul exact ... la taille limite de la flash risque fort d'etre atteinte plus rapidement que prevu. J'espere que les developpeurs de la numworks envisageront de passer au moins a 8M, si possible 16. Et qu'ils ont les reins suffisamment solides pour exister encore dans 18 mois!

[clifward]

Mais bon, c'est quand même aberrant, pour une calculatrice qui se vaut "récente", de mettre si peu de RAM...
Pour moins cher, on a ça : http://www.lesnumeriques.com/telephone- ... /test.html
Et c'est pas la même utilisation... Mais c'est du bien meilleur matos (pas le tel hein, les composants ), pour beaucoup moins cher...
La faute à une trop grande précipitation, trop faible équipe, et temps de dev trop court...

[parisse]

Je serais curieux de savoir quel est le surcout constructeur d'une puce de flash de 16M (ou plus) et de passer la RAM a disons 1M (hors framebuffer video). La avec 256K, donc 32K pour la stack, ca risque d'etre difficile d'ecrire un programme recursif en Python.

[critor]

De nouveaux articles :
http://revue.sesamath.net/spip.php?breve1938
https://www.programmez.com/actualites/n ... eeks-26413
https://www.presse-citron.net/numworks- ... ematiques/

[parisse]

A voir le code source, il n'y a pas beaucoup de matheux chez Numworks, par contre ils ont l'air bon en communication

[clifward]

Fin le mec à la tête du projet, il est polytechnicien... Alors s'il est pas bon en maths... Où va-t-on ?
EDIT : Après... Il se charge peut-être pas du sale boulot....

[Lionel Debroux]

Ceci étant dit, j'ai lu déjà plusieurs fois dans la communauté qu'il y a des codes C++ (beaucoup, apparemment) plus lisibles que celui de giac
Mais ce n'est pas le sujet.

[parisse]

Ah mais je ne pretends nullement que mon code source soit un modele de lisibilite, c'est parfois impossible a concilier avec du code optimise (par exemple quand on deroule une boucle). Par contre je constate que le code source de "poincare" a ete ecrit par des programmeurs qui n'ont pas du faire beaucoup de maths algorithmiques. Par exemple le PGCD:

Code: Select all

...
  if (isnan(f1) || isnan(f2) || f1 != (int)f1 || f2 != (int)f2) {
    return new Complex<T>(Complex<T>::Float(NAN));
  }
  int a = (int)f2;
  int b = (int)f1;
  if (f1 > f2) {
    b = a;
    a = (int)f1;
  }
  int r = 0;
  while((int)b!=0){
    r = a - ((int)(a/b))*b;
    a = b;
    b = r;
  }
  return new Complex<T>(Complex<T>::Float(std::round((T)a)));


deja c'est un peu bete de transtyper en int 32 bits au lieu de 64, ca limite a 2^31, ensuite c'est inutile de tester que f1>f2, le calcul de r devrait se faire avec a%b, et on se demande pourquoi il y a un round a la fin. Pour un algorithme de niveau lycee, ca fait quand meme beaucoup je trouve.

[Adriweb]

Les Pull Requests sur GitHub sont parfaitement acceptées ^^

(j'en ai d'ailleurs fait quelques unes déjà, mais pas niveau maths...)