Newsgroup: it.comp.programmare
Titolo: esempi di ricorsione

Ciao a tutti.
Vorrei,per favore,alcuni esempi di funzioni ricorsive (non importa il
motivo per cuii sono state scritte),in c,c++,Basic,o anche qualche
altro linguaggio.
Se ne avete scritto qualcuna,e me la volete postare,mi farebbe
piacere.
Eventualmente,se mi date anche qualche link utile in questo
senso,tanto meglio.
Ciao e grazie


I'm not prejudiced, I hate everyone equally.

 Vorrei,per favore,alcuni esempi di funzioni ricorsive
Spero di esserti utile dandoti questo link:
http://www.iasi.rm.cnr.it/~adp/ProgramCorsoASD02-03.html
E' la pagina di un mio professore, Alberto Pettorossi con cui ho fatto 
l'esame di Fondamenti II, forse l'esame che piu' di tutti mi ha saputo dare 
qualcosa, piuttosto che succhiarmi risorse.
Nella sezione "Programmazione in C++" ci sono link a diversi sorgenti di 
programmi che fanno uso massiccio di ricorsione.
Ricordo ancora uno dei programmi da consegnare all'esame: "dato una 
espressione regolare, calcolare il corrispondente automa a stati finiti 
deterministico con il minimo numero di stati", forse la "cosa" 
concettualmente piu' complessa che abbia mai programmato in vita mia.
vagamente nostalgico,
stewie
-- 
there is no place like /home

Coefficiente binomiale.....
# include <stdio.h>
float fatt(int);
float binomiale_ric(int,int);
main()
{  int n,k;  float coef=1;
   do
 {printf("\nInserire n");
    scanf("%d",&n);
   }
   while (n<=0);
   do
   {printf("\nInserire k");
    scanf("%d",&k);
   }
   while (k<0 || k>n);
   printf("\nCoeficiente calcolato iterativamente  :");
   coef= fatt(n)/(fatt(k)*fatt(n-k));
   printf("\nIl coefficiente binomiale di %d su %d e : %.2f",n,k,coef);
   printf("\n\nCoeficiente calcolato ricorsivamente:");
   coef=binomiale_ric(n,k);
   printf("\nIl coefficiente binomiale di %d su %d e : %.2f",n,k,coef);
   fflush(stdin); getchar();
}
float fatt(int a)
{ int i,f=1;
 for (i=2; i<=a; i++)  f=f*i;
   return (f);
}
float binomiale_ric(int n,int k)
{ if (n==k || k==0) return (1);
 return (binomiale_ric(n-1,k)+binomiale_ric(n-1,k-1));
}

 altro linguaggio.
public int fatt(int num) {
        int ris=1;
        if (num!=0) 
                ris=num*fatt(num-1);
        return ris;
}
esempio classico: calcola il fattoriale di un numero.
ciao

 wrote in message
news:cf5qha...@192.168.1.1...

Però questo è un esempio di quando NON bisogna usare la ricorsione...
Kiuhnm

 Kiuhnm
Perchè per la velocita' di esecuzione?
vabbè ma si trattava di un esempio a scopo didattico...
in ogni caso è dimostrato che la ricorsione è più onerosa (se non sbaglio) 
in termini di memoria e di istruzioni quindi come dici tu non dovrebbe 
essere usata affatto...
ciao

 essere usata affatto...
Intendevo dire che per alcuni problemi non esistono soluzioni iterative e
per questo bisogna ricorrere a quelle ricorsive. Perň, quando č possibile, č
preferibile la versione iterativa.
Nel caso del fattoriale la prima cosa alla quale pensi č il ciclo for,
giusto?
Poi, visto che qualcuno ti ha chiesto un esempio di ricorsione, dici:
"facciamolo ricorsivo"!
Perň č piů difficile pensarlo ricorsivamente che iterativamente, invece Le
Torri di Hanoi (per fare un esempio) č facilissimo ricorsivamente e (quasi?)
impossibile iterativamente.
E non mi riferisco al falso iterativo dove ci si costruisce uno stack di
richieste in software (il Fortran non supportava la ricorsione).....sempre
ricorsivo rimane (anzi č ancora piů lento).
Kiuhnm
P.S. Non era una critica a te: ho capito lo scopo didattico; era una
precisazione per chi ha posto la domanda.



il seguente programma C dovrebbe disegnare triangoli come:
@
@@
@@@
@@@@
@@@@@
@@@@@@
#include <stdio.h>
void g(int b, char c)
{if(b==0) return;
 g(b-1,c);
 while(b--) 
    putchar(c);
 putchar('\n');
}
int main(void)
{ g(6,'@');
  g(20,'X');
  return 0;
}

 precisazione per chi ha posto la domanda.
