Quote:
Originariamente inviato da Ziosilvio
L'errore sta proprio nel punto finale: a robs05 non serve un programma che "fallisce con probabilità bassa", ma glie ne serve uno che riesca sempre.
|
Qua ti sbagli tu: non fallisce, semplicemente una volta su 1000 (stimo) può tirarti fuori prima il 67 del 78, mentre i due dovrebbero uscire dall'urna contemporaneamente; se non ti basta puoi ovviare prendendo dei double, al che cominci a sconfinare nell'infinitesimo :> Ricorda che, qualsiasi cosa fai, con un calcolatore puoi sempre e solo approssimare la realtà; la stessa generazione dei numeri random è PSEUDOcasuale, quindi in qualsiasi caso introduci una "distorsione" dalla situazione reale
Quote:
Originariamente inviato da Ziosilvio
Un algoritmo corretto, eseguito su un input di grandezza finita, ha sempre tempo di esecuzione finito.
|
Nella teoria sì, per fortuna che poi subentra il mondo reale dei calcolatori, altrimenti sai che noia
Un esempio?
double a,b,c,d,e,f,g......
for (a=1;a<MAX;a++)
for (b=1;b<MAX;b++)
for (c=1;c<MAX;c++)
for (d=1;d<MAX;d++)
...
//aggiungi un altro po' di for
printf ("%d %d %d %d %d ...\n",a,b,c,d,e....);
Fino a quanti for e a quale valore di MAX credi che sta roba riesca a reggere in un tempo finito? Eppure l'algoritmo mi pare corretto (fa una semplice esplosione combinatoria) e l'input finito (numeri interi e limitati superiormente)