Appunti ambienti di calcolo

In questa pagina cercherò di raccogliere quanto mi è stato utile sapere sulle calcolatrici scientifiche / grafiche.e su altri sistemi di calcolo.

Calcolatrici DAL con 2 linee di visualizzazione per risolvere equazioni generiche a radici reali

Ho fatto una veloce ricerca per vedere un pochino le marche che offrono (luglio 2009) calcolarici DAL a 2 linee di visualizzazione (magari non sono tutte, ma la maggior parte sicuro).
#red|Queste calcolatrici esistono dal 1990, questi sono alcuni modelli disponibili a luglio del 2009, quindi forse la possedete già!##
#blue|Nonostante una calcolatrice DAL sia a 2 linee, non è detto (l'ho scoperto ieri) che possa risolvere un'equazione, prima del'acquisto, quindi, controllate il manuale.##

  • Casio
    • FX-82MS
    • FX-85MS
    • FX-350MS
    • FX-115MS
    • Casio fx-570 ES (confermata da Vasapollo M.)
  • Citizen
    • SR270II
    • SR275
    • SR282
  • Canon
    • F-766S
    • F-710
    • F-715S
    • F-788dx
  • HP
    • Smartcalc 300s
    • HP-10s
  • Texas Instruments
    • TI-30XS
    • TI-30X II S
    • TI-36X II
    • TI-34
    • TI-30X IIB
    • TI-34 II
  • Sharp
    • EL509WB
    • EL506WB
    • EL520WB

HP 50g

L'hp50g è una calcolatrice grafica, al top della gamma (almeno ora gennaio 2010 ) delle calcolatrici grafico-programmabili dell'HP. Le sue concorrenti sono la Texas instrument Ti-89, Ti-Nspire ; la casio 9860 G SD, 9860GII, algebra FX 2.0 ; la sharp el9900, altre valide concorrenti non ne ho trovate.

risorse

Incredibilmente la roba 'pro' (professionale o detta a mo di slang da community 'ad alti livelli') attira gente pro. Queste persone, anche se sono poche rispetto a tutti gli utilizzatori del prodotto, fanno cose incredibili! Potrei dire che è più sviluppato il software per l'hp che kmeleon.

Update 14092013
Purtroppo non ho mantenuto questa lista aggiornata con le mie conoscenze, "fortunatamente" ho scoperto una wiki della community (scoperta quasi per caso, vista la poca pubblicità) dove cercherò di segnare tutto quello che conosco riguardo al mondo delle calcolatrici HP e delle calcolatrici in generale. Anche perchè un conto è fare uno sforzo con l'aspettativa che poi sia completato da altri, un conto è fare uno sforzo (qui ad esempio) dove la possibilità che altri copino il lavoro fatto per estenderlo è molto bassa.
Viva la collaborazione di gruppo per interessi comuni!
/end update 14092013
Le risorse che ho trovato io sono:

Tuttavia grazie ad una discussione sul forum ufficiale (questa) sono spuntati fuori tanti bellissimi link, in particolare:

Ho recentemente scoperto, grazie al forum ufficiale, che (grandissimi sia gli utenti che youtube) ci sono molti video (ed una quantità impressionante di questi in spagnolo/portoghese, queste comunità sono molto unite su questa calcolatrice) relativi all'hp50g. Basta cercare video con la stringa "hp50g" o "hp 50g" (vale anche con 49g+ visto che è praticamente lo stesso modello).
Sono molto utili per iniziare.

Aggiornamento1:
L'utente più esperto attivo, di lingua italiana, che per ora ho incontrato è un ragazzo che si firma con il nome di supergems o gem_tux. Visto che è davvero scrupoloso aggiorna constantemente la sua raccolta e raccoglie praticamente tutti i collegamenti utili relativamente a questa calcolatrice, dunque mi baso sulle sue raccolte per i link importanti.

comparazione tra l'hp50g e le sue concorrenti