Puoi vedere la mia risposta nella stessa vena: capire bene i
rapporti fra iterazione e recursione e` didatticamente molto
importante, quindi precisazioni accurate possono aiutare.
Poi bisognerebbe parlare della TAIL recursion, perche` e` un
caso particolare importante ecc ecc, ma questo post e` gia`
piuttosto lungo...
Alex

 per questo bisogna ricorrere a quelle ricorsive.
Per esempio ?
Mai sentito parlare della possibilita' di tradurre qualsiasi programma
iterativo in ricorsivo e viceversa ?
--------------------------------
Inviato via 
http://usenet.libero.it

 per questo bisogna ricorrere a quelle ricorsive. P
mi sa che è proprio il contrario...
 

 possibile, č preferibile la versione iterativa.
dipende da quale e` la "preferenza": se cerchiamo di ottenere il codice 
piu` veloce possibile hai ragione: ma spesso la velocita` non e` lo 
scopo primario: se chiarezza, semplicita`, rapidita` di sviluppo sono 
piu` importanti della velocita` d'esecuzione a volte una funzione 
ricorsiva si adatta meglio allo scopo.
ciao Anto
-- 
Antonio Cuni, 20 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 stack.
Hai perso qualcosa per strada:
"E non mi riferisco al falso iterativo dove ci si costruisce uno stack di
richieste in software (il Fortran non supportava la ricorsione).....sempre
ricorsivo rimane (anzi è ancora più lento)."
Un metodo iterativo il cui numero di cicli è influenzato da uno stack di
"richieste" o "compiti", resta pur sempre ricorsivo.
Kiuhnm

 wrote in message
news:gv8uha...@192.168.1.1...

Mi fai la versione iterativa di Hanoi *senza* usare alcuno stack?
Semplicemente con cicli?
Magari ne troverai anche una, ma sarà mostruosamente complessa e alla fine,
se semplificata, probabilmente si ricondurrà alla versione ricorsiva.
Kiuhnm

 set di algoritmi computabili, comunque.
Per ridurre lo stack è sufficiente utilizzare la versione ricorsiva con
variabili globali. Le var. che dovranno rimanere locali, probabilmente
saranno le stesse che inserirai nel tuo stack esplicito.
Se nella versione iterativa mi basterà inserire nello stack le var. A, B e
C, allora mi basterà una funzione ricorsiva contenente solo A, B e C.
Naturalmente resta sempre un RET ADDR posto sullo stack dalla chiamata. Però
pone una informazione in più e potrebbe limitare il numero di var.
necessarie.
Kiuhnm

 iterativo in ricorsivo e viceversa ?
Per esempio un metodo di Back Tracking deve essere programmato in modo
ricorsivo.
E ripeto, non accetto l'"iterativo con stack implicito" che per me resta
sempre concettualmente ricorsivo e anzi meno efficiente.
Kiuhnm

 "richieste" o "compiti", resta pur sempre ricorsivo.
No e poi no. Hai uno strano concetto di ricorsione. Un metodo iterativo e'
iterativo, punto e basta. Non c'e' verso di implementare la ricorsione se
non fornendo all'iterazione il supporto adatto a ricostruirne la stessa
logica (leggi: lo stack). Ma questa e' e resta *iterazione*, non
*ricorsione*.


 sempre concettualmente ricorsivo e anzi meno efficiente.
Non lo e' ed e' da dimostrare che sia meno efficiente.
Un metodo iterativo resta iterativo (che poi concettualmente implementi una
logica simile a quella ricorsiva e' tutt'altro discorso).


 *ricorsione*.
La pensiamo allo stesso modo, solo che io mi *ostino* a non considerarla
_iterazione_ perchè sempre _ricorsione_ rimane.
Kiuhnm

 logica simile a quella ricorsiva e' tutt'altro discorso).
Perchè le funzioni ricorsive sono da evitare il più possibile? Perchè sono
lente e consumano molto stack per le chiamate annidate.
Quelle iterative che si basano sullo stack non si comportano in maniera
molto diversa. Utilizzano ugualmente lo stack, ma riducendone il consumo al
minimo. Comunque i compiti da eseguire seguono la solita logica "ricorsiva".
Se si riscrive la funzione ricorsivamente usando come var. locali solo
quelle indispensabili alla ricorsione e definendo le altre come globali (o
meglio, in uno scope più esterno, ma sempre interno al gruppo di funzioni
che gestiscono la ricorsione), si ottiene lo stesso consumo limitato di
stack senza dover gestire lo stack manualmente (operazione più lenta della
gestione in hw).
Ammetto di non averci mai provato, ma intuitivamente mi convince...
Se nella iterativa basta salvare sullo stack A, B e C, allora significherà
che anche alla versione ricorsiva servono solo 3-4 variabili (forse
addirittura 1 in meno della iterativa).
Se poi si scrive la ricorsiva usando 200 KB di variabili locali è un altro
discorso.
Mettendo da parte per un momento la nostra attitudine alla conflitto ;-),
hai capito che cosa voglio dire? Che cosa ne pensi?
Kiuhnm

 ricorsiva.
se è iterativa è iterativa... che significa semplificare? 

 _iterazione_ perchè sempre _ricorsione_ rimane.
Ostinazione alquanto stupida, a mio avviso.
Un'iterazione non e' una ricorsione, proprio perche' e' un'iterazione.
Facci tutti i ricami che vuoi, ostinati nel credere quello che vuoi, ma nei
fatti, e' cosi'.
Passo e chiudo.


 addirittura 1 in meno della iterativa).
Non si sta parlando di trasformare l'iterazione in ricorsione, ma la
ricorsione in iterazione.
Il discorso e' inverso. Se nella funzione ricorsiva hai le variabili locali
A, B, C, di quante variabili hai bisogno nella versione iterativa ?
Rispondi a questa domanda (se mi dici 3 ci hai capito poco ;).


 Ho usato moltissime funzioni ricorsive, non le ho mai trovate piu' lente.
Beh da quel che so io una funzione ricorsiva è più lenta in quanto
eseguire un numero elevato di chiamate di funzione consuma il tempo di
esecuzione di un processore. Ovviamente la perdita non è nulla di
importante ma c'è.
IMHO
Scute l'intrusione,
Ciao !
Nicholas

 Passo e chiudo.
<cite>
L'iterazione e la ricorsione sono basate entrambe su una struttura di
controllo: l'iterazione utilizza una ripetizione; la ricorsione utilizza
una selezione. L'iterazione e la ricorsione richiedono entrambe una
ripetizione: la prima utilizza esplicitamente una struttura di quel
tipo; la seconda invece la ottiene attraverso ripetute chiamate di
funzione. L'iterazione e la ricorsione richiedono entrambe un controllo
di terminazione: l'iterazione terminerà quando sarà fallita la
condizione di continuazione del ciclo; la ricorsione invece terminerà
quando sarà riconosciuto un caso di base.
<....>
Qualsiasi problema che possa essere risolto in modo ricorsivo potrà
essere risolto anche in maniera iterativa (non ricorsiva). Normalmente
l'approccio ricorsivo sarà preferito a quello iterativo, qualora il
primo rispecchi in modo più naturale il problema e produca un programma
che sia più facile da comprendere e collaudare. Un'altra ragione per
scegliere una soluzione ricorsiva è che quella iterativa potrebbe non
essere evidente.
</cite>
Dal D&D. Io le ho studiate così.
Ciao !
Nicholas

 Ho usato moltissime funzioni ricorsive, non le ho mai trovate piu' lente.
Beh da quel che so io una funzione ricorsiva è più lenta in quanto


 esecuzione di un processore.
Anche il salto all'inizio di un ciclo, in un'iterazione, "consuma il tempo
di esecuzione di un processore", non vedo dove sia la differenza. Se ti
preoccupa il passaggio dei parametri, su molti sistemi e' fatto tramite
registri (e non tramite stack) ed e' molto piu' veloce rispetto a quanto
avviene, in un'iterazione, se si e' costretti a leggere la variabile in
memoria.


 essere risolto anche in maniera iterativa (non ricorsiva).
<...>
E' cio' che sto affermando.


 E' cio' che sto affermando.
Tant'č... ho postato sotto per dire che anch'io la pensavo cosě.
Nicholas

Non ci capiamo.....sei proprio fuori.......se la profondità della ricorsione
è imprevedibile lo è anche la profondità del tuo stack virtuale quindi evita
di dire fesserie.
Mi sono proprio rotto le scatole...
Ciao, Kiuhnm

 wrote in message
news:80Z105Z34Z80Y1...@usenet.libero.it...

Bella stronzata questa....si vede che programmi in assembly....
Kiuhnm

 di "richieste" o "compiti", resta pur sempre ricorsivo.
la definizione piu` banale di ricorsione e` questa:
"una funzione e` ricorsiva se richiama se stessa"
ovviamente un algoritmo iterativo che usa uno stack non risponde a questa 
definizione, per cui l'intero mondo lo considera *non* ricorsivo.
Cmq, accettiamo anche la tua definizione di ricorsione e, per evitare 
confusione, chiamiamola "kiuhnm-ricorsione". Ora, considera questi 
spezzoni di codice:
stack st;
for(int i=0; i<10; i++)
        st.push(i);
