Link alla notizia: https://www.hwupgrade.it/news/cpu/creata-una-cpu-a-16-bit-funzionante-dentro-microsoft-excel_123859.html

Una CPU a 16 bit completamente funzionante è stata riprodotta in Excel da uno youtuber che ha illustrato il tutto in un video. Capace di lavorare a 3 Hz, il processore include 128 KB di RAM, un display a 16 colori ed è accompagnato da un linguaggio assembly custom.

Click sul link per visualizzare la notizia.

L'ho sempre detto, cosa non si riesce a fare sotto Excel, a saperlo usare ! ;)

Il tizio con un C.V. del genere verrà certamente assunto :)

PER forza...

Se riesci a implementare una porta logica nand, ci puoi fare di tutto partendo da questa...

Basta vedere gli esempi di cpu fatti anche con gli oggetti presenti nei giochi, come minecraft, factorio....

Giusto un tre mesi fa si sono svolti i campionati mondiali di Excel (si trovano integralmente sul tutubo): robe "aliene" che un semplice utente non può nemmeno immaginare che si possano fare con excel !! :eek:

L'ho sempre detto, cosa non si riesce a fare sotto Excel, a saperlo usare ! ;)

Anni fa ho scoperto Power Query, inutile dire come ho cambiato il lavoro in azienda.

Tanto per dirne una.

Anni fa ho scoperto Power Query, inutile dire come ho cambiato il lavoro in azienda.

Tanto per dirne una.

Ho sempre utilizzato Office in modo estremamente basico date le mie limitate esigenze in tal senso. Ma rimango ogni volta entusiasta delle possibilità che offre !

Excel, Access, niente da dire, MS-Office è un prodotto tripla A ! :)

Ho sempre utilizzato Office in modo estremamente basico date le mie limitate esigenze in tal senso. Ma rimango ogni volta entusiasta delle possibilità che offre !

Excel, Access, niente da dire, MS-Office è un prodotto tripla A ! :)

Veramente roba del genere è banale, solo che la maggior parte degli utilizzatori non si rende conto di quante funzionalità hanno i fogli di calcolo (Excel o altro che sia).

Semmai sarebbe il caso che chi pensa di essere bravo ad usare Excel dia pure un occhiata qui:
https://eusprig.org/
Ed in particolare a:
https://eusprig.org/research-info/horror-stories/

Veramente roba del genere è banale, solo che la maggior parte degli utilizzatori non si rende conto di quante funzionalità hanno i fogli di calcolo (Excel o altro che sia).

Semmai sarebbe il caso che chi pensa di essere bravo ad usare Excel dia pure un occhiata qui:
https://eusprig.org/
Ed in particolare a:
https://eusprig.org/research-info/horror-stories/

Ne ho letti alcuni e mi viene in mente solo una cosa: spesso l'origine del problema risiede tra lo schermo e la sedia. :asd:

Veramente roba del genere è banale, solo che la maggior parte degli utilizzatori non si rende conto di quante funzionalità hanno i fogli di calcolo (Excel o altro che sia).

Semmai sarebbe il caso che chi pensa di essere bravo ad usare Excel dia pure un occhiata qui:
https://eusprig.org/
Ed in particolare a:
https://eusprig.org/research-info/horror-stories/

Purtroppo le potenzialità di excel sono da sempre accompagnate da un difetto fatale: la facilità con cui si può, passatemi il termine, craccare le protezioni.

Ad esempio se io voglio creare una foglio excel che esegue una macro e interrogando una DLL fa vedere a chi lo apre i dati della sua unità operativa per quanto possa proteggere la macro non ci vuole niente con un minimo di pratica a distruggere le protezioni e accedere al codice. A quel punto basta conoscere 2 bischerate di basic e la modifichi come ti pare.

Se risolvessero queste vulnerabilità sarebbe veramente uno strumento devastante.

Ho sempre utilizzato Office in modo estremamente basico date le mie limitate esigenze in tal senso. Ma rimango ogni volta entusiasta delle possibilità che offre !

Excel, Access, niente da dire, MS-Office è un prodotto tripla A ! :)

Io che ho fatto cose abbastanza complesse sia in Access che in Excel posso dire però che di bug e di problemi ce ne sono a bizzeffe.
Access, se fai query complesse, con sotto-query può diventare di una lentezza imbarazzante, minuti e minuti di elaborazioni per query che fatte direttamente in SQL sono praticamente immediate.
Excel con pulsanti che funzionano solo sul monitor principale e non sui secondari, fogli di calcolo che invece di occupare qualche kb diventano da decine di MB perchè Excel decide di tenere in memoria righe di dati vuoti, spesso arrivando fino al limite massimo del numero di righe supportato, macro in VBA che ho dovuto riscrivere in buona parte perchè, a volte, non funzionavano correttamente, e via andare. Certo tante funzionalità ma anche tanti grattacapi...

