Newsgroup: it.comp.lang.c
Titolo: Somma di milioni di cifre

Salve, cercavo su internet un programma in C che possa sommare due
numeri da un milione di cifre ed oltre... esiste?

 numeri da un milione di cifre ed oltre... esiste?
  Prova a guardare i sorgenti di bc per linux / unix

 numeri da un milione di cifre ed oltre... esiste?
http://gmplib.org/
Ciao  Manlio

 numeri da un milione di cifre ed oltre... esiste?
Se i numeri sono già in binario, puoi usare questo codice:
// tutti i numeri sono unsigned int
riporto = 0;
for (i=0; i<numero_interi; i++) {
  somma[i]=a[i]+b[i];
  if (riporto) somma[i]++;
  printf(" %1x + ",riporto);
  riporto = (somma[i] < a[i]) || (somma[i] < b[i]);
  printf("%08x + %08x = %1x%08x\n",a[i],b[i],riporto,somma[i]);
}
somma[i+1]=riporto;
Ciao
-- 
Enos


<snip>
tutto questo è così sbagliato da così tanti punti di vista che è
difficile anche iniziare una spiegazione.
Semplicemente, non fare _mai_ come sopra.
Ciao!

 come sopra. Ciao!
A me funziona... perché sarebbe sbagliato?
-- 
Enos


perché presuppone troppe cose, tra cui la notazione, il comportamento
all'overflow, la dimensione dei buffer, la dimensione degli indici -
insomma praticamente tutto.
Ciao!
P.S. Senza contare i nomi delle variabili in italiano, il commento su
una riga, il post-incremento sul for (tra le altre) scelte che
personalmente non riesco a digerire, ma che non c'entrano nulla con il
problema in oggetto.

 problema in oggetto.
alcune comprensibili altre un pò meno, scusa dove incrementi un tipico
contatore?

 problema in oggetto.
alcune comprensibili altre un pò meno, scusa dove incrementi un tipico
contatore?
O ne fai una questione di pre vs post?

 O ne fai una questione di pre vs post?
La seconda. Ovviamente è (come per i nomi delle variabili) più un
gusto personale che altro (anche se non è sempre stato così, almeno
per i pre-post incrementi).
Ciao!

 Ciao!
Senti lo capisco in C++
Pippo Pippo::operator++(int)
{
  Pippo temp(*this);
  incrementa();
  reutrn temp;
}
Pippo& Pippo::operator++()
{
	incrementa();
  return *this;
}
che ci guadagni ad usare la forma prefissa...
Ma in C se il compilatore è mediamente degno con i tipi nativi non
dovrebbe fare molta (nel 99% dei casi nessuna) differenza.
Premetto che anche a me piace prefisso.

 Ciao!
Senti lo capisco in C++


e giusto per fare il pirla ho messo i nomi delle variabili in italiano...
dai per fare un coding style
* si indenta con 4 spazi (sempre spazi non tab)
* nomi variabili, oggetti etc.. inglese
* Classi in CamelCase
* metodi e variabili in camelCase
* { } sempre su una nuova riga
* commenti /* */
* si usa le {} sempre e comunque anche su if a istruzione singola
* uso selvaggio dell'operatore ternario nelle operazioni...
ti piace?


wrote:

è meglio il prefisso per una serie di cose, tra cui una è quella che
hai fatto notare (e a cui non pensavo quasi più :D) - anche se qui si
programma in C un binding/wrapping tra i due linguaggi è sempre
comune.
Io ricordo invece dei problemi che aveva uno specifico compilatore
(che adesso purtroppo non mi sovviene) nell'ottimizzare i cicli for
con il post incremento.
Fatto sta che alla fine, te l'ho detto, è più una questione di gusti
personali nella "lettura del codice" che una necessità effettiva.
Ciao!

 ti piace?
ehehe, nel complesso direi proprio di sì ;-)
Aggiungerei anche:
* linee non più lunghe di 80 caratteri
* linee massime per funzione 20 (a meno di un blocco switch o if in
cascata)
* linee massime per file 400
* massimo livello di nesting 4
:)
Ciao!

 sempre e comunque.
Come mai?
Io ad esempio preferisco gli hard tab.

 Io ad esempio preferisco gli hard tab.