while( !st.empty() )
        cout << st.pop();
e` un programma iterativo che utilizza uno stack: dobbiamo considerarlo 
kiuhnm-ricorsivo oppure no?
Altro esempio: considera l'algoritmo per effettuare la ricerca in 
ampiezza in un grafo:
queue q;
q.push( <primo vertice> );
while ( ! q.empty() )
        node n = q.pop();
        <visita n>
        <per ogni nodo p non ancora visitato e collegato a n>
                q.push(p);
E` iterativo o kiuhnm-ricorsivo? Ora fai un bel 
        search&replace("queue", "stack")
e ottieni l'algoritmo per la visita in profondita`: e` iterativo o 
kiuhnm-ricorsivo?


 importante ma c'è.
probabilmente e` vero per la maggior parte delle architetture in 
circolazione, ma in questo thread non abbiamo mai fatto riferimento ad 
una architettura specifica, per cui non sappiamo se l'ipotetica 
istruzione CALL sia piu` o meno veloce di una ipotetica INC o JUMP.
Se non facciamo riferimento a nessuna architettura specifica non ci resta 
che esaminare il costo computazionale degli algoritmi, ma in questo caso 
e` facile vedere che non c'e` alcuna differenza tra l'implementazione 
ricorsiva e quella iterativa.


 Bella stronzata questa....si vede che programmi in assembly....
Kiuhnm, ripeto, le "stronzate" sono quelle che compaiono nei TUOI messaggi.
A tutti e' noto (meno che a te, ma non me ne meraviglio) che la lettura da
un registro e' molto piu' veloce che la lettura dalla memoria e a tutti e'
noto (meno che a te, ma non me ne meraviglio) che il default di passaggio
dei parametri per molti compilatori e' quello tramite registri e non tramite
stack.