L'ho sempre detto, cosa non si riesce a fare sotto Excel, a saperlo usare ! ;)

the e pasticcini per tutti? :stordita: :D

In Excel sono riuscito a creare del codice Windows in modo nativo appoggiandomi totalmente all'SDK di Windows stesso e fregandomi totalmente degli user form e dei vari controlli disponibili in Excel per la programmazione di macro con Visual Basic for Application.

Ho però trovato non molte magagne in Excel, la più clamorosa sono gli indici delle colonne dei fogli di calcolo che sono normalmente rappresentate con le lettere dell'alfabeto ma che sotto il cofano vengono tradotti negli indici numerici 1,2,3,4 ... (la colonna A ha indice 1 e non zero).

La codifica tra le etichette e gli indici numerici è banalmente il sistema di numerazione posizionale a base 26, solo che invece di utilizzare anche le usuali cifre numeriche (come accade per la rappresentazione esadecimale dei numeri) utilizza solo ed esclusivamente le lettere dell'alfabeto secondo la corrispondenza A=1, B=2, C=3, ..., X=24, y=25, Z=26, AA=27, AB=28 ecc. ecc..

Ora non è molto difficile comprendere che la conversione tra la rappresentazione letterale delle colonne e quella numerica e viceversa si opera esattamente come si opera per esempio nel convertire un numero decimale a binario e viceversa tenendo conto che appunto A=1, B=2, C=3, ... Y=25, Z=26

Ricorrendo alle funzioni nascoste di Excel presenti in delle dll che mi convertono le le etichette delle colonne nei rispettivi indici e viceversa, queste mi restituiscono un errore con Z, AZ, ... insomma con quelle colonne i cui indici sono congrui a 26 modulo zero

Per quello che mi serviva nel codice che ho realizzato mi sono dovuto scrivere io due funzioni che convertono le lettere delle colonne in indici delle colonne e viceversa

Tutto bene, ma poi non riesce a leggere correttamente i csv....

In Excel sono riuscito a creare del codice Windows in modo nativo appoggiandomi totalmente all'SDK di Windows stesso e fregandomi totalmente degli user form e dei vari controlli disponibili in Excel per la programmazione di macro con Visual Basic for Application.

Ho però trovato non molte magagne in Excel, la più clamorosa sono gli indici delle colonne dei fogli di calcolo che sono normalmente rappresentate con le lettere dell'alfabeto ma che sotto il cofano vengono tradotti negli indici numerici 1,2,3,4 ... (la colonna A ha indice 1 e non zero).

La codifica tra le etichette e gli indici numerici è banalmente il sistema di numerazione posizionale a base 26, solo che invece di utilizzare anche le usuali cifre numeriche (come accade per la rappresentazione esadecimale dei numeri) utilizza solo ed esclusivamente le lettere dell'alfabeto secondo la corrispondenza A=1, B=2, C=3, ..., X=24, y=25, Z=26, AA=27, AB=28 ecc. ecc..

Ora non è molto difficile comprendere che la conversione tra la rappresentazione letterale delle colonne e quella numerica e viceversa si opera esattamente come si opera per esempio nel convertire un numero decimale a binario e viceversa tenendo conto che appunto A=1, B=2, C=3, ... Y=25, Z=26

Ricorrendo alle funzioni nascoste di Excel presenti in delle dll che mi convertono le le etichette delle colonne nei rispettivi indici e viceversa, queste mi restituiscono un errore con Z, AZ, ... insomma con quelle colonne i cui indici sono congrui a 26 modulo zero

Per quello che mi serviva nel codice che ho realizzato mi sono dovuto scrivere io due funzioni che convertono le lettere delle colonne in indici delle colonne e viceversa

In VBA potevi fare riferimento ad una cella sia usando gli indici riga colonna, che usando il nome della cella es Cells(1,1) = Range("A1"), io mi sono abituato quasi subito ad usare solo gli indici perchè estremamente più comodi, se devi spostarti di 10 colonne per esempio è facilissimo fare Cells(1+10,1) piuttosto che calcolarsi A+10. Tra l'altro nelle opzioni di visualizzazione dell'interfaccia puoi anche passare dalle colonne "alfabetiche" a quelle "numeriche" e quindi non hai proprio più questo problema di conversione. Questo per dire che questa per me non è una magagna di excel, ma semplicemente una sua caratteristica (capisco però che possa dare qualche noia).