Update 14092013
Consiglio la visione degli articoli riguardo ai benchmark sulla wiki4hp.
\end Update 14092013
Ho precedentemente citato le concorrenti dell'Hp50g. In sostanza, se non si considerano programmi esterni che estendono le capacità della singola calcolatrice, tutte le calcolatrici sono allo stesso livello per quanto riguarda le funzioni principali a livello matematico.
Ovviamente differiscono tra loro per l'hardware (chi ha più memoria, chi meno; chi ha la CPU più veloce, chi meno, etc..)
Ogni calcolatrice ha funzioni particolari. La casio (9860G SD e modelli simili), ad esempio, permette di scrivere testi con formule matematiche (di poco aiuto devo dire, c'è word/latex pr questo..).

Tuttavia queste funzioni particolari non sono particolarmente importanti nell'uso della calcolatrice. E' importante, ad esempio, poter scrivere una formula in un formato simile ad una visualizzazione su quaderno (piuttosto che x^2+ 3x + 10), questo lo permettono di fare tutte le calcolatrici, e via discorrendo.

Un'altra caratteristica importante in una calcolatrice grafica è la possibilità di creare programmi (si, c'è il pc pure per questo, ma noi compriamo calcolatrici per avere computabilità in momenti in cui il pc non è utilizzabile [mentre si cammina verso l'aula, per esempio] o non è disponibile).

Un ruolo chiave nella programmazione tramite una calcolatrice è il linguaggio di programmazione (ed anche le capacità hardware ovviamente, ma quelle vengono dopo).
La discussione a cui ho accennato precedentemente (questa) voleva lasciare un feedback al team di sviluppo calcolatrici dell'hp.
In sostanza nelle concorrenti dell'hp il linguaggio di programmazione è di facile uso (ad esempio il codice di programmazione per le casio, sin dalla 7400gp, è questo http://pier4r.wikispaces.com/file/detail/app_calc_num_primi_casio.jpg, per le sharp e le texas instrument varia di poco), mentre quello dell'hp è del tutto inusuale (per chi è abituato ai linguaggi di programmazione 'normali', ovvero facilmente interpretabile come si vede dall'esempio per le casio). Si chiama userRPL (ci sono altre versioni che sono a più basso livello d'astrazione).

Se nei linguaggi 'normali' o, per come li definisce il menù "mode", 'algebrici' una struttura for si scrive così:

For variabile_delFor=valoreInizio to valoreFine do
istruzioni
next [o end]

in userRPL è leggermente diverso, perchè prima bisogna allocare in memoria per quali valori bisogna ripetere il ciclo:

valoreInizio valoreFine 
FOR variabile_delFor
istruzioni
next

Quindi il feedback nel primo post in pratica dice: "ok che molti sono abituati all'userRPL, ma se potete affiancategli qualcosa di più ad alto livello d'astrazione", questo perchè l'userRPL si basa sulla concezione di stack, che non astrae moltissimo.

Tuttavia dopo un pochino di pratica si prende la mano con questa programmazione (certo non è bellissimo leggerla) ed è possibile fare programmi molto più veloci delle concorrenti.

Nell'immagine precedentemente linkata si vede l'algoritmo di confronto. Nelle concorrenti il tempo di esecuzione varia da 1 minuto e qualcosa a circa 2 minuti per trovare i primi 50 numeri primi.

Ora vediamo diversi esempi dello stesso algoritmo (il più possibile simili agli algoritmi sulle altre calcolatrici) che tende ad utilizzare sempre più l'userRPL 'puro'.

  • Codice iniziale (mio) basato quello più 'ad alto livello'
    • PB1
    • esecuzione in circa: 10 min e 20 sec
  • Codice di Tim Wessmann, identico a quello precedente solo che usa variabili locali
    • PB2
    • esecuzione in circa: 9min e 43 sec
  • Codice di Tim Wessmann, utilizzando variabili locali ed evitando le valutazioni algebriche
    • PB3
    • esecuzione in circa: 5min e 46 sec
  • Codice di Tim Wessmann, utilizzando variabili locali, evitando le valutazioni algebriche anche sulle liste
    • PB4]
    • esecuzione in circa: 44 sec

In sostanza l'hp50g vince il confronto (utilizzando solo i linguaggi disponibili attraverso al calcolatrice, senza usare tool esterni per programmare in linguaggio macchina [assembly/ASM] ) rispetto a molte altre calcolatrici, tuttavia lo vince solo se si usa il linguaggio di programmazione per come è pensato, ovvero ad un livello di astrazione (rispetto alla logica del calcolatore) basso.
Quando si cerca di rendere più leggibile il tutto, è un pochino un disastro (rispetto ai concorrenti).

Aggiornamento1:
Valutando lo stesso algoritmo su una T89 titanium , questo esegue in 41 secondi, decisamente meglio della hp50g se si considera che il linguaggio TI-BASIC è più semplice.
Ovviamente questo valutando i linguaggi accessibili senza grossi problemi tramite la calcolatrice stessa, altrimenti in codice C, generato con HPGCC, si impiegano 0.07 secondi a trovare i primi 50 numeri primi sulla HP50g. (Questo perchè l'userRPL è emulato per mantenere la compatibilità con funzioni scritte per calcolatrici precedenti).
Fine aggiornamento.

In generale l'hp50g è il miglior acquisto (se dovete comprare calcolatrici al top) possibile, ma se sfruttate intensamente la vostra calcolatrice tramite programmi, e non volete scrivere questi attraverso tool esterni basati sul pc (potete usare c attraverso HPGCC), le opzioni sono 3:

  • Comprate una delle calcolatrici concorrenti, che hanno il linguaggio di programmazione che permette alti livelli d'astrazione sfruttando abbastanza bene l'hardware disponibile.
    Oppure una possibile soluzione (anche se leggermente macchinosa) potrebbe essere questa:
    - prima scrivete il programma tramite una sintassi che cerca di astrarsi dall'userRPL standard, ed abbiamo visto che ciò rallenta il tutto
    - una volta che verificate che il vostro programma funziona, lo modificate utilizzando una sinstassi più adatta all'userRPL, così da velocizzarne l'esecuzione.
    Un esempio banale, ma che vale in generale. Si potrebbe iniziare a scrivere:
    '2*x + 6 * cos (5*x) + y' EVAL la formula in formato algebrico valutata in un programma userRPL.
    Questa forma esegue nel modo più lento anche se è facilmente leggibile.
    Una volta appurato il fatto che funzioni, si può scrivere:
    '2*x' EVAL '6*cos(5*x)' EVAL + y +
    Che è una prima scrittura in RPN,
    dopodichè si arriva a scrivere:
    2 x 5 x * cos 6 * + y +
    che è la forma in RPN (la forma preferita dalla calcolatrice) con cui esegue a massima velocità.
    ovviamente per leggerla ci vuole un pochino di abitudine.
  • Mettete in conto di imparare a dovere l'userRPL (è sempre conoscenza) per sfruttare al meglio le potenzialità hardware superiori della calcolatrice Hp.
  • Aspettate finchè l'HP non affianca all'userRPL un linguaggio di programmazione a più alti livelli d'astrazione.

userRPL, emulatore Saturn ed osservazioni

Come ogni cosa cercare continuamente nuove informazioni (anche se lentamente) su un argomento è solo un bene. Relativamente alla velocità di esecuzione dell'hp50g sono rimasto un pochino deluso quando ho visto che la sua diretta concorrente esegue lo stesso algoritmo in poco meno tempo ma con una leggibilità superiore. Questo poichè l'userRPL è emulato, altrimenti con l'HPGCC si sfrutta tutta la velocità dell'ARM con prestazioni straordinarie. Il problema dei programmi HPGCC è che bisogna svilupparli prima al computer, non è possibile ritoccarli dalla calcolatrice se non con molto impegno.
Quindi mi son chiesto come mai l'userRPL deve essere emulato sull'hp50g.

La precedente calcolatrice di punta dell'HP era la serie 48. Questa aveva un processore saturn ed adottava l'userRPL come linguaggio base ed il sysRPL come linguaggio macchina (veramente c'è un terzo linguaggio, ma vabbè).
Questo tipo di calcolatrice è rimasta al top per molto tempo, quando la concorrenza non produceva prodotti simili, e quindi moltissimi programmi sono stati sviluppati per questo modello.
Molti di uesti programmi sono stati sviluppati nel codice piu' veloce possibile per le calcolatrici della serie 48, il system RPL.
Quando l'hp ha cambiato processore ed architettura dello stesso1 , utilizzando l'ARM, si è trovata davanti ad una scelta:
Ricompilare tutti i programmi, anche quelli fatti dagli utenti2 , oppure riutilizzare lo stesso sistema, emulando il sysRPL. Ovvero esiste un interprete, nel sistema operativo dell'hp50g, che traduce le istruzioni da systemRPL a codice ARM per essere eseguite.
Con questo si è evitato di riscrivere una montagna di programmi e quindi di ritardare il lancio del prodotto, oltre che a permettere di riutilizzare i programmi scritti per la serie 48 dagli utenti.

In soldoni per la serie 48 si avevano questi passaggi:
UserRPL tradotto in systemRPL tradotto in codice Saturn eseguito sulla CPU saturn.

Per le calcolatrici con processore ARM si hanno invece questi passaggi
UserRPL tradotto in systemRPL tradotto in codice Saturn tradotto in codice ARM eseguito sulla CPU ARM

L'esecuzione non è diretta ma quasi, ovvero il codice per quella CPU viene opportunamente trasformato in sequenza di bit e poi eseguito, tuttavia questa trasformazione è la piu' semplice e meno costosa di tutte.
La traduzione è invece, in termini di operazioni da fare, costosissima, poichè bisogna verificare ogni volta la sintassi del comando per scoprire che tipo di comando è.
Quindi già da questo osserviamo che il processore ARM perde tantissimo tempo a tradurre, poichè deve fare ben due traduzioni (ecco perchè emula il saturn) di sintassi affatto banali.

Non è finita qui!
Infatti si potrebbe dire: "vabbè ma una volta che il codice userRPL (o systemRPL) è tradotto in codice ARM, poi si esegue il programma senza doverlo ritradurre ad ogni passaggio. In questo modo consumo tante operazioni all'inizio, ma se il programma è intensivo, non si faranno sentire granchè3 sull'esecuzione totale".
Si e no vedi l'update!
Una traduzione completa del programma (che sia userRPL o systemRPL) con eventuali chiamate, in codice ARM potrebbe richiedere la creazione di un file temporaneo (il file eseguibile) molto grande (poichè deve comprendere la traduzione di tutti i sottoprogrammi o funzioni usati nel programma principale).
Queste calcolatrici non hanno molta memoria, e si rischierebbe di consumarla tutta prima di poter eseguire il programma (basta vedere gli eseguibili generati da hpgcc).
Rendersi conto di ciò è banale. Basta andare a vedere un programma in userRPL ed il suo equivalente scritto in HPGCC che scrive direttamente codice ARM basandosi su C.
Se il programma in userRPL occupa 500 byte.
Il programma in codice ARM occupa 10.000~15.000 byte .
Allora han pensato: invece di tradurre in un file eseguibile tutto il programma, io lo traduco interamente in SysRPL (se non è già in sysRPL). Così il costo in memoria del singolo programma tradotto è piccolo (il sysRPL è abbastanza compatto). Per eseguire tutte le operazioni mi basta leggere e tradurre di volta in volta le istruzioni (in systemRPL) del programma, così consumo pochissima memoria e posso eseguire molti programmi.

Update: non è proprio così, ringrazio Andreas Moeller (un ragazzo tedesco che conosce moltissimo di questa calcolatrice) per la seguente spiegazione:

Hi,

I guess that for same problem (:save memory) OS on Hp calculators (both with saturn and ARM) don't compile the program (that mean: other memory for temporary compiled programs) but do a continous interpretation of each commands, right?

Nope, the command line parser actually compiles each USER-RPL program into a series of either 5 Nibbles ROM addresses or 11 Nibbles ROMPTRs or 12 Nibble FLASHPTR. Other objects, like Extended Pointers (15 Nibbles), Primitiv Code Objects (5 Nibble address), Code objects (size varies), etc. are not available in USER-RPL.

A good example for this are all built in numbers, take for example the real number 1. In RAM this would be
Prologue (02933) 5 nibbles
Exponent 3 nibbles
Mantissa 12 nibbles
Sign 1 nibble
########
Total: 16 Nibbles = 8 Bytes = 64 Bits which is the length of a processor register, which is, of course, no coincidence.

However, the compiler detects that this is a built-in number (the key to this is the Prologue, a very clever approach but way beyond this scope) and will translate it to 2F94C which is the ROM address of the built-in number and this address then points to the 16 Nibbles in ROM where the number is stored (actually it is a little more complicated, depending if ROM is covered or not, which FlashBank, etc., but this should do it for understanding).

That way the number consumes only 5 Nibbles RAM instead of 16 Nibbles.

RPL is designed to run from ROM with a minimal RAM usage.
##
Cioè in sostanza si traduce l'userRPL in sysRPL e questo consuma davvero poco spazio, facendo veder eun esempio di un numero reale.

Come potete immaginarvi questa scelta di risparmiare spazio è valida da una parte ma terribile da un'altra, perchè in pratica poi ogni operazione sysRPL deve essere emulata (cioè tradotta) e l'emulazione costa molto perchè di deve capire cosa fa l'operazione in sysRPL (mentre sulle hp48 le operazioni in sysRPL parlavano già ottimamente con l'hardware). Quindi si rendono le calcolatrici con processore ARM lentissime rispetto alle loro potenzialità.

Come potete ben capire, con pochissimi programmi in codice ARM riempireste buona parte della memoria della calcolatrice (che è di 2 megabyte, approssimativamente 2.000.000 byte), contando che la parte restante serve per fare i calcoli (che durante l'esecuzione occupano spazio). Quindi l'uso dell'userRPL/sysRPL permette di salvare moltissimi programmi in piu' direttamente sulla calcolatrice.

Tuttavia, se si tiene presente che su 2 modelli su 3 con processore ARM (almeno fino a giugno 2010) dell'hp c'è la possibilità di salvar i programmi su una scheda SD, dove anche 64 megabyte (~64.000.000 byte) sono tantissimi, allora ci si rende conto che sviluppare programmi in C non è male.

Infatti poi, se si guardan le prestazioni, se il programma in C utilizza, per terminare, 100 unità di tempo, lo stesso programma in userRPL (in system RPL è 4-5 volte piu' veloce poichè l'userRPL è memorizzato, una volta scritto, in sysRPL ma porta con se molti controlli "automatici"4 che una scrittura diretta in sysRPL può evitare, ecco perchè è più veloce ) utilizza all'incirca 65.000 unità di tempo. Update: no questo valore non è un valore medio, mediamente un programma in C che esegue con la CPU a 12mhz (l'userRPL esegue a 75mhz perchè richiede molta potenza) è 20-25 volte più veloce dello stesso programma in sysRPL (a 75mhz) e di conseguenza 100-150 volte più veloce dell'userRPL.

Quindi, se volete sfruttare davvero una calcolatrice con processore ARM con programmi intensivi5 (con quelli semplici è accettabile aspettare qualche secondo sprecando cicli su cicli per le traduzioni), è davvero necessario saper utilizzare HPGCC.

Sperando che prima o poi la divisione dell'hp decida di ricompilare almeno i programmi ufficiali in codice ARM, cosicchè potremo avere:
userRPL tradotto in ** codice ARM **eseguito sulla CPU ARM

Certo, non si potranno usare tutti quei programmi scritti da utenti precedenti in systemRPL, ma almeno con la maggior parte dei programmi si andrà decisamente piu' veloce. O si potrebbero compilare in codice ARM quei programmi computazionalmente costosi di uso comune come i risolutori di sistemi.

Aggiornamento: non ho seguito la community sull'hp50g (principalmente il forum offerto dall'hp, il gruppo di discussione su comp.sys , ed il sito hp museum, dai quali, leggendo qualche thread, si arriva a quasi tutte le risorse utili) per molto tempo, limitandomi ai siti italiani (il forum helpcalculator) che sono poco attivi, ed ho scoperto con una ricerca al volo, devo ritornarci, che ci sono stati notevoli sviluppi. Ad esempio finalmente è uscito, già nel 2011 (quanto sono rimasto indietro), l'ambiente di sviluppo hpgcc3.
Comunque un utente con discrete possibilità ha testato varie calcolatrici programmabili su un problema classico come le "n" regine (qui, così si può vedere la differenza tra userRPL e codice C arm, contando però che non è tutto oro quello che luccica. Il C arm sarà anche velocissimo ma è molto più pesante dello userRPL in termini di spazio in ram (e l'hp 50 g non ne ha molto), e soprattutto non può utilizzare le librerie che sono disponibili con lo userrpl, quindi per risolvere un problema bisogna trascrivere (o ricompilare) una libreria già esistente adatta allo scopo o scriversela da se. Inoltre ho scoperto che non esiste solo l'hpGCC ma anche versioni sperimentali di Lua e Pascal (hpLua e Hp studio pascal). Infine l'hp ha prodotto una nuova calcolatrice che supporta un linguaggio di programmazione più vicino al linguaggio umano rispetto allo userRPL, è la 39gII.

Documento sulla programmazione in userRPL

Calcolatrici per java me 2.0 (per cellulari)

Jasymca

Non è male, certo non è potente come l'hp50g a livello di funzioni preinstallate (o rintracciabili sui siti più importanti), ma per molte cose va bene.
Per esempio ho facilmente impostato il benchmark (molto più facile da scrivere rispetto a tutte le calcolatrici programmabili provate) dei numeri primi, per vedere jasymca (versione 2.0) su un nokia 3109c se era capace di battere l'hp50g (una delle più veloci calcolatrici a completare il test tra quelle al top della gamma casio / hp / sharp / ti).

Il codice da inserire è prima la funzione per il modulo (che non c'è, ma nonostante tutto esegue velosissimo!):

E poi la funzione di ricerca stupida dei numeri primi

Il tempo di esecuzione è di 23 secondi, molto meglio dell'hp 50g (che per migliorarsi ha comunque richiesto il codice scritto non ad altissimo livello, tralasciando tool esterni come HPGCC o userRPL2SysRPL).
Il problema e che non riesce (non ho capito bene il motivo, sarà che sono ancora i primi giorni che provo) a leggere automaticamente gli scriptfile, quindi per ogni cosa complessa serve tantissimo tempo per scriverla ogni volta (dunque l'hp50g in questo senso stravince).
Se riesco a fargli prendere i file con gli script allora diventa un buon sostituto palmare (su un cellulare con java midp 2.0) dell'hp50g per programmi semplici che non richiedono molte funzioni preinstallate.

Aggiornamento1:
Non sono riuscito a fargli caricare i file :( .

Cellular basic pro

In pratica è un interprete j2me (direttamente sul cellulare) di un linguaggio simile al quick basic (o qbasic, dove il qbasic è un sottoinsieme di quick basic). In realtà è un sottoinsieme di quick basic, ma con adeguata pazienza si posson fare molte cose (appena installato è giusto utile a risolvere qualche algoritmo). Non è molto documentato (per ora), ma se riesco (stavolta carica il codice da file a differenza di jasymca!) scriverò una documentazione (magari in inglese) relativa. Per ora bisogna capire il funzionamento dgli esempi, dal reference.txt e da pagine web relative a quick basic (esempio).
Dovrebbe essere open source ma ancora la sviluppatore non ha rilasciato il codice, anche se prima o poi lo farà (secondo me).
Se la scimmia (ovvero "desiderio indomabile") evita di farmi investire tempo nel cercare soluzioni migliori (utilizzabili direttamente sul cellulare) dovrei utilizzarlo non poco, quindi potrei ricavare tante informazioni da scrivere qui (questo vale anche per l'hp50g che è fantastica) soprattutto nell'espansione delle funzioni.
Nota: sul mio nokia 3109 le versioni 2 e 3 non funzionano per mancanza di una libreria, la 1.0 funziona benissimo.

Per ora, come al solito, ho mandato in esecuzione il solito benchmark sui numeri primi (ormai uno standard):

Il tempo di esecuzione è impressionante, 3 secondi (a differenza di Jasymca che richiede 23 secondi).
Questo dimostra che le potenzialità di calcolo sono ovunque, ma sono poco sfruttate. Quindi non solo devices (comuni già dal 2004-2005 ad un prezzo maggiore di 200€) come i cellulari nokia "semplici" sono estremamente potenti per risolvere molti problemi, ma anche le calcolatrici odierne (es hp 50g) alla fine non sono così potenti (almeno in termini di velocità, che come funzioni installate vanno benissimo) come sembrano, tutto questo a causa della mancanza di ottimizzazione (ricordo che con hpgcc l'hp50g impiega 0.07 secondi a trovare i primi 50 numeri primi con l'algoritmo precedentemente postato).

Aggiornamento1:
Ho scoperto una cosa davvero carina, se il programma eseguito è uguale al precedente ed il caso rientra in quello precedente (ad esempio "calcolami 50 primi dopo che ti ho chiesto di calcolarne 100"), allora l'interprete se ne accorge (non è banale come funzione) e riutilizza il risultato precedente. In questo modo, dopo aver calcolato 100 primi, il calcolo di 50 primi è istantaneo (ma ovviamente falsa il conteggio temporale).
Inoltre con 100 primi il tempo richiesto è di 10 secondi, pari a spacetime su un [n30] che è parecchio potente (in termini di possibili usi). Quindi il 3109 assieme ad un buon software (e non credo che cellular basic sia molto ottimizzato assieme all'interprete j2me) potrebbe fare davvero tante cose, peccato che questi strumenti non vengano sfruttati al massimo (come del resto vale anche per i pc).

Ambienti di analisi numerica per cellulari basati su windows mobile (dal 2003 in poi)

Anche per i cellulari con windows mobile esiste un tool per generare codice ottimizzatissimo (però bisogna portarsi dietro anche il notebook :S ) che è CeGCC (giustamente Mezzo-GCC. Esiste l'HPGCC, il TIGCC per calcolatrici texas instruments ed il CeGCC per i cellulari windows mobile).

Lightweight Matrix Engine LME

Molto simile a matlab ed è free. Il codice che ho eseguito è praticamente lo stesso di jasymca.
Su un i-mate jama 101 (datasheet) impiega 2.5 secondi per trovare i primi 50 numeri primi.

Spacetime

Ho provato questo prodotto, da molti decantato come il miglior ambiente palmare per la matematica. Assolutamente no!
E' molto buono per il calcolo simbolico o per i grafici (il primo non è gestito da LME ed i grafici sono molto piu' semplici da fare con spacetime, inoltre sono anche piu' chiari), ma ha tantissime limitazioni quando non si usano funzioni semplici ma bensì simulazioni intensive. Ad esempio non supporta la logica booleana, quindi è impossibile dire SE (questo AND questo) ma bisogna simularla con una serie di operazioni innestate.
Quindi è valido, ma solo per matematica "non algoritmica" o almeno non troppo. Il che per me non è il massimo.
Attenzione, poichè spacetime per palmari windows non verrà piu' sviluppato, è rilasciato gratuitamente (a patto di registrarsi tramite il dispositivo)! E ciò è ottimo, visto che comunque è un buon prodotto! link per touchscreen link per smartphone

Spacetime vs LME su algoritmi

Ho provato sia LME sia Spacetime (per pocket pc) sullo stesso palmare con lo stesso algoritmo, per quanto possibile. In spacetime ho dovuto sudare perchè molte funzioni non sono ben esposte e bisogna andare a tentativi prima di capirne il funzionamento (ad esempio l'insert modifica una lista, ma la modifica permanentemente o momentaneamente?). Fattostà che ho usato l'algoritmo dei numeri primi su entrambi.
Con 50 numeri primi da trovare, entrambi si comportano similmente, sui 2,5~3 secondi.
Con 100 numeri primi da trovare, LME impiega 6 secondi (per eccesso) e spacetime ne impiega 10.
Quindi se si tratta di algoritmi, LME è il migliore (anche perchè ha un signor manuale). Altrimenti Spacetime se la cava con il calcolo simbolico e grafici.

Python

Dopo una ricerca leggermente più approfondita ho scoperto che su windows CE esistono diversi linguaggi di programmazione "on the go". Alcuni che permettono l'interattività (come python), altri invece permettono l'editing di piccole cose ma è possibile sviluppare progetti più complessi con il pc e poi usare il risultato innumerevoli volte sul dispositivo mobile. Purtroppo non ho salvato i risultati della ricerca e quindi riporto solo uno degli innumerevoli ambienti di programmazione on the go (c# ide mobile, Pocket Programing language, pocket scheme, etc..), che è python di cui ho discusso nella sezione riguardante il symbian s60v3. PythonCE.
Update: eseguendo lo stesso algoritmo eseguito con python per s60v3, sul palm treo pro , il calcolo è terminato in 52 secondi! Ottimo se si considera che il nokia e5 ha una cpu molto più potente. Vediamo 33 secondi con 600mhz contro 52 con 400 mhz hanno un rapporto all'incirca lineare, dunque le versioni di python sui due dispositivi sono egualmente ben fatte.

Ambienti di analisi numerica su s60v3

Python

Sul symbian s60 v3 (o symbian 9.3) è presente direttamete un interprete python (by nokia), quindi abbiamo a disposizione un intero linguaggio di programmazione, con tanto di librerie matematiche presenti in rete. Sinceramente ciò mi ha fatto pensare: ho fatto una ricerca per un compilatore/interprete presente sul cellulare per windows mobile, ma non trovai nulla, chisssà con una ricerca più approfondita! Per ora rimangono LME e spacetime. (preso dal rosik ho fatto una ricerca veloce da espandere, devo provare C# ide [provato, funziona c'è c# su win mobile!], freepascal per wince [ce ne sono tanti altri e devo dedicarmici!]. Tuttavia sembrano meno interattivi di python. Ok chiusa nota. Riapro: su Windows mobile ci sono moltissimi linguaggi disponibili, interpretati o meno, il problema è trovarli poichè i link iniziano a non funzionare. PythonCE si trova benissimo)
Dopodichè mi sono informato su python. Ancora la gente non si fida dei linguaggi interpretati (come java) perchè sono "lenti". Affatto! Si, dialogare con le periferiche con un linguaggio interpretato è più difficile ma per fare codice puro, che elabora e basta, sono migliorati moltissimo (chi storce il naso dopo questa affermazione: fuori dal mio wiki xD! No davvero, basta provare). Allora ho fatto eseguire il solito codice sul nokia e5.

Sono rimasto con la bocca aperta! Seppur l'e5 ha 256 mega di ram ed un processore da 600 mhz, l'acer n30 non è molto più scarso (è molto simile all'i-mate jama 101 che è diventato inusabile a causa di un urto, uffa), almeno per questi programmi ad uso intenso di CPU e poca ram. Eppure LME impiega 2-3 secondi per trovre i primi 50 primi. Circa 6 per trovare i primi 100. Python sull'e5 impiega qualche centesimo di secondo!
E' ovvio che non è colpa dell'n30, ma dell'ambiente di sviluppo (LME) meno ottimizzato rispetto a python per s60 (mi sono innamorato!).
Per curiosità ho lanciato l'algoritmo sui primi 5000 numeri primi, ed ha impiegato 33 secondi. Poi su un atom n270 (1.6ghz) e visual basic di excel 2007 (ho scelto questo perchè, ad occhio, è un linguaggio interpretato con la stessa ottimizzazione di python sul cell), lo stesso algoritmo ha impiegato 6.5 secondi ad eseguire.
Molti diranno, distrattamente "mbè? L'atom è più veloce". Non vi rendete conto che l'atom è molto meno portabile di un e5 (almeno per me) e consuma 40watt tutto il sistema. L'e5 ne consumerà 2 a dir tanto. Un consumo inferiore di 20 volte contro una prestazione inferiore di "solo" 5 volte. Ma per dire, in 33 secondi non ci riesce scilab (sempre sull'atom, richiede 10 minuti ed oltre), in 33 secondi credo che non ci riuscirebbe (con visual basic) neanche un ottimo pentium 3 @600mhz (per i consumi).
Insomma, se si scrivono applicazioni ben ottimizzate, i cellulari sono mostruosi, si potrebbe evitare di aprire il pc per molte azioni (e si risparmia energia).
Grazie ad un amico abbiam provato lo stesso algoritmo su 6210 navigator che ha un hw circa il 70% più veloce (almeno stando ai mhz) dell'acer n30. L'algoritmo, su 5000 primi, ha eseguito in 62 secondi. Una conferma di ciò che ho scritto.

Su vari sistemi embedded con awk

So che non è proprio opportuno usare sistemi embedded per fare calcoli, ma qualche calcoletto è fattibile. Si lancia il giorno prima e lo si trova il giorno dopo (avendo spento i pc, non avendo server disponibili in casa) a patto che il sistema possa effettivamente completarlo in tempo. Ho scoperto da poco (maledetto me) il linguaggio awk, che prima contemplavo solo per le espressioni regolari. Molti sistemi embedded lo supportano e non supportano altro quindi ho creato un piccolo script in questo linguaggio per vedere come si comportano.

Tplink wr741nd

root@Gargoyle:~# cat /proc/cpuinfo 
system type             : Atheros AR7240 rev 2
machine                 : TP-LINK TL-WR741ND (un 400mhz)
processor               : 0
cpu model               : MIPS 24Kc V7.4
BogoMIPS                : 232.65
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0000, 0x0ff8, 0x0ff8, 0x0ffb]
ASEs implemented        : mips16
shadow register sets    : 1
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

ram 32 mb

ha impiegato (avendo il sistema quasi tutte le risorse disponibili):

root@Gargoyle:~# time awk -f nprimi.awk 
numero primi?
5000
real    12m 35.71s
user    12m 21.87s
sys     0m 6.51s

Che è poco più di quanto fatto da scilab 5 su un sistema più adatto (vedi benchlinguaggi). Si potrebbe dire "è più lento dello userRPL dell'hp50g!" ebbene no. Seppure l'hp50g sta aspettando un mio impegno nell'uso di HPGCC, il linguaggio base della calcolatrice (idem per la texas ti89) impiega "al minimo" una quarantina di secondi solo per trovare i primi cinquanta primi, non certo i primi cinquemila. E c'è anche da dire che pure per il wr741nd è possibile, come per l'hp50g (o la ti89) usare una versione scritta in C molto più efficiente. Anche se ormai, almeno lato calcolatrici (non è certo compito del router far molti conti), sembra che finalmente abbiano riscritto il software in modo nativo anche in casa Hp con la 39gII (mentre in casa texas lo fanno da sempre, infatti le cpu che utilizzano sono molto più parche delle cpu dell'hp).

Considerazioni sull'uso dei vari supporti di calcolo a seconda dei problemi

Con questa miriade di supporti sembrerebbe che bisogna usarne solo uno, il piu' potente. Questo è vero qualora non si possiedano anche altri supporti. Quando si possiedono diversi supporti (calcolatrici scientifiche, grafico-programmabili, grafico-programmabili e simboliche, programmi sul palmare, etc..) non e' detto che il piu' potente escluda gli altri, in termini di fruibilità.

2 giugno 2010

Calcolatrice scientifica sharp el 506 wb.
- ottima per calcoli veloci. Esempio banale, per operazioni on frazioni, se usassi gli altri supporti, ci metterei troppo. Invece grazie ai tasti immediati, con la sharp vado velocissimo. Oppure quando devo trovare una soluzione approssimata di un'equazione, il metodo solve della sharp è velocemente raggiungibile rispetto agli altri supporti ed è egualmente veloce.

Calcolatrice grafico-programmabile casio 7400 g plus
- C'è la possibilitò di graficare velocemente funzioni (non complesse) settando molti meno parametri delle calcolatrici piu' potenti. Quindi se devo vedere un attico come si comporta una funzione semplice, uso questa. Inoltre ha la possibilità di graficare facilmente funzioni dai programmi (ha un comando proprio veloce, a differenza delle altre calcolatrici piu' potenti, dove devi dar sempre qualche informazione in piu'), e quindi risulta facile fare piccoli programmi che graficano situazioni utili ma non complesse.

Calcolatrice grafico-programmabile-simbolica hp50g (o ti89t è uguale)
- E' utilissima nei calcoli simbolici veloci (quelli che risolve brevemente), nelle simulazioni algoritmiche non troppo intensive (roba da qualche ora, stando fuori casa), nel graficare roba complessa. Soprattutto è utilissima per produrre immagini anche molto grandi (2000x2000) di grafici (semplici o complessi) o passaggi simbolici, grazie all'uso delle variabili GROB. (vedere ad esempio il documento su modellistica ed identificazione).

Calcolatrice grafico-programmabile per cellulari Calc 4.52
- E' ottima per calcoli non banali (non solo le 4 operazioni) quando si è in luoghi dove altre risorse non sono utilizzabili (pullman, fermate del treno, in una discussione seria tra amici, etc..)

LME su palmari windows mobile
- Utilissimo principalmente (per il resto uso altro) per simulazioni algoritmiche intensive ma non troppo da richiedere un pc. Si ci porta dietro soltanto un peso minimo con una tastiera al silicone (con certi palmari è adattabile, l'acer n30 ad esempio), e si possono fare prove non stupide che altri mezzi palmari (l'hp50g) affronterebbero in molto piu' tempo (salvo uso di colpilatore HPGCC, che però, in caso di modifica del codice, richiede il pc, quindi niente).
Ad esempio per verificare il comportamento di certi settings di emule tramite simulazione, con l'hp ci ho messo 14 ore e non avevo il pc, alla fine la batteria era al minimo. Con LME ho provato una leggera modifica al codice e c'ho messo 20 minuti, giusto il tempo di avviare la simulazione prima di prendere il pullman per avere il risultato appena sceso, dentro la mia tasca.

Spacetime
- Ottimo da accoppiare ad LME, quando si ha il palmare si possiede un ottimo elaboratore di calcoli simbolici o normali assieme alle capacità di disegnare diversi tipi di grafici. Tuttavia e' sicuramente piu' lento (previa tastiera di silicone che richiede un piano) di una calcolatrice in quanto quest'ultima ha la tastiera di immissione apposita.
Inoltre non riesce ad esportare grafici o passaggi simbolici sotto forma di screenshot estesi, ma sempre limitati alla risoluzione dello schermo del palmare, che di solito fà ridere. Quindi è utile per farsi un'idea delle funzioni da usare qualora si debba implementarle con LME, portandosi dietro solo il palmare.

Come si può vedere ogni strumento ha motivo di essere utilizzato in un certo scenario. Sicuramente non mi porto dietro 20 cose per volta, quindi se ho il palmare LME e Spacetime sono entrambi utili, se ho la calcolatrice grafica sono limitato alle sue funzioni, etc..
Solitamente io mi porto sempre dietro quella scientifica se ho lo zaino, oppure ho sempre il cellulare con Calc (che è un pochino piu' macchinosa di quella scientifica, tuttavia). Quando porto una calcolatrice in piu' mi porto l'hp (la 7400 la uso a casa se non stò studiando sul computer). Di certo non mi porto hp+palmare dietro. Una delle due cose, normalmente il palmare se voglio produrre risultati che poi non salverò (se non i meri risultati numerici in un file di testo) da nessuna parte. Se invece li voglio conservare per esportarli sul PC, mi porto l'hp (quindi esporto tutti i passaggi o i grafici completi).

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License