virtuale quindi evita di dire fesserie.
Caro K., ci sono CASI in cui la profondita' di una ricorsione non e'
prevedibile e quindi e' bene usare la ricorsione, al posto della iterazione.
Ci sono CASI in cui sai benissimo a che livello la ricorsione finisce e qual
e' il numero massimo di chiamate ricorsive possibili e quindi, in questo
caso, puoi stabilire a priori quanto e' grande, massimo, il tuo stack.
Ma anche nel primo caso, nessuno mi vieta, se proprio voglio ricorstruire la
ricorsione con una iterazione, di avere uno stack ridimensionabile, mano a
mano che si va avanti.
Evidentemente sei abituato a discutere di cose che non conosci
sufficientemente bene e ti illudi che cio' che scrivano gli altri siano
fesserie. Credilo pure, non mi interessa.


 kiuhnm-ricorsivo?
E' kricorsivo.
Per me un algo è kricorsivo quando utilizza stack, code o altro ed è
"banalmente convertibile" in ricorsivo.
Oppure forse potrei dire che è kricorsivo se percorre una struttura
ricorsiva e ha bisogno di memorizzare in qualche modo il percorso compiuto
(solitamente a partire dal primo nodo)
La ricorsione lo fa implicitamente, la k-ricorsione esplicitamente,
l'iterazione non lo fa e basta.
Conosco la definizione di ricorsione e l'accetto però esistono dei casi
limite dove un'iterazione è praticamente una ricorsione e viceversa.
Semplicemente mi dà fastidio chiamare iterativo, nel senso di puramente
iterativo, qualcosa che è la banale traduzione di un algo ricorsivo.
E comunque una funzione è ricorsiva se chiama se stessa, ma che cos'è una
chiamata se non un salvataggio di dati sullo stack e un salto (in questo
caso) al solito indirizzo (equivalente a vari push e a un jmp (o un ciclo
complessivamente))?
La k-ricorsione non è altro che un emulatore per la ricorsione.
E' come se installassi un emulare per PSX sul PC e qualcuno mi chiedesse:
"stai giocando alla PSX"? No, sto giocando al PC.............avrei detto la
verità, ma sarebbe concettualmente poco corretto....
Kiuhnm

 memoria.
Perchč in un'iterazione si dovrebbe essere costretti a leggere la variabile
dalla memoria?
E secondo te in una fastcall i dati non passano per la memoria prima?
E se non č necessario che passino per la memoria perchč dovrebbe esserlo nel
ciclo iterativo?
Programmo in ASM da almeno 10 anni e ho scritto milioni di righe di codice
quindi evita di dire "stronzate" e di ostentare conoscenze che non hai.
Kiuhnm

 fesserie. Credilo pure, non mi interessa.
E tu invece, come vedi, hai confermato 1 volta quello che avevo scritto e le
altre volte hai semplicemente mancato il punto...
Kiuhnm

 quindi evita di dire "stronzate" e di ostentare conoscenze che non hai.
Senti K, cominci a stancare, ti ripeto che le cosiddette "stronzate" stanno
uscendo continuamente dalle tue ditina, che purtroppo ti ostini a battere
sulla tastiera.
Un loro sano sciopero farebbe bene a tutti quanti.
Sappi che dicendo che programmi da almeno 10 anni in asm non spaventi
proprio nessuno e non e' affatto detto che i milioni di righe di codice che
hai scritto tu non li abbia scritti alla kiuhnm maniera, ovvero non e' detto
che siano necessariamente corretti.


 <Non contrasta con quanto ho detto>
Idem. Non c'entra nulla con quanto hai detto.


 che siano necessariamente corretti.
Sei veramente esilarante........di programmazione a basso livello non sai
veramente niente.
Non sai come funziona un compilatore, non sai cos'è una variabile locale,
non sai come vengono implementate dai compilatori, ecc..ecc....va là sarà
meglio che smetta di risponderti altrimenti muoio dal ridere....ahahah
Kiuhnm

 Idem. Non c'entra nulla con quanto hai detto.
ROTFL......o mio Dio, siamo a questi livelli allora........
Kiuhnm

Ho usato moltissime funzioni ricorsive, non le ho mai trovate piu' lente.
forse mi sbaglio, ma mi sembra di aver letto che è il compilatore che
rimuove la ricorsione trasformandola in iterazione
 

"av" <a...@av.av> wrote in message news:3d458d3...@news.tin.it...

Nah....non oserebbe mai a meno che qualche compilatore non lo permetta nelle
opzioni (in Visual C e Borland C non ho mai trovato niente di simile).
Comunque secondo me andrebbe tutto più lento....
Kiuhnm

Ciao ragazzi,e grazie a tutti..
Alberto

 Comunque secondo me andrebbe tutto pių lento....
   Consiglio: Internet e` una fonte di informazioni senza fondo, e 
Google ne e` il profeta, non fare affermazioni cosi` categoriche senza 
averci prima fatto un giro...
<cite src="
http://www.nullstone.com/htmls/category/tailrec.htm
">
	Tail Recursion
	A tail-recursive call can be replaced with a goto, which
	avoids the overhead of the call and return and can also
	reduce stack space usage.
	Example:
	In the code fragment below, the tail-recursive call to f()
	can be replaced with a goto.
		int f (int i)
		{
		  if (i > 0) {
		    g (i);
		    return f (i - 1);
		  }
		  else
		    return 0;
		}	
	Below is the code fragment after tail recursion.
		int f (int i)
		{
		entry:
		  if (i > 0) {
		    g (i);
		    i--;
		    goto entry;
		  }
		  else
		    return 0;
		}
	Notes:
	Tail recursion can significantly improve the performance
	of small recursive benchmarks such as Hanoi. Although
	more difficult than simple tail recursion, it is also
	possible to optimize a() calls b() calls a() tail
	recursion.
</cite>
   Il GCC e` certamente uno dei migliori compilatori C che esistano, in 
