quale ?

[71104]

Originariamente inviato da Albi89

Non mi permetterei mai
Tra l'altro se non sbaglio l'autore di brainfuck ogni tanto sforna qualche altro linguaggio sullo stesso stile... tipo un linguaggio basato sui taxi e successive fermate

non lo sfottete, quell'uomo è un genio

il BrainFuck è utilissimo per progettare sistemi antipirateria: immaginate un poveraccio di hacker che deve crackare dei dati criptati tramite uno script BrainFuck interpretato just-in-time
ce lo voglio

[shinya]

Originariamente inviato da k0nt3

ma dal punto di vista didattico mi sembrano solo inutili complicazioni (come il fatto di pensare se l'algoritmo è in O(n^n) piuttosto che in O(6).. ma chissenefrega )

Si, se non fai girare i programmi che scrivi, sono inutili complicazioni.
Altrimenti, usare un algoritmo ugualmente semplice ma con un tempo lineare invece di uno con un tempo esponenziale, fa la differenza tra un programma che funziona, e uno che non funziona.
Perchè ripeto, nell'esempio che hai scritto sei stato disonesto.

Hai messo un bel "if (i < 10) ..." e poi hai detto:"Funziona!". Adesso metti "i < 80".
Funziona ancora? Funziona "abbastanza"? Secondo me l'approccio del "chissenefrega, tanto metto i < 10 e parte..." è fare le cose a braccio. E non c'è metodologia che riesca a raddrizzare questa mentalità. A me non piace il TDD, ma il motivo per il quale è richiesto scrivere dei test per tutto non è fine a se stesso. Il motivo è spingere il programmatore a pensare a fondo a quello che sta scrivendo.

[k0nt3]

Originariamente inviato da shinya

Si, se non fai girare i programmi che scrivi, sono inutili complicazioni.
Altrimenti, usare deliberatamente un algoritmo ugualmente semplice ma con un tempo lineare invece di uno con un tempo esponenziale, fa la differenza tra un programma che funziona, e uno che non funziona.
Perchè ripeto, nell'esempio che hai scritto sei stato disonesto.

Hai messo un bel "if (i < 10) ..." e poi hai detto:"Funziona!". Adesso metti "i < 80".
Funziona ancora? Funziona "abbastanza"? Secondo me l'approccio del "chissenefrega, tanto metto i < 10 e parte..." è fare le cose a braccio. E non c'è metodologia che riesca a raddrizzare questa mentalità. A me non piace il TDD, ma il motivo per il quale è richiesto scrivere dei test per tutto non è fine a se stesso. Il motivo è spingere il programmatore a pensare a fondo a quello che sta scrivendo.

ma lo scopo è calcolare il numero più grande che appartiene alla serie di fibonacci o forse per caso è solamente implementare un algoritmo che la calcola?
per me la seconda, quindi il mio programma soddisfa pienamente i vincoli, già sapere i primi 25 numeri della serie è di utilità relativa.. ne bastano anche 10 per capire se l'algoritmo è corretto o no.
il motivo dell'esistenza dei test comunque non è quello di far pensare a quello che si scrive, ma quello di isolare il comportamento di un modulo per poterlo testare, altrimenti dovremmo aspettare che il programma sia completo per poterne testare anche una piccola parte.
questa cosa già si faceva in maniera più scomoda e macchinosa prima del TDD usando dei main fittizzi ecc.. ovviamente in maniera molto meno esasperata. il TDD ha portato all'automatizzazione di questo processo
tornando al nostro discorso... uno che impara a programmare non deve assolutamente pensare all'efficienza dei suoi algoritmi, ma soltanto alla correttezza. per l'efficienza c'è sempre tempo dopo e solo quando serve

[Albi89]

#include <stdio.h>

long long fibonacci(long long i)
{
  if (i < 0) return -1; 
  if (i == 0) return 0;
  else if (i == 1) return 1;
  else return fibonacci(i-1) + fibonacci(i-2);
}

Cioè e poi sono io il napoletanaccio... e "long long" come me lo chiamate?
Comunque no, non dovrebbe essere standard, che compilatore lo supporta? (immagino il Visual C++ ma sono troppo pigro per controllare )

Edit: ok, dovevo pensare prima di parlare: mi correggo, lo supporta anche gcc, codificando su 64 bit

[cdimauro]

Originariamente inviato da k0nt3

scrivere meno righe di codice secondo me significa soltanto una cosa: scrivere meno righe di codice :P
è sbagliato pensare che le soluzioni più corte sono sempre più leggibili (anche se molte volte lo sono tuttavia), c'è un limite inferiore sotto il quale l'informazione è così compressa che risulta difficile risalire al suo significato.
io preferisco scrivere due righe in più quando necessario, non trovo nessun interesse nel far stare tutto in una riga.

Non mi pare che qualcuno qui abbia detto qualcosa di diverso.

Fermo restando il calcolo del numero bug per linea di codice è una metrica abbastanza usata in informatica.

ad esempio l'assegnazione parallela di python (per riprendere un esempio visto in questo thread) è più difficile da capire rispetto all'uso di una variabile temporanea. questo perchè la semantica dell'assegnazione parallela è più complicata di quella dell'assegnazione normale (e qui sfido a dimostrare il contrario).

La dimostrazione te l'avevo già fornita:

Info = DB.Gets('SELECT Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza FROM Utenti WHERE ID = %s', (12345, ))

Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza = Info

Ovviamente Info è una tupla, che viene "spacchettata" grazie all'assegnamento multiplo.

La versione senza assegnamento multiplo sarebbe questa:

Info = DB.Gets('SELECT Nome, Cognome, CodiceFiscale, Residenza, Cittadinanza FROM Utenti WHERE ID = %s', (12345, ))

Nome = Info[0]
Cognome = Info[1]
CodiceFiscale = Info[2]
Residenza = Info[3]
Cittadinanza = Info[4]

poi non c'è dubbio che chi li conosce li ritiene strumenti utilissimi e indispensabili.. ma dal punto di vista didattico mi sembrano solo inutili complicazioni

Lascia decidere a chi deve imparare quale delle due soluzioni di cui sopra è più complicata.

(come il fatto di pensare se l'algoritmo è in O(n^n) piuttosto che in O(6).. ma chissenefrega )

Certo: è noto che un algoritmo superesponenziale e uno lineare sono la stessa cosa.

Originariamente inviato da 71104

anche in C volendo, anche se è necessario l'aiuto del compilatore*

#include <stdio.h>

long long fibonacci(long long i)
{
  if (i < 0) return -1; 
  if (i == 0) return 0;
  else if (i == 1) return 1;
  else return fibonacci(i-1) + fibonacci(i-2);
}

int main(void)
{
  int n;
  printf("Inserire intero >= 0 : ");
  scanf("%d", &n);
  printf("L' %do numero di Fibonacci e' %lld.\n", n, fibonacci(n));
  return 0;
}

*credo che long long non sia standard

Anche se lo fosse (e mi pare che col C99 lo è), non sta scritto da nessuna parte che long long = intero a 64 bit. Come non sta scritto da nessuna parte che int o long debbano essere a 32 bit.

In ogni caso, superati i 64 bit il problema col C si riproporrebbe. Con Python no.

Originariamente inviato da k0nt3

ma lo scopo è calcolare il numero più grande che appartiene alla serie di fibonacci o forse per caso è solamente implementare un algoritmo che la calcola?
per me la seconda, quindi il mio programma soddisfa pienamente i vincoli, già sapere i primi 25 numeri della serie è di utilità relativa.. ne bastano anche 10 per capire se l'algoritmo è corretto o no.

Non è né la prima né la seconda. Il problema era di generare la sequenza di Fibonacci, quindi avere uno stream di dati virtualmente illimitato. Cosa che la tua applicazione NON fa. Quella in Java, invece, risolveva perfettamente il problema.

Io avevo chiesto di tirare fuori l'EQUIVALENTE di un'applicazione di cui avevo fornito il codice in Python.

Tu, come programmatore, non puoi fare di testa tua e assumere cose diverse: sei tenuto COME MINIMO a rispettare i REQUISITI del problema.

Sull'implementazione io non avrò nulla da dire, purché però i requisiti siano rispettati alla lettera. Quindi anche la tua soluzione ricorsiva sarebbe andata bene, seppur estremamente inefficiente, posto che avesse risolto il problema.

tornando al nostro discorso... uno che impara a programmare non deve assolutamente pensare all'efficienza dei suoi algoritmi, ma soltanto alla correttezza. per l'efficienza c'è sempre tempo dopo e solo quando serve

Va benissimo, non c'è problema, ma la condizione NECESSARIA è che almeno i requisiti debbano essere rispettati.

[k0nt3]

quindi? voglio vedere come dimostri che la versione ricorsiva non è corretta.. è la trascrizione 1:1 della definizione di successione di fibonacci praticamente

ps. probabilmente ti è sfuggito il fatto che nessun software può calcolare tutta la successione.. è infinita, mentre la memoria di un PC è finita, quindi tutti gli algoritmi sarebbero sbagliati secondo la tua curiosa interpretazione. ma se la memoria fosse infinita sia la soluzione ricorsiva che quella non ricorsiva riuscirebbero a calcolare tutta la serie

[Albi89]

Originariamente inviato da k0nt3

quindi? voglio vedere come dimostri che la versione ricorsiva non è corretta.. è la trascrizione 1:1 della definizione di successione di fibonacci praticamente

ps. probabilmente ti è sfuggito il fatto che nessun software può calcolare tutta la successione.. è infinita, mentre la memoria di un PC è finita, quindi tutti gli algoritmi sarebbero sbagliati secondo la tua curiosa interpretazione. ma se la memoria fosse infinita sia la soluzione ricorsiva che quella non ricorsiva riuscirebbero a calcolare tutta la serie

Secondo me ti stai un po' "scostando" dal discorso... la questione non era "quale implementazione di fib è più bellina" (e le ultime pagine erano finite così) ma "è meglio iniziare con linguaggi a oggetti? python è un linguaggio a oggetti?".
Il frammento di codice di cdimauro era, perlappunto, un'oggetto su cui poter iterare col for "foreachoso" di python e che mantenesse nota dell'ultimo valore stampato; nella mia vita non credo che mi troverò mai a iterare su fib, ma è un esempio che si può adattare a qualunque sequenza virtualmente infinita di numeri.
Le altre (a parte quella di shinya) non solo sono semplici funzioni, ma non assolvono allo scopo iniziale.

(come il fatto di pensare se l'algoritmo è in O(n^n) piuttosto che in O(6).. ma chissenefrega )

Penso che sia uno scherzo... penso che se ci fosse la possibilità di rendere tutti gli algoritmi "O(6)" cioè COSTANTI, neanche lineari, i nostri pc sarebbero scheggiozze

[cdimauro]

Originariamente inviato da k0nt3

quindi? voglio vedere come dimostri che la versione ricorsiva non è corretta.. è la trascrizione 1:1 della definizione di successione di fibonacci praticamente

Qui o non hai capito il problema o stai cercando di cambiare discorso.

La versione che hai fornito NON è corretta perché NON è in grado di generare una sequenza virtualmente illimitata di numeri della successione di Fibonacci.

ps. probabilmente ti è sfuggito il fatto che nessun software può calcolare tutta la successione.. è infinita, mentre la memoria di un PC è finita, quindi tutti gli algoritmi sarebbero sbagliati secondo la tua curiosa interpretazione. ma se la memoria fosse infinita sia la soluzione ricorsiva che quella non ricorsiva riuscirebbero a calcolare tutta la serie

Nessuno ha mai detto questo. Infatti ho scritto "VIRTUALMENTE illimitata" proprio per questo motivo.

Il concetto è che tu, intanto, mi devi garantire di generare numeri fino a quando io lo riterrò opportuno. Questo significa che potenzialmente potrei anche arrivare a occupare tutta la memoria del PC e mandarlo in crash, ma non me ne frega niente: intanto genera i numeri e non ti fermare.

Esempio pratico:

for n in fib(): print n

Questa continua a generare numeri fino a quando non decido di premere Ctrl-C o di chiudere l'applicazione. Non c'è nessun limite fissato A PRIORI.

[k0nt3]

Originariamente inviato da cdimauro

Esempio pratico:

for n in fib(): print n

Questa continua a generare numeri fino a quando non decido di premere Ctrl-C o di chiudere l'applicazione. Non c'è nessun limite fissato A PRIORI.

dubito fortemente che questo programma possa generare tutta la serie di fibonacci. anche in questo caso finisce la memoria prima o poi (se non altro perchè il numero n è monotono crescente, quindi i bit occupati crescono in continuazione).
quindi a livello concettuale non c'è nessuna differenza: entrambi gli algoritmi generano tutta la successione solo se la memoria disponibile è illimitata.
l'unica differenza è che quello ricorsivo si ferma prima mentre quello iterativo dopo

[cdimauro]

[Albi89]

Originariamente inviato da k0nt3

dubito fortemente che questo programma possa generare tutta la serie di fibonacci. anche in questo caso finisce la memoria prima o poi (se non altro perchè il numero n è monotono crescente, quindi i bit occupati crescono in continuazione).
quindi a livello concettuale non c'è nessuna differenza: entrambi gli algoritmi generano tutta la successione solo se la memoria disponibile è illimitata.
l'unica differenza è che quello ricorsivo si ferma prima mentre quello iterativo dopo

No concettualmente c'è una differenza molto più forte.
Il for del python è in pratica un for each, itera sugli elementi che sono contenuti nell'oggetto fib.
Dunque fib concettualmente "contiene" tutti gli elementi della successione di fibonacci, così come lo potrebbe fare un array infinito che contenga tutta la successione.
Quando usi la tua funzione fib invece gli dai un limite superiore e lui calcola fin lì, si ferma e ti restituisce il valore.

Edit: in ogni caso propongo di cambiare argomento... so dai tanti altri tuoi post che sei competente ed esperto, quindi non credo proprio che tu davvero non colga la differenza... penso semplicemente che vuoi farci uscire pazzi ripetendo le stesse cose fib(50) volte

[k0nt3]

Originariamente inviato da Albi89

No concettualmente c'è una differenza molto più forte.
Il for del python è in pratica un for each, itera sugli elementi che sono contenuti nell'oggetto fib.
Dunque fib concettualmente "contiene" tutti gli elementi della successione di fibonacci, così come lo potrebbe fare un array infinito che contenga tutta la successione.

concettualmente anche la soluzione ricorsiva genera tutta la successione, ma in pratica non è possibile per nessun algoritmo

[k0nt3]

Originariamente inviato da Albi89

Secondo me ti stai un po' "scostando" dal discorso... la questione non era "quale implementazione di fib è più bellina" (e le ultime pagine erano finite così) ma "è meglio iniziare con linguaggi a oggetti? python è un linguaggio a oggetti?".

no sto cercando di dire che chi inizia a programmare se ne deve fregare dell'efficienza degli algoritmi, è molto più importante creare algoritmi corretti. per l'efficienza c'è tutta una letteratura che uno si può studiare in un momento successivo senza problemi.
ma veniamo al dunque:

è meglio iniziare con un linguaggio a oggetti?
dipende

python è un linguaggio a oggetti?
certamente, ma è anche procedurale e funzionale

[cdimauro]

E' inutile: con te è una causa persa in partenza.

Ti ho fatto vedere come funziona Python, e torni nuovamente sul solito discorso dei paradigmi.

Ti ho fatto vedere quali erano i REQUISITI della generazione dei numeri di Fibonacci e, da "buon" informatico, li hai puntualmente disattesi cercando di spostare la discussione verso altri lidi.

Vuoi sempre cadere in piedi anche sei hai torto marcio. Per fortuna scripta manent, come dicevano gli antichi latini: gli altri utenti possono verificare come sono andate le cose.

[k0nt3]

i "requisiti" sarebbero generare "tutta" la successione di fibonacci? no perchè se è così non mi sforzo nemmeno di pensare un algoritmo visto che sarebbe una fatica inutile

[cdimauro]

I requisiti li trovi nell'ultima parte di questo messaggio: http://www.hwupgrade.it/forum/showpo...6&postcount=92

[k0nt3]

penso che sia abbastanza inutile (anche difficile e sostanzialmente OT) cercare di fare un programma "perfettamente" equivalente a quello in java, ogni linguaggio ha le sue caratteristiche

[cdimauro]

Le tue opinioni non contano: i requisiti sono quelli, e li devi rispettare.

L'implementazione ovviamente è libera.

La soluzione di shinya risponde PERFETTAMENTE ai requisiti. La tua NO, e non venirmi a dire che in C non si potrebbe fare.

[k0nt3]

ah beh allora facciamo che anche le tue opinioni non contano e la discussione finisce qui
se vuoi puoi aprire un forum dove ci sei solo te

[cdimauro]