Forum TI-Planet.org

Afyu a écrit:Edit : en même temps, si tu choisis une échelle logarithmique pour la partie haute du graphique mais pas pour la partie basse, ça parait bizarre...

Les deux axes sont bien en log.

redgl0w a écrit:Le stack sur numworks a bien une valeure écrite dans le code : on peut la trouver sur ces lignes là https://github.com/numworks/epsilon/blob/edafa0e15555bdd024660e78e36756651bd85438/python/port/port.cpp#L120-L144.

Merci.

Cela pourrait être une piste intéressante pour estimer la taille de stack pour les concurrents faisant tourner un système à code source fermé.

Sauf que comme il y a apparemment 2 types d'erreurs différentes renvoyées...

Afyu a écrit:D'accord. Comment fais-tu pour savoir que ce n'est pas le 1024 ?

Le 1024 correspond au pystack, qui est ajouté en plus du stack uniquement sur emscripten (le simu web).

Oui, j'ai vu que le test sur le simu web donnait sur ce test des valeurs qui n'avaient absolument rien à avoir avec celles obtenues sur calculatrice.

D'où le fait que le test NumWorks est le seul illustré par des photos et non des captures d'écran.

critor a écrit:

Afyu a écrit:Edit : en même temps, si tu choisis une échelle logarithmique pour la partie haute du graphique mais pas pour la partie basse, ça parait bizarre...

Les deux axes sont bien en log.

Effectivement. Je voulais dire que si tu avais choisi une échelle logarithmique pour le haut du graphique (pas le choix, à cause du 5362) mais une échelle normale pour le bas du graphique (pour mettre en évidence la grande(!) différence entre 28 et 128), alors ça aurait donné un graphique incohérent qui utilise deux échelles différentes pour mesurer un même paramètre. Donc finalement il n'y avait pas trop d'alternative possible et les deux échelles en logarithme c'est cohérent