particolare per quanto riguarda le ottimizzazioni, comunque non penso 
che Visual C++ e Borland C++ non siano in grado di comportarsi similmente...
-- 
Alla prossima,
Marco

 che Visual C++ e Borland C++ non siano in grado di comportarsi
similmente...
I compilatori ottimizzano i programmi, ma non li stravolgono completamente.
Mi capita spesso di esaminare il codice asm di programmi compilati dal
Visual C e non ho mai trovato cose del genere.
Kiuhnm

 Ciao ragazzi,e grazie a tutti..
Non partecipi al linciaggio??? :-)
Kiuhnm

 Visual C e non ho mai trovato cose del genere.
   LOL! Uscite come questa qualificano molto piu` di un intero thread...
-- 
Alla prossima,
Marco

    LOL! Uscite come questa qualificano molto piu` di un intero thread...
Solo perchè tu non lo sai fare, chi lo afferma dovrebbe mentire o fare il
pallone gonfiato?
Ho semplicemente detto la verità. Non posso dire che come lavoro programmo
kernel debugger?
Parlare con gente come te mi arricchisce sempre profondamente...
Kiuhnm

 pallone gonfiato?
   Non so se menti o meno ma quello che scrivi ti qualifica in modo 
abbastanza preciso: se non vuoi essere frainteso, allora parla come 
lavori e nessuno ti prendera` in giro; al momento, non lo stai davvero 
facendo.
-- 
Alla prossima,
Marco

 facendo.
A casa mia leggere disassemblati è una cosa normale e doveva pensarla così
anche la Microsoft (che tuttavia stimo pochissimo...) che ha perfino
aggiunto l'hotkey ALT-8
(in msdev).
Hai paura di diventare cieco leggendo troppi disassemblati???
Kiuhnm

 iterativo, qualcosa che è la banale traduzione di un algo ricorsivo.
e non potevi dirlo subito? E` una settimana che mezzo newsgroup cerca di 
farti capire la definizione di "ricorsivo" e poi tu dici che la sapevi 
gia` ma non ti stava simpatica?


 QUESTO E' FALSO!
[cut]
ma non ti sorge il dubbio che se 4/5 persone continuano a farti notare i 
tuoi errori sei tu che sbagli e non loro?


 RICORSIVE.
non hai ancora chiarito cosa tu intendi per "ricorsione". Dacci una 
definizione, cosi` siamo tutti contenti.
ciao Anto


 gia` ma non ti stava simpatica?
eh già....non s'era capito?
Intendevo dire che se a qualcuno chiedo "trovami un algo iterativo per
risolvere questo problema", non accetto un algo iterativo che usa uno stack
perchè evidente trasposizione dell'algo ricorsivo (magari anche
stra-conosciuto).
Kiuhnm
P.S. Qualsiasi (e intendo dire proprio *qualsiasi*) algo iterativo può
essere convertito in ricorsivo, infatti qualsiasi ciclo può essere
implementato ricorsivamente. IMHO, sei tu ad avere le idee molto confuse.

 Hai paura di diventare cieco leggendo troppi disassemblati???
   Non la trovo una pratica cosi` utile: se qualcosa non va come mi 
