Module TI-Python disponible à l'unité chez Jarrety : 13,50€

→ **MyCalcs** profile · de **critor** » 04 Fév 2019, 12:36

A propos, au cas où ma boîte à lettres soit toujours vide ce soir...

Parmi ceux qui l'ont reçu, quelqu'un peut nous partager quelques photos du module final ? Avant et arrière ?

C'est à peu près tout ce qui nous manquerait pour une annonce 'propre' en page d'accueil.
Bien évidemment, les photos seront créditées.

Merci.

→ **MyCalcs** profile · de **zardam** » 04 Fév 2019, 13:20

Pour le problème de précision, il ne faut rien attendre du coté d'adafruit, c'est "by design" dans la doc : https://learn.adafruit.com/circuitpytho ... pectations

Floating point numbers are single precision in CircuitPython (not double precision as in Python). The largest floating point magnitude that can be represented is about +/-3.4e38. The smallest magnitude that can be represented with full accuracy is about +/-1.7e-38, though numbers as small as +/-5.6e-45 can be represented with reduced accuracy.

CircuitPython's floats have 8 bits of exponent and 22 bits of mantissa (not 24 like regular single precision floating point), which is about five or six decimal digits of precision.

Je vais prendre quelques photos mais je ne suis pas très bon pour ça...

→ **MyCalcs** profile · de **zardam** » 04 Fév 2019, 13:29

→ **MyCalcs** profile · de **critor** » 04 Fév 2019, 18:38

Bonsoir.

Merci beaucoup.

→ **MyCalcs** profile · de **critor** » 06 Fév 2019, 00:02

Le test de performances des QCC 2018 était basé sur un algo de seuil en flottants.
Mais puisque le module TI-Python a une gestion des flottants très inférieure, il ne serait pas équitable de baser un classement des performances numériques des pythonnettes là-dessus.

Partons donc sur autre chose, des entiers (courts) et des listes :

Code: Tout sélectionner: try: from time import * except: pass def hastime(): try: monotonic() return True except: return False def genseed(ndigits): nmax,s,k=5*10**(ndigits-1),0,1 while s<nmax: s+=k k*=2 return s def genarr(ndigits): sd,arr=genseed(ndigits),[] for k in range(1,ndigits): for j in range(ndigits): t=sd%10**k arr.extend([t,-t,10**k-t,t-10**k]) sd=sd//10+(sd%10)*10**(ndigits-1) arr.extend([sd,-sd]) return arr def myabs(x): if x<0: x=-x return x def sgn(x): if x!=0: return x/myabs(x) else: return 0 def sortarr(arr,sdiff): segs=[0,len(arr)-1] while len(segs): iref=segs[0] for k in range(segs[0],segs[1]+1): if sgn(arr[k]-arr[iref])==sdiff: t=arr[iref] arr[iref]=arr[k] arr[k]=arr[iref+1] arr[iref+1]=t iref+=1 if iref>=segs[0]+2: segs.extend([segs[0],iref-1]) if iref<=segs[1]-2: segs.extend([iref+1,segs[1]]) segs.pop(0) segs.pop(0) return arr def test(l,n): timed=hastime() if timed: start=monotonic() start,stop,sdiff,arr=0,1,-1,[] arr.extend(genarr(l)) for k in range(n): arr.extend(sortarr(arr,sdiff)) sdiff=-sdiff if timed: stop=monotonic() return stop-start,len(arr),arr[0],arr[len(arr)//2-1],arr[len(arr)//2],arr[len(arr)-1]

Ligne d'appel utilisée pour le test : test(9,2)

Voici le classement :

TI-Nspire CX CR3- avec micropython : 3.71s
TI-Nspire CX CR4+ avec micropython : 5.48s
NumWorks : 10.50s
Graph 90+E : 14.76s
Graph 35+E/35+USB/75/95 SH4 avec CasioPython : 28.42s
module externe TI-Python : 32.92s
HP Prime G2 : 1min41.60s
Graph 90+E avec KhiCAS : 3min39.64s
HP Prime G1 : 4min29.49s

→ **MyCalcs** profile · de **Lionel Debroux** » 06 Fév 2019, 08:28

En d'autres termes, la plus lente des implémentations native de Python sur ce benchmark-ci, alors que c'est la seule qui utilise du SPFP, beaucoup moins précis. Ca serait donc beaucoup plus lent en DPFP, si bien sûr on parvenait à faire fonctionner du DPFP sur CircuitPython...

→ **MyCalcs** profile · de **Lionel Debroux** » 06 Fév 2019, 12:10

