Newsgroup: it.comp.programmare
Titolo: codice c per fattoriale

salve a tutti, mi sto dilettando ad imparere un po il
linguaggio c, e dopo alcuni semplici esempi sono
arrivato ad un assurdo !!
ecco il codice di un algoritmo che dovrebbe
calcolare il fattoriale di un numero
#include<stdio.h>
#include<math.h>
int main() {
    int n,i;
    float f;
    i=1;
    f=1;
    printf("inserisci n\n");
    scanf("%d",&n);
    while (i<=n) {
                 f=f*i;
                 i=i+1;
                 }
    printf("il fattoriale e' %f\n",f);
    getchar();
    getchar();
            }
il problema � che questo programma, compilato
calcola correttamente il fattoriale fino a n=13
dopodiche sembra che spari numeri a caso..
qualcuno mi sa dire perch�?? 


Perche' hai usato un float.
Quando i numeri raggiungono un valore superiore al massimo esprimibile
con quel tipo di variabile, subentrano errori dovuti alla perdita
delle cifre meno significative.
Se hai bisogno di calcolare fattoriali di numeri grossi, devi usare
interi a precisione multipla, che non sono un tipo standard ma che
devi definire tu (con tutta la matematica di supporto ad esso) oppure
utilizzare qualche libreria gia' pronta.
In ogni caso il fattoriale e' piu' bello se definito ricorsivamente
int fact(int x)
{
  return (x==0) ? 1 : x * fact(x-1);
}

 In ogni caso il fattoriale e' piu' bello se definito ricorsivamente
Ma manco per niente. E' solo estremamente inefficiente.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Vorrei vedere come risolvi il sudoku senza usare la ricorsione!

Vorrei vedere come risolvi il sudoku senza usare la ricorsione!
Mai fatto un sudoku in vita mia. Poi mi spieghi cosa c'entri con
quanto si sta dicendo. Voglio comunque sperare che tu sappia che
qualsiasi ricorsione � riconducibile ad una iterazione.

 qualsiasi ricorsione è riconducibile ad una iterazione.
Si, ma al prezzo di quale codice confuso?
Sono mica tutti fattoriali le funzioni che capitano!
Voglio vederti a percorrere un albero usando l'iterazione.
Cosi' come voglio vederti risolvere un sudoku con l'iterazione, visto
che devi comunque memorizzarti tutte le posizioni prima di ogni
deviazione: tanto vale lasciare che lo faccia lo stack.

 Voglio vederti a percorrere un albero usando l'iterazione.
Non c'entra con quanto si sta dicendo in questo thread. Non buttarla in
caciara solo perch� hai detto una minchiata. A parte il fatto che tra
iterazione e ricorsione, nella navigazione di un albero, la complessit� �
la stessa, se hai una struttura dati adeguata (stack con push e pop),
scrivere un codice di navigazione iterativo � ESTREMAMENTE banale. Ma il
punto, come gi� detto, non � questo. Esistono contesti in cui pu� essere
pi� comodo usare l'iterazione della ricorsione e viceversa. Ma si tratta
di comodit� e di compromesso con l'efficienza. Nel caso del fattoriale
questo compromesso non si pu� pagare.


 scrivere un codice di navigazione iterativo � ESTREMAMENTE banale.
La ricorsione � lenta proprio perch� 
bisogna allocare dati sullo stack.
Creare una struttura dati con stack push 
e pop per usare l'iterazione al posto 
della ricorsione mi lascia perplesso.
In ogni caso spostare la complessit� 
sulla struttura dati e poi dire che 
l'algoritmo iterativo � semplice mi 
sembra arrampicarsi sugli specchi
in quanto la ricorsione � semplice sia 
dal lato dell'algoritmo sia della 
struttura dati.
Comunque se una buona fetta dello 
sviluppo della teoria (e anche pratica) 
della programmazione si sta muovendo 
verso la ricorsione tramite linguaggi 
funzionali (F#, erlang etc...) un motivo 
ci sar�.
Per ultimo, dire ad altri che stanno 
sparando minchiate e accusarli di 
buttarla sulla caciara... mah!?

buttarla sulla caciara... mah!?
E' vero.

 sono molto pi� che semplice ricorsione.
Di fatto per� la ricorsione � l'unico modo "puro" che si ha per
raggiungere la turing-completezza. I loop *necessariamente* hanno
bisogno di variabili modificabili: poi ci *sono* linguaggi funzionali
che hanno i loop, ma l'idea � che lo fanno per "pragmatismo", uscendo
dal modello funzionale per quello specifico costrutto. In pratica � una
forma di ibridizzazione, che va benissimo, figurati.
-- 
-riko

 Vorrei vedere come risolvi il sudoku senza usare la ricorsione!
Dipende cosa ho in mano e cosa mi sono costruito.
Ma che cavolo centra? :)
-- 
-riko

 deviazione: tanto vale lasciare che lo faccia lo stack.
No ascolta, non parliamo di algoritmi naive per fare i sudoku. Se
vogliamo parlare di algoritmi per risolvere i sudoku, visto e
considerato che ci sono, usiamo quelli. Tipicamente a seconda della
piattaforma su cui stai lavorando sceglierai una soluzione marcatamente
ricorsiva oppure una marcatamente iterativa. Ma il problema non � certo
li. Tipicamente vai a fare programmazione a vincoli e amen.
-- 
-riko

crescita.
Benissimo (e questo lo so anch'io), ma da qui a dire che "una buona
fetta dello sviluppo" sta passando o � passata ai linguaggi
funzionali, ce ne passa. Nei fatti non � vero. O non � ancora vero.
Comunque torno al punto di partenza: io non critico n� la ricorsione
(che mi piace), n� i linguaggi funzionali (che mi piacciono). 
Quando dico che la gente la "butta in caciara", voglio dire proprio
questo: uno critica un'applicazione della ricorsione e viene presa
come una critica all'intera branca dell'informatica che si occupa
dell'argomento.
Come ho detto nel mio messaggio di partenza, ci sono contesti in cui
usare la ricorsione � pi� comodo/elegante/conveniente rispetto
all'iterazione e contesti in cui vale il contrario. Il punto non �
questo. Io sto criticando UNA APPLICAZIONE della ricorsione.

 questo. Io sto criticando UNA APPLICAZIONE della ricorsione.
Che infatti era una cattiva applicazione, specie in C. Meno male che un
compilatore dovrebbe riuscire comunque ad ottimizzare quella cosa li. 
Apparentemente scheme (gambit) ci riesce, per lo meno. E' sempre meno
efficiente di fare le cose come si deve, ma tiene botta.
-- 
-riko