attendevo andasse, allora e` una possibilita` da prendere in 
considerazione, altrimenti preferisco fidarmi degli strumenti che uso 
(in particolare, dell'a-te-ignoto GCC, che produce ottimi programmi).
-- 
Alla prossima,
Marco

 magari pure legittimamente, aspiri.
Le mie frasi vogliono farti capire che sei troppo schematico e hai troppi
pregiudizi per quel che riguarda la programmazione. Vedi tutti bianco o
nero: questo è impossibile (visita in ampiezza ricorsiva.....ti è piaciuto
il codice che ti ho fatto?), l'Info è una branca della Matematica e non
comprende opinioni personali.......ROTFL!
Il grande software nasce proprio quando le persone hanno idee personali.
Tempo fa ho domandato su vari ng, a programmatori affermati e perfino alla
MS se era possibile fare una certa cosa.
Mi hanno TUTTI risposto che era *assolutamente* impossibile.
Ovviamente mi sono indignato: da come mi hanno risposto si è capito che
pensavano "Che cos'è che vuole fare 'sto cretino? Spostare IDT, GDT, TLB
mentre Windows è attivo? Rotfl!!!".
Beh, adesso il mio debugger fa proprio questo (assolutamente l'unico tra
tutti) e chi mi aveva risposto non si è nemmeno degnato di dire qualcosa
tipo: "sì, si poteva fare, scusa se ti abbiamo risposto in quel modo" Ma no,
non mi hanno neanche risposto.
Palloni gonfiati che credono di sapere tutto e invece ignorano l'unica cosa
importante: "La programmazione è *continua* scoperta e invenzione".
Questo dovrebbe inquadrarmi un po' meglio....mi piacciono le sfide e spesso
le vinco...
Mi piace contraddire chi dice "impossibile": sono fatto così.
Kiuhnm

 Mi piace contraddire chi dice "impossibile": sono fatto cosě.
   Sei fatto parzialmente bene: cerca solo di controllare prima i motivi 
per cui ti viene detto che e` impossibile.
-- 
Alla prossima,
Marco

 wrote in message
news:ai8fnk$3qd$1...@newsreader.mailgate.org...
Sei bravo a parlare, ma dimmi soltanto due cose:
1) il codice che ho scritto è ricorsivo?
2) esegue la visita in ampiezza di un grafo?
Dei sì o no basteranno.
Facciamo come gli struzzi?
Kiuhnm

 confuse.
perche`, secondo te non lo sapevo?
Tu confondi gli algoritmi con la loro implementazione: un algoritmo e` un 
insieme di regole che mi dicono quali operazioni compiere per risolvere 
un determinato problema, l'implementazione di un algoritmo e` la 
formalizzazione di tali regole in un linguaggio di programmazione.
E l'implementazione che puo` essere ricorsiva o iterativa, non 
l'algoritmo in se: il quicksort e` sempre il quicksort sia che sia 
implementato come iterativo che come ricorsivo, e cosi` tutti gli altri 
algoritmi.


 algoritmi.
Non è vero niente!
L'implementazione può essere ricorsiva o iterativa così come l'algoritmo può
essere ricorsivo o iterativo.
Per esempio per uscire da un labirinto esistono versioni iterative
ovviamente implementabili iterativamente o ricorsivamente e versioni
ricorsive ovviamente implementabili iterativamente o ricorsivamente.
Per esempio se ti trovi veramente in un labirinto, non puoi usare una
versione ricorsiva, ma iterativa.
Tu hai letto troppi libri e usato troppo poco la tua testa......ecco che
cosa penso.
E comunque hai fatto un *grave* errore dicendo che la visita in ampiezza non
era implementabile ricorsivamente.
Io sono riuscito a fare in un'oretta quello che tu hai definito impossibile
e vieni a dire a me che non so programmare?
Tu, come tutti i professori che ho conosciuto all'Università sei 90%
matematico e 10% informatico.
Questo proprio non va...
Kiuhnm

 problema e` labile. 
visto che stiamo matematicamente parlando...
che significa numero sufficiente di ipotesi?
che significa problema labile?
in ogni caso non mi sembra corretta come frase perchč si possono dimostrare 
piů tesi naturalmente non contrastanti (anche questo non č del tutto 
vero... ma lasciamo perdere ci 
allontaniamo troppo dal discorso :-))

 Questo proprio non va...
come ti e` gia` stato fatto notare informatica e matematica sono piu` 
imparentate di quanto tu creda: senza la matematica l'informatica non 
sarebbe neppure nata, quindi non ci vedo nulla di male.
Cmq dalla tua frase mi sembra di capire che hai frequentato 
l'universita`, ma non ci hai ancora detto se ti sei laureato o no...


 l'universita`, ma non ci hai ancora detto se ti sei laureato o no...
L'ho frequentata per 1 anno e mezzo prendendo i miei 30 nelle materie che
m'interessavano (poche....TAMC/calcolo numerico e qualcun'altra) e qualche
25 in quelle tipo analisi, fisica...
Non sono mancati i momenti di conflitto con i prof. Ho notato subito che
quel mondo non faceva per me: persone rigide che non ammettono mai di aver
sbagliato nemmeno dopo aver toccato con mano (come si dice: "il professore
ha sempre ragione :-)")
Mi è stato fatto capire che all'Università "non c'è spazio per i
*sovversivi*", così l'ho lasciata e ho potuto riprendere la mia attività.
Adesso programmo kernel debuggers / decompilatori, ecc... e presto inizierò
a vendere il mio primo prodotto (speriamo...)
Kiuhnm

a vendere il mio primo prodotto (speriamo...)
Programmi kernel debuggers per lavoro oppure hobby?
--
Rhymes (
rhy...@myself.com
)
http://www26.brinkster.com/rhymes
" ride or die "

 Programmi kernel debuggers per lavoro oppure hobby?
E' nato come hobby, ma adesso è diventato lavoro.
Diciamo che sono un libero professionista.
Mi piacerebbe programmare e distribuire tutto come freeware, ma a questo
mondo bisogna anche guadagnare.
Ormai sono dietro a questo debugger da 2 anni.
Credimi, chiamarlo debugger è mooolto riduttivo.
Preferirei il termine "micro-os".
All'inizio ci ho lavorato poco perchè avevo l'Università che mi portava via
molto tempo, ma quest'anno ci sto lavorando molto assiduamente.
Kiuhnm

molto tempo, ma quest'anno ci sto lavorando molto assiduamente.
come ti dissi su it.comp.lang.assembly attendo l'NDA da firmare :)


 ha scritto nel messaggio
news:Ail19.139085$Jj7.3...@news1.tin.it...

Kiuhnm ho letto il thread e mi sono appassionato ! E mi veniva in mente che
forse ti farebbe bene un po di informatica teorica :)!!!! Pensaci su ciao
:)!

 wrote in message
news:nVk29.157311$Jj7.3...@news1.tin.it...

Non credo proprio.....a voi comunque farebbe bene un po' di
programmazione....a quanto pare l'informatica non basta.....
E comunque da che cosa lo deduci?
Dal fatto che non sono d'accordo sulla definizione di iterativa/ricorsiva?
Le 2 definizioni sono insufficienti a descrivere la tipologia di algoritmo e
implementazione utilizzata! Dovresti averlo capito leggendo i thread, ma a
quanto pare...
Dal fatto che sono riuscito a fare qualcosa che l'Informatico
super-acculturato riteneva impossibile?
Dal fatto che quasi qualsiasi cosa voi pensiate che sia assoluta è in realtà
approssimativa e confutabile?
Lo scopo finale è saper programmare e tutto è lecito pur di raggiungere lo
scopo.
La programmazione è inoltre settoriale: alcuni sono esperti di teoria della
programmazione, teoremi e *ca..ate* varie, altri sono esperti di reverse
enginnering, asm, firmware, ecc... e queste nozioni non vengono solo dai
libri, ma dall'esperienza diretta......e tutt'altra cosa, credimi.
Non è un attacco, voglio solo capire che cos'hai capito da tutto questo
thread.
Kiuhnm
P.S. La storia racconta che la maggiorparte degli algoritmi di
programmazione sono stati inventati dagli hacker (appassionati - termine
ormai "arcaico"!) e non dai professori o dai ricercatori. Serve intuito e
purtroppo non viene dai libri: c'è chi ce l'ha e chi non ce l'ha.

 ormai "arcaico"!) e non dai professori o dai ricercatori.
Vorrei vedere la faccia di Don Knuth quando gli diranno che e' uno dei piů 
grandi hacker viventi :-)
stewie
-- 
there is no place like /home

 grandi hacker viventi :-)
Il mondo è grande: non c'è solo Don Knuth e comunque questa statistica l'ho
trovata su qualche libro di programmazione, ma adesso non ricordo i titoli.
Uno era di Schildt se non sbaglio...
Kiuhnm

 Uno era di Schildt se non sbaglio...
AHAHAHAHAHAHA Schildt ! ora si spiega tutto !!!!
E' uno degli scrittori di Informatica peggiori che esistano...
Non mi meraviglio, ora, che tu abbia tali conoscenze (vogliamo parlare
del tuo: "un puntatore e' un DWORD" ??) ;))

 wrote in message
news:bfaaa329.02080...@posting.google.com...

*plonk*
Kiuhnm

*plonk*
su Schildt Andrea ha ragione (ma non solo Andrea...)
fatti un giro su 
accu.org


 fatti un giro su 
accu.org
Ho scritto: "uno era di Shildt".
Le statistiche le sa leggere anche lui, no?
E gli altri libri di cui non ricordo nome e/o autore dove li lasciamo?
Kiuhnm

 *sovversivi*", 
A mio avviso, il termine "sovversivo", nel tuo caso, e' una scelta di
decenza ;)
Se uno dovesse giudicare le tue (stupide, IMHO) puntate di piedi, in
tutti i thread in cui ti vedo intervenire, dovrebbe usare qualcosa di
molto piu' offensivo ;)  Tu credi di "far toccare con mano" agli altri
delle verita', quando invece chi non ha afferrato realmente i concetti
base sei tu.
Forse e' questa la causa del tuo fallimento universitario ;)

 meglio che smetta di risponderti altrimenti muoio dal ridere....ahahah
Certo, certo, sono gli altri che non sanno :)... ROTFL !!! :)
--------------------------------
Inviato via 
http://usenet.libero.it

 Le statistiche le sa leggere anche lui, no?
Ma *quali* statistiche ?? penoso... veramente penoso...


 ha scritto nel messaggio
news:ttT29.182251$vm5.5...@news2.tin.it...

Uff non c'è peggior sordo di chi non vuol sentire !!!
Ciao !!

 Uff non c'è peggior sordo di chi non vuol sentire !!!
e non c'è peggior cieco di chi non vuol leggere...
Kiuhnm

 ha scritto nel messaggio
news:_WZ29.164301$Jj7.3...@news1.tin.it...

Si ma almeno io accetto di farmi guidare da un cane apposito!! Tu credi di
non aver bisogno delle risposte che ti si danno qui per cui credo che tu sia
irrecuperabile !!
Come diceva Arighe:"Ci vuole Umiltè (umiltà)!!!". Tu non ne hai proprio !
PS.: Ah se devi rispondere fallo per dimostrare il contrario sennò stiamo a
perdere tempo qui!
CIAO!

 termine ormai "arcaico"!) e non dai professori o dai ricercatori.
certo, certo. Turing, Knuth, Dijkstra, Von Neumann, Hoare: tutti 
famossisimi hacker!


 i titoli. Uno era di Schildt se non sbaglio...
hai studiato sui libri di Schildt? Si iniziano a capire molte cose...


 ciao Anto
Bhuahahahaha !!! GRANDE ANTONIO !!!

 hai studiato sui libri di Schildt? Si iniziano a capire molte cose...
Qualsiasi programmatore può avere qualcosa da insegnare.
Hai studiato sui libri di un solo autore?
Adesso si spiegano molte cose...
Siete così ottusi da non capire neppure di cosa si stia parlando.
Credete ancora che si stia discutendo di ricorsione?
Tutte le volte che non avete saputo rispondere a qualcosa vi siete rifugiati
nelle definizioni.
Qualche volta le definizioni vanno estese e nel campo della
ricorsione/iterazione penso che ce ne sia proprio bisogno.
Pensavo di avervi aperto gli occhi mostrandovi i vari problemi e/o
superficialità della definizione di ricorsione, ma a quanto pare è una
battaglia persa in partenza.
Rimanete pura nella vostra 'colta ignoranza'.
Abbandono il thread e prob. anche il ng, tanto è solo una perdita di tempo
visto che tutte le volte che mi serve qualche informazione riesco a trovarla
da solo o su Internet.
Usenet è per i pigri, IMHO.
Kiuhnm