concordo. Anche perche' qualsiasi "editor degno di questo nome" ti
consente di visualizzare i tab larghi 8 oppure 4 oppure 2...
ciao
Giacomo

On Mar 29, 6:39 pm, Giacomo Degli Esposti

se è per questo qualsiasi editor degno di questo nome ti consente di
gestire una quantità di 8, 4 o 2 spazi come fossero hard tab.
comunque, è vero che si tratta di convenzione, ma è anche vero che
capita sempre il furbone di turno che, impostando male il suo editor,
scombina senza accorgersene l'indentazione di uno o più file facendo
dei tab. Lo spazio è spazio, quello è, quello rimane.
Ciao!

 Ciao!
Anche perch� qua molta gente usa il terminale, senza contare che a volte
i super visori si limitano ad usare less per leggere un sorgente o
qualche grep per saltare ad una funzione di particolare interesse e
quando ci sono i tab scazzati giustamente si incazzano come iene.
giusto per ribadire lo spazio � spazio...
Appoggio anche le 80 colonne come limite. :-)

 problema in oggetto.
In tale caso per cortesia non fare terrorismo per via di (parole tue) 
scelte personali.
Ciao
-- 
Enos

 In tale caso per cortesia non fare terrorismo per via di (parole tue) scelte personali.
Infatti non era terrorismo, era un elenco di scelte personali (parole
mie), oltretutto messo in PS.
Non volevo assolutamente offendere o insultare, e non è il caso di
prendersela se ho espresso un giudizio fortemente negativo su tre
righe del tuo codice. Potresti essere più bravo/esperto/preparato di
me sia in algoritmi che a programmare in C, ma di sicuro non è questo
che stiamo discutendo, e darmi del terrorista perché puntualizzo il
vero problema non mi sembra un comportamento costruttivo: se hai
qualche obiezione reale alle obiezioni mie scrivi e ne discutiamo
tutti, alla fine questo NG a questo serve.
Ciao!

 * uso selvaggio dell'operatore ternario nelle operazioni...
Arg! 
-- 
-riko

 Semplicemente, non fare _mai_ come sopra.
Sintentizzo il mio pensiero in modo oggettivo:
- il codice non comprende i controlli: si
- la sintassi non è la migliore: si
- l'algoritmo funziona e può essere reso sicuro: si
Ciao
--
Enos


ringrazio tutti per le tante risposte :-) io il programma l'ho fatto
personalmente... è abbastanza lunghetto, il mio problema è
l'efficienza... per ora è di 10 milioni di cifre sommate in circa 13
secondi... ora sto puntando al miliardo :-) GRAZIE ANCORA DELL'AIUTO!


Fortunatamente ci siamo chiariti in maniera pacifica ;-)
Sicuramente hai ragione, l'algoritmo "funziona e può essere reso
sicuro". Per completezza riporto la spiegazione più lunga di ogni
critica, punto per punto, di quello che intendevo inizialmente - tanto
per farti capire quelle che ho visto e che intendevo:
"la notazione": posso sommare solo numeri senza segno. Questo non è
stato specificato né come requisito né sopra l'algoritmo.
"il comportamento all'overflow": ovvero il fatto che siano unsigned
int è il fulcro dell'algoritmo. Mettendo dei signed non funzionerebbe
più nulla (in quando non il wrap-around non sarebbe garantito).
"la dimensione dei buffer": se voglio sommare un numero di un milione
di byte con un'altro da pochi bytes (diciamo facendo un +1) devo
aggiungere un po' di codice prima, dopo o durante, oppure richiedere
che i due buffer siano di uguali dimensioni, e che "somma" sia grosso
un'unità di più.
"la dimensione degli indici": la variabile i deve essere abbastanza
capiente, visto che non controllo l'overflow della stessa: questa è
una di quelle situazioni in cui utilizzando un normale int avrei
probabilmente un overflow.
Ciao!

 capiente, visto che non controllo l'overflow della stessa [...]
Effettivamente avrei dovuto specificare tutti quei limiti del codice, o  
scrivere un programma intero che fosse versatile e sicuro.
Grazie FtM, anche della pazienza
Ciao
-- 
Enos