J'essaie de debugger mon CircuitPython trafiqué qui calcule mal, en utilisant la target sim d'un vieux build de GDB 7.9 que j'avais réalisé sur ma machine pour le développement Nspire, il y a des années. Je connais la target sim depuis qu'ExtendeD l'avait utilisée très fructueusement pour les Nspire, cf. https://www.yaronet.com/topics/125502-d ... 4#post-117 .

Je confirme que le fait que les valeurs affichées dans CircuitPython soient stupides n'est manifestement pas un problème de conversion double -> string, puisque si on met les valeurs attendues dans les bons registres avant exécuter la conversion, on obtient la conversion attendue.
A suivre...

Obtention de la représentation binaire des double (sur x86_64, mais c'est la même sur ARM):

Code: Tout sélectionner: $ perl -e 'print (pack "d", 10);' | od -t x1 -A x 000000 00 00 00 00 00 00 24 40 000008 $ perl -e 'print (pack "d", 101);' | od -t x1 -A x 000000 00 00 00 00 00 40 59 40 000008 $ perl -e 'print (pack "d", 101.2);' | od -t x1 -A x 000000 cd cc cc cc cc 4c 59 40 000008

Désassemblage du code dont la simulation m'intéresse:

Code: Tout sélectionner: 0001b648 <float_print.lto_priv.888>: 1b648: b510 push {r4, lr} 1b64a: 0004 movs r4, r0 1b64c: b08a sub sp, #40 ; 0x28 1b64e: 0008 movs r0, r1 1b650: f7f7 f8f8 bl 12844 <mp_obj_float_get.lto_priv.1343.lto_priv.1422> 1b654: 2300 movs r3, #0 1b656: 9301 str r3, [sp, #4] 1b658: 3310 adds r3, #16 1b65a: 9300 str r3, [sp, #0] 1b65c: aa02 add r2, sp, #8 1b65e: 3357 adds r3, #87 ; 0x57 1b660: f008 f8c2 bl 237e8 <mp_format_float.part.0.constprop.172> 1b664: a902 add r1, sp, #8

Il a fallu changer l'adresse de démarrage de l'ELF, octets 0x18-0x1B, de 00 20 00 00 en a0 d1 00 00 (Reset_Handler).

Trace d'exécution:

Code: Tout sélectionner: arm-none-eabi-gdb GNU gdb (GDB) 7.9 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) file ports/atmel-samd/build-trinket_m0/firmware.elf Reading symbols from ports/atmel-samd/build-trinket_m0/firmware.elf...done. (gdb) target sim Connected to the simulator. (gdb) load ports/atmel-samd/build-trinket_m0/firmware.elf Loading section .text, size 0x2da1c vma 0x2000 Loading section .ARM.exidx, size 0x8 vma 0x2fa1c Loading section .data, size 0x130 vma 0x20000000 Start address 0xd1a0 Transfer rate: 1497760 bits in <1 sec. (gdb) break Reset_Handler Breakpoint 1 at 0xd1a8 (gdb) run Starting program: .../ports/atmel-samd/build-trinket_m0/firmware.elf ^C Program received signal SIGINT, Interrupt. 0xf748f550 in ?? () (gdb) set $r0=0 (gdb) set $r1=0x40240000 (gdb) set $pc=0x1B654 (gdb) info registers r0 0x0 0 r1 0x40240000 1076101120 r2 0x0 0 r3 0x67 103 r4 0xffffffff 4294967295 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0xe59ff838 3852466232 r12 0x0 0 sp 0x800 0x800 lr 0xd1e4 53732 pc 0x1b654 0x1b654 <float_print.lto_priv+12> cpsr 0x1000033 16777267 (gdb) advance *0x1B664 0x0001b664 in float_print.lto_priv () (gdb) x/s ($sp+8) 0x808: "10" (gdb) set $r0=0 (gdb) set $r1=0x40594000 (gdb) set $pc=0x1B654 (gdb) advance *0x1B664 0x0001b664 in float_print.lto_priv () (gdb) x/s ($sp+8) 0x808: "101" (gdb) set $r0=0xcccccccd (gdb) set $r1=0x40594ccc (gdb) set $pc=0x1B654 (gdb) advance *0x1B664 0x0001b664 in float_print.lto_priv () (gdb) x/s ($sp+8) 0x808: "101.2"

→ **MyCalcs** profile · de **Lionel Debroux** » 06 Fév 2019, 12:50

A partir du code de float_make_new(), qui est juste au-dessous de float_print() dans objfloat.c, j'ai cherché la définition de mp_obj_new_float(), et je suis tombé sur les différentes définitions de cette fonction en fonction de la représentation des objets MicroPython. Il y en a 4, MICROPY_OBJ_REPR_A à _D. CircuitPython pour cette target utilise MICROPY_OBJ_REPR_C .
Les différentes valeurs possibles sont décrites en détail dans mpconfig.h:

Code: Tout sélectionner: // A MicroPython object is a machine word having the following form (called R): // - iiiiiiii iiiiiiii iiiiiiii iiiiiii1 small int with 31-bit signed value // - 01111111 1qqqqqqq qqqqqqqq qqqqq110 str with 20-bit qstr value // - s1111111 10000000 00000000 00000010 +/- inf // - s1111111 1xxxxxxx xxxxxxxx xxxxx010 nan, x != 0 // - seeeeeee efffffff ffffffff ffffff10 30-bit fp, e != 0xff // - pppppppp pppppppp pppppppp pppppp00 ptr (4 byte alignment) // Str and float stored as O = R + 0x80800000, retrieved as R = O - 0x80800000. // This makes strs easier to encode/decode as they have zeros in the top 9 bits. [b]// This scheme only works with 32-bit word size and float enabled.[/b] #define MICROPY_OBJ_REPR_C (2)

Bref. Il y a peut-être des problèmes additionnels, qu'il faudra découvrir ultérieurement, mais l'utilisation de la représentation C est largement suffisante pour que mp_float_t == double plutôt que float se passe très mal

La représentation D n'est manifestement pas faite pour les plate-formes 32 bits:

Code: Tout sélectionner: // A MicroPython object is a 64-bit word having the following form (called R): // - seeeeeee eeeeffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 64-bit fp, e != 0x7ff // - s1111111 11110000 00000000 00000000 00000000 00000000 00000000 00000000 +/- inf // - 01111111 11111000 00000000 00000000 00000000 00000000 00000000 00000000 normalised nan // - 01111111 11111101 iiiiiiii iiiiiiii iiiiiiii iiiiiiii iiiiiiii iiiiiii1 small int // - 01111111 11111110 00000000 00000000 qqqqqqqq qqqqqqqq qqqqqqqq qqqqqqq1 str // - 01111111 11111100 00000000 00000000 pppppppp pppppppp pppppppp pppppp00 ptr (4 byte alignment) // Stored as O = R + 0x8004000000000000, retrieved as R = O - 0x8004000000000000. // This makes pointers have all zeros in the top 32 bits. // Small-ints and strs have 1 as LSB to make sure they don't look like pointers // to the garbage collector. #define MICROPY_OBJ_REPR_D (3)

et de toute façon, j'ai très vite des erreurs de compilation si je tente de l'utiliser.

La représentation B:

Code: Tout sélectionner: // A MicroPython object is a machine word having the following form: // - xxxx...xx01 : a small int, bits 2 and above are the value // - xxxx...xx11 : a qstr, bits 2 and above are the value // - xxxx...xxx0 : a pointer to an mp_obj_base_t (unless a fake object) #define MICROPY_OBJ_REPR_B (1)

compile du premier coup, sans nécessiter de modifs supplémentaires du code, et le binaire produit est à peine plus gros qu'avec la représentation C:

Code: Tout sélectionner: LINK build-trinket_m0/firmware.elf 1080 bytes free in flash out of 188416 bytes ( 184.0 kb ). 26060 bytes free in ram for stack out of 32768 bytes ( 32.0 kb ). Create build-trinket_m0/firmware.bin Create build-trinket_m0/firmware.uf2 Converting to uf2, output size: 374784, start address: 0x2000 Wrote 374784 bytes to build-trinket_m0/firmware.uf2.

A vous de tester, merci d'avance

→ **MyCalcs** profile · de **Adriweb** » 06 Fév 2019, 14:53

Ca a l'air de bien marcher, félicitations

Code: Tout sélectionner: >>> 1+1 2 >>> 0.1+0.2 0.3 >>> 1e2+1e3 1100.0 >>> cos(0) 1.0 >>> cos(0.0) 1.0 >>> sin(pi) 1.224646799147353e-16 >>> cos(pi) -1.0 >>> pi 3.141592653589793 >>> pow(2,3) 8.0 >>> pow(2,15) 32768.0 >>> pow(2,20) 1048576.0 >>> pow(3,20) 3486784401.0 >>> pow(3,24) 282429536481.0 >>> trunc(2.03) 2 >>> log(123,3) 4.380238966019956

→ **MyCalcs** profile · de **critor** » 06 Fév 2019, 14:55

Ah, génial !

Problème corrigé avant même que l'on annonce son existence !

Donc maintenant, faut injecter ça dans le firmware de TI dont nous n'avons pas le code source, histoire que ça communique bien avec l'appli PyAdaptr de la TI-83PCE.