Il problema di excel è che è semplicissimo usarlo male.

In Excel sono riuscito a creare del codice Windows in modo nativo appoggiandomi totalmente all'SDK di Windows stesso e fregandomi totalmente degli user form e dei vari controlli disponibili in Excel per la programmazione di macro con Visual Basic for Application.

Ho però trovato non molte magagne in Excel, la più clamorosa sono gli indici delle colonne dei fogli di calcolo che sono normalmente rappresentate con le lettere dell'alfabeto ma che sotto il cofano vengono tradotti negli indici numerici 1,2,3,4 ... (la colonna A ha indice 1 e non zero).

La codifica tra le etichette e gli indici numerici è banalmente il sistema di numerazione posizionale a base 26, solo che invece di utilizzare anche le usuali cifre numeriche (come accade per la rappresentazione esadecimale dei numeri) utilizza solo ed esclusivamente le lettere dell'alfabeto secondo la corrispondenza A=1, B=2, C=3, ..., X=24, y=25, Z=26, AA=27, AB=28 ecc. ecc..

Ora non è molto difficile comprendere che la conversione tra la rappresentazione letterale delle colonne e quella numerica e viceversa si opera esattamente come si opera per esempio nel convertire un numero decimale a binario e viceversa tenendo conto che appunto A=1, B=2, C=3, ... Y=25, Z=26

Ricorrendo alle funzioni nascoste di Excel presenti in delle dll che mi convertono le le etichette delle colonne nei rispettivi indici e viceversa, queste mi restituiscono un errore con Z, AZ, ... insomma con quelle colonne i cui indici sono congrui a 26 modulo zero

Per quello che mi serviva nel codice che ho realizzato mi sono dovuto scrivere io due funzioni che convertono le lettere delle colonne in indici delle colonne e viceversa

welcome to basic :D :D

In VBA potevi fare riferimento ad una cella sia usando gli indici riga colonna, che usando il nome della cella es Cells(1,1) = Range("A1"), io mi sono abituato quasi subito ad usare solo gli indici perchè estremamente più comodi, se devi spostarti di 10 colonne per esempio è facilissimo fare Cells(1+10,1) piuttosto che calcolarsi A+10. Tra l'altro nelle opzioni di visualizzazione dell'interfaccia puoi anche passare dalle colonne "alfabetiche" a quelle "numeriche" e quindi non hai proprio più questo problema di conversione. Questo per dire che questa per me non è una magagna di excel, ma semplicemente una sua caratteristica (capisco però che possa dare qualche noia).
Offset(10,0). :O :cool:

o (0,10), non ricordo :p

Link alla notizia: https://www.hwupgrade.it/news/cpu/creata-una-cpu-a-16-bit-funzionante-dentro-microsoft-excel_123859.html

Una CPU a 16 bit completamente funzionante è stata riprodotta in Excel da uno youtuber che ha illustrato il tutto in un video. Capace di lavorare a 3 Hz, il processore include 128 KB di RAM, un display a 16 colori ed è accompagnato da un linguaggio assembly custom.
[/b]

Lo youtuber soffrirà sicuramente della sindrome di Lovelace :p

@dav1deser

Scusa conosci il codice che ho scritto per stabilire se è vero o non è vero che Excel ha delle magagne sugli indice delle colonne? Ribadisco senza se e senza ma ... Excel ha problemi con le colonne i cui indici sono congrui a 26 modulo zero. Punto!

Studiati le congruenze e prova a scrivere del codice ...

Purtroppo le potenzialità di excel sono da sempre accompagnate da un difetto fatale: la facilità con cui si può, passatemi il termine, craccare le protezioni.

Ad esempio se io voglio creare una foglio excel che esegue una macro e interrogando una DLL fa vedere a chi lo apre i dati della sua unità operativa per quanto possa proteggere la macro non ci vuole niente con un minimo di pratica a distruggere le protezioni e accedere al codice. A quel punto basta conoscere 2 bischerate di basic e la modifichi come ti pare.

Se risolvessero queste vulnerabilità sarebbe veramente uno strumento devastante.

Per affrontare e risolvere il problema di protezione che citi, basterebbe utilizzare un compilatore che converte il foglio di excel in un eseguibile, tipo XCell Compiler, xlCompiler...?

NON E' STATA CREATA NESSUNA CPU, è stata emulata. Imparare l'italiano, please.