battaglia persa in partenza.
vedi sopra.
--
Rhymes (rhy...@NOSPAMmyself.com)


 Usenet è per i pigri, IMHO.
Incornicio anche questa ;)


 purtroppo non viene dai libri: c'è chi ce l'ha e chi non ce l'ha.
Non conosco molto la storia degli algoritmi, se qualcuno può passarmi 
degli url interessanti ne sarei grato.
Ad ogni modo dei pochi algoritmi che conosco sono stati tutti inventati 
dai ricercatori. ;)
Maurizio

 Uno era di Schildt se non sbaglio...
ah, questo spiega tante cose...
Maurizio

 Usenet è per i pigri, IMHO.
Usenet non è un posto dove chiedere le cose che non trovi e basta. I 
newsgroup sono nati come GRUPPI DI DISCUSSIONE.
Alle volte il tuo tono di arroganza e presunzione può dar fastidio a chi 
ti legge.
Maurizio

Ragazzi miei.
Ho letto un po' di cose che avete scritto su questo thread.
Ho constatato in alcuni soggetti (non faccio nomi per carita')
una mancanza di
- 1 - rigore scientifico nell'argomentare affermazioni
- 2 - buon senso
- 3 - rispetto per il prossimo
per la prima si invitano i trasgressori a inaugurare un nuovo newsgroup:
it.comp.smanettare
Gli altri 2 sono dovuti all'appertenenza alla specie "Homo Sapiens",
quindi non ci si puo' far nulla.
 ciao
Raffaello

 Qualsiasi programmatore può avere qualcosa da insegnare.
no, non tutti. Knuth e Dijkstra non hanno mai insegnato nulla di 
concreto, poiche` non sono mai stati Veri Hacker!


 A quando "Programmazione - La Guida Completa" di Kiuhnm-Schildt ?
ROTFL!


 battaglia persa in partenza.
Non vedo nessuna dimostrazione formale che confuti la definizione vigente di
ricorsione per cui non ci hai mostrato un bel niente !!!
Dimostrazione !!!!!!! Analizza bene il termine !!!
Ora io farò una dimostrazione che coinvolge le algebre, tu magari farai la
stessa cosa con la ricorsione cosi ci dimostri la confutazione della
definizione di ricorsione, cosa che io non so fare :D!
Diciamo che 1+1 = 3 può fare anche 3 se mi inveto una mia algebra
 che gode di particolari proprietà per cui 1+1=3 ha senso!
 Dicesi algebra una tupla <S,op1, ... ,opn> dove S è un insieme dato, detto
 di Sostegno dell'algebra, e per i=1,..,n
 opi è una funzione da S^ki a S oppure da S^ki a {true,false}.
 Esempi di algebre :
 l'insieme dei numeri naturali N={0,1,2,...} con la somma, cioè <N,+>
 l'insieme dei numeri naturali N={0,1,2,...} con il prodotto, cioè <N,x>
 l'insieme dei numeri naturali con la mia somma:
 <N,mysum>
 DIM:
 op1 mysum op2 <=> (op1 mysum op2)+1
ne segue che:
1+1=3
oppure
 2+2=5
 CVD

  Dicesi algebra una tupla <S,op1, ... ,opn> dove S è un insieme dato, 
   Come passa il tempo: quando l'Algebra l'ho studiata io, le tuple si 
chiamavano ancora "ennuple". ;)
-- 
Alla prossima,
Marco

  CVD
mamma mia mai visto qualcosa di più sballato e sensa senso...
senza offesa eh :-)

 senza offesa eh :-)
Perche' ? il discorso di elevator ha invece senso in matematica.
Un'operazione e' una convenzione.
Se io stabilisco che al simbolo + associo l'operazione di addizione, posso
anche dire che al simbolo @ associo l'operazione di addizione + 1.
In questo caso, nella mia algebra: 1 @ 1 = 3.
Ora, dato che i simboli sono "simboli" e quindi convenzionali, posso
invertire la notazione e assumere che @ identifichi la prima operazione e +
la seconda, per cui ottengo, sempre nella mia algebra, che:
1 @ 1 = 2
e
1 + 1 = 3
Ora vi propongo un giochetto, anche se siamo OT ;)
A = B
quindi
A^2 = AB
quindi
A^2 - B^2 = AB - B^2
quindi
(A+B)(A-B) = B(A-B)
semplifico e ottengo:
A+B = B
Per l'ipotesi iniziale, A = B, quindi supponendo A = 1, B= A, si ha:
1 + 1 = 1
Dov'e' l'inghippo ? :))



Heheheh Già Marco :D! Gli americani che che ne so io le chiamano tuple ma in
effetti è la stessa cosa dire nuple :D!


Eh Eh Eh!!!! Questo giochetto e' vecchio anche se fa sempre effeto.
Quando dividi entrambi i menbri dell' equazione per A-B devi porre A-B != 0
cioe' A != B, il che e' in ovvio contrasto con l'equazione di partenza A=B.
Ciao, Davide :)

 cioe' A != B, il che e' in ovvio contrasto con l'equazione di partenza
A=B.
Acc... ;))
--------------------------------
Inviato via 
http://usenet.libero.it