Newsgroup: it.hobby.lotto
Titolo: per tutti in che linguaggio programmate?

A tutti coloro che hanno fatto un programma per il lotto...che
linguaggio di programmazione usate?
ho in mente un prog per Totoscommesse, ma di programmazione ne so
pochino, voi con che cosa avete iniziato?
che consigli mi date?
Ciao
Marco
--
Visitate il mio sito sul totoscommesse!!!
http://members.it.tripod.de/betman/index.html


avevo già visto il tuo sito ed è sicuramente un bel sito, però mi sembra che
quei sistemini 8 colonne, 6 colonne + fissa, ecc, siano un pò troppo
decantati. Insomma non mi sembra ci sia nulla di speciale nello sviluppare
3,4 doppie con una fissa e qualche condizione.
Molto interessante invece era il confronto fra EuroBet e Snai. Anche se
credo che le diversità di premio per alcune partite siano sempre compensate.
Mi spiego: se cercano di attirarti verso una partita con un premio
apparentemente più conveniente del solito probabilmente ci saranno altre due
o tre partite su cui giocherà una buona percentuale di scommettitori con il
risultato che quelle più semplici si rivelano le più ardue.

che consigli mi date?
Ogni linguaggio ha i suoi pro e i suoi contro... Visual Basic è molto
facile da imparare ed usare, ma non è certo un fulmine in elaborazione
e in più qualsiasi lavoro tu faccia (anche uno piccolo) ti farà uscire
un "malloppo" da distribuire grosso diversi Mega
Delphi è più veloce, fa eseguibili più piccoli, ma è un po' più
difficile da apprendere
Il C++ (ti sconsiglio il Visual/C, è meglio il Borland) è MOLTO
veloce, ma anche MOLTO complesso
Il mio consiglio è di farti le ossa con un linguaggio, cominciando a
fare dei piccoli programmini per entrare nel "meccanismo" di
progettazione e sviluppo, per poi passare gradualmente ad applicazioni
via via più complesse
Wolf IMHO
"Lo stress è quell'apostrofo grigio tra le parole...M'INCAZZO"
[Remove numbers for correct e-mail address]
"Tariffe a tempo sviluppano pensieri a breve termine"
(Nicholas Negroponte contro la TUT)
Visitate e supportate: --> 
www.notut.org
 <---

totoscommesse e uno di questi dovrebbe essere il fabiani.
Grassie, grassie.
Marco

 writes:
Mb> 
Mb> ho in mente un prog per Totoscommesse, ma di programmazione ne so
Mb> pochino, voi con che cosa avete iniziato?
dovendo iniziare a programmare, io ti consiglio Java, per questo e
quell'altro motivo :-)
E' semplice, ma ha librerie molto complete che, volendo e studiandoci,
ti  permettono di  fare  moltissimo. Trovi  parecchio materiale  anche
grauito in rete (ad esempio  "thinking in Java" di Bruce Eckel, presso
www.bruceeckel.com
, credo: io me lo sono stampato e merita davvero).
Tutto il pacchetto di  sviluppo (JDK1.2) è gratuito (
www.javasoft.com
,
ma lo trovi sui cd divarie riviste) e quindi...
Mb> che consigli mi date?
di lasciar perdere completamente la grafica.
Fai  solo e soltanto  programma a  riga di  comando: ti  permetterà di
concentrarti sulle funzionalità  vere del tuo programma, sull'imparare
a  programmare,  senza  perderti   nei  mille  dettagli  di  finestre,
eventi...
cmq, fatti un giro su it.comp.java se vuoi sapere altro.
Ciao
Marco
-- 
Legge di Lewis:
	Per quanto uno cerchi e si informi prima di comprare un qualsiasi
	articolo, lo trovera' a minor prezzo da un'altra parte non appena
	l'avra' acquistato.

quell'altro motivo :-)
giusto consiglio
quando si comincia non ci si deve far abbagliare dalle comodità di oggi. Io
quando iniziai dovevo studiare il modo di non sfondare i 64k, yeahhhhh
ciao
Davide

totoscommesse e uno di questi dovrebbe essere il fabiani.
Ah ,  ecco , non potresti trovare un accordo pure con me? Io non ho
bisogno di un programma, ho già scritto in VB un programma per
Totocalcio, che sto continuando ad elaborare, tuttavia, è un pochino
lento, se si tratta di elaborare 13 triple. Avrei solo bisogno di una
routine in C che riproduca la mia routine di calcolo. Ciò dovrebbe
aumentare la velocità, immagino.
Si tratta solo di una serie di 13 cicli For-Next nidificati con in
mezzo poche righe per fare la selezione delle colonne. 
Volendo poi ci sarebbe anche una quarantina di righe (di righe brevi!)
che, da colonne già in memoria, ne calcola la probabilità di fare 12 e
compie un'ulteriore selezione. Ma questo è secondario.
Ciao.
Massimo




 che consigli mi date?
Lascia perdere i linguaggi come il C++ / C / Java che sono troppo complessi
per un primo approccio alla programmazione... ti consiglierei il Visual
Basic anche se poi ti consiglio di abbandonarlo il prima possibile dato che
non permette una programmazione a oggetti! quindi solo per semplici
programmi che non richiedano elevate prestazioni!
Ciao
--
Alessandro Pulvirenti
ale...@cedss.it
Sito Lottovelox: 
http://www.cedss.it/lottovelox/

programmi che non richiedano elevate prestazioni!
se sicuro che il VB non permetta la programmazione ad oggetti ?
ciao
Davide

che consigli mi date?
Se di programmazione ne sai poco, ti consiglio il Visual Basic che è più
immediato per cominciare a costruire applicazioni. Tutto sommato non è da
buttare e la versione 6 ora compila in codice nativo per cui anche le
prestazioni sono accettabili. Certo sarebbe meglio il C++ ma partire da zero
con questo linguaggio è un'impresa e i tempi di apprendimento sono piuttosto
lunghi. Se proprio ti interessa il C++ ti consiglio il pacchetto Borland che
offre degli strumenti che facilitano un pò la programmazione. Se vuoi della
documentazione sulla programmazione, chiedi in libreria i volumi McGraw-Hill
che mi sembrano molto completi e chiari.
Ciao, Stefano

 writes:
m> 
m> lento, se si tratta di elaborare 13 triple. Avrei solo bisogno di una
m> routine in C che riproduca la mia routine di calcolo. Ciò dovrebbe
m> aumentare la velocità, immagino.
e di molto se la codifica delle colonne è buona
----------------------------------------------------------------
template<class Function>
integrale(Function& s, TCol& pronostico){
  TCol col(X12,TIPO); 
  int i[]={0,0,0,0,0,0,0,0,0,0,0,0,0}; 
  int j=0; 
  vector<short> pro[TIPO]; 
  for(int k=0; k<TIPO; k++){
    if(pronostico.get_pos(k)&1) pro[k].push_back(1);
    if(pronostico.get_pos(k)&4) pro[k].push_back(4);
    if(pronostico.get_pos(k)&2) pro[k].push_back(2);
  };
  for(i[0]=0; i[0] < (pro[0]).size(); ++i[0])
   for(i[1]=0; i[1] < (pro[1]).size(); ++i[1])
    for(i[2]=0; i[2] < (pro[2]).size(); ++i[2])
     for(i[3]=0; i[3] < (pro[3]).size(); ++i[3])
      for(i[4]=0; i[4] < (pro[4]).size(); ++i[4])
       for(i[5]=0; i[5] < (pro[5]).size(); ++i[5])
        for(i[6]=0; i[6] < (pro[6]).size(); ++i[6])
         for(i[7]=0; i[7] < (pro[7]).size(); ++i[7])
          for(i[8]=0; i[8] < (pro[8]).size(); ++i[8])
           for(i[9]=0; i[9] < (pro[9]).size(); ++i[9])
            for(i[10]=0; i[10] < (pro[10]).size(); ++i[10])
             for(i[11]=0; i[11] < (pro[11]).size(); ++i[11])
              for(i[12]=0; i[12] < (pro[12]).size(); ++i[12])
              { 
                col.clear();
                for(j=0; j< TIPO; ++j)
                  col.set_pos(j,(pro[j])[i[j]]); 
                s(col);
              }; 
}; 
-----------------------------------------------------------------
Non è  esattamente un  bell'esempio di programmazione  C++ se  non sai
molto  di  questo  linguaggio,  ma  funziona ed  ha  anche  una  certa
eleganza...
Ciao
Marco
-- 
Al manicomio: "Mi scusi, sa dirmi dove si trova il prof. Von Schutz?".
"Ma e' lei il prof. Schutz!".  "Appunto, dove mi trovo?".


dai Marco, se quella roba è elegante allora il C è da buttare alle ortiche.
In casi del genere la soluzione ottimale è una funzione ricorsiva che cioè
richiama se stessa. Con 7,8 righe hai risolto il problema. Di problemi ne
potrebbero sorgere altri, come ad esempio con lo stack, ma trattandosi di
1,5 milioni di colonne ed una profondità di 13 elementi fila tutto liscio.
ciao
Davide

1,5 milioni di colonne ed una profondità di 13 elementi fila tutto liscio.
In casi del genere la soluzione ottimale e' invece quella iterativa.
Gia' 1.5 milioni di colonne sono tanti, se ti metti pure a pushare e poppare
dallo stack ci stai mezza giornata.
Marco
PS: io pero' faccio sempre cosi':
    for (c[0] = 0; c[0] < 3; c[0]++)
       if (prono[0][c[0]])
           for (c[1] = 0; ecc. ecc.
mi sa che risulta leggermente piu' veloce (ma di poco).
Nel caso peggiore ho tredici confronti con un accesso a c[] ciascuno, nella
soluzione di Marco (trasposizione dei segni) ho 13 riferimenti a pro.size
(che costano come l'accesso a c[]) nei cicli, e poi l'overhead della
trasposizione con, di nuovo, 13 accessi a pro.
Almeno credo.

eleganza...
Eh, purtroppo io di C++ non ne so proprio nulla, quindi non credo di
poter apprezzare molto quanto hai scritto. :-)
Ciao.
Massimo

mi sa che risulta leggermente piu' veloce (ma di poco).
Mannaggia..magari potessi capirci qualcosa...:-)
Massimo

dallo stack ci stai mezza giornata.
mezza giornata ??
oè dico.... che processore hai un 86 ?
con un pentium2 300 lo sviluppo integrale delle 49 milioni di cinquine del
lotto comporta un'attesa inferiore ai 2 secondi.
ciao
Davide
NB
che si chiede che fine abbia fatto lo standard SCH dopo anni e anni che non
smanetta più con i segni 1x2

smanetta più con i segni 1x2
Come standard ha resistito solo l'NTP ...124124...
Ha proposito sia Fabiani che Pozzato hanno votato per il NG sul
totocalcio che per l'ennesima volta non è stato approvato....ahi
ahi....poveri noi ...

 wrote in message 7tqnft$1b1$1...@nslave1.tin.it...

Si!
Per chiamarsi programmazione a oggetti, bisogna soddisfare alcuni requisiti
e il VB ne soddisfa solo una parte!
per esempio: non è possibile l'Ereditarietà cosa necessaria nella
programmazione a oggetti.


Ciao
l'ereditarietà porta al polimorfismo e in VB si arriva al polimorfismo
tramite le interfacce activex.  Si tratta di una scelta logistica che
facilita la programmazione. In più con le interfacce sei facilitato
dall'associazione anticipata così da sapere subito se questo o quel metodo
sono supportati.
ciao
Davide

lotto comporta un'attesa inferiore ai 2 secondi.
Comunque la soluzione iterativa e' piu' veloce.
Ad esempio questa (con DJGPP, O3):
void    main(void)
{
int     count;
int     v[5];
        count = 0;
        for (v[0] = 0; v[0] < 86; v[0]++)
          for (v[1] = v[0] + 1; v[1] < 87; v[1]++)
            for (v[2] = v[1] + 1; v[2] < 88; v[2]++)
              for (v[3] = v[2] + 1; v[3] < 89; v[3]++)
                for (v[4] = v[3] + 1; v[4] < 90; v[4]++)
                  count++;
        printf("count = %d\n", count);
}
ci mette 0.8 secondi sul PII 400.
Marco
PS le cinquine sono  43949268.

 wrote in message
7tvdvd$r9t$1...@nslave1.tin.it...



le hai contate una per una  ?
:-)) eheheh

long)
Dipende dal compilatore che usi. Su alcuni int e' a 16 bit, su altri a 32
bit.
Marco

non č elegante, ma č uguale
Non direi. E' semplice, elegante e veloce.
Sempreche, naturalmente, tu non posti del codice PIU' veloce.
Marco

 writes:
m> 
m> Spero di sě, che l'aumenti di molto, cioč. Ora io, con i miei cicli in
m> Vb, con un Pentium 150, arrivo ad elaborare 7000 colonne al secondo,
cioč oltre 21000 cicli di clock per colonna
m> č accettabile, considerando anche che si tratta di
m> calcoli probabilistici, per cui per ogni colonna deve fare diverse
m> moltiplicazioni.
m> 
il mio programma in C++  che fa _molti_ calcoli di tipo probabilistico
e  non č  ottimizzato impiega  3170 cicli  di clock  a colonna  (le 13
triple in 25 secondi).
Giusto a titolo di esempio, inserendo  5 quadri in link, con 5 colonne
filtro l'uno piů una condizione sulla fascia di vincita, impiega 15230
cicli per combinazione.
Ciao
Marco
-- 
Borsa:
	Oggi borsa in tilt a Milano.  Tutto fermo.  A piazza Affari
annullata la seduta per un guasto ai computer.  Gia' da domani, pero',
gli operatori potranno ricominciare a giocare a Tetris.
		-- Panfilo Maria Lippi, "TABLOID TABLOID"@"Mai Dire Gol"

 writes:
DG> 
DG> dai Marco, se quella roba è elegante allora il C è da buttare alle ortiche.
ok, sono stato troppo sintetico, forse peggio del codice che scrivo :-)
Il  codice della  funzione è  tutt'altro che  ottimizzato per  dare il
meglio del  C++ (perchè  era C++,  non C) perchè,  secondo me,  con la
potenza  di  calcolo  e  il   ritmo  con  cui  si  incrementa,  è  più
intelligente sviluppare codice  riusabile e ben organizzato, piuttosto
che perdere tempo ad ottimizzarlo, entro certi limiti, ovviamente.
L'unica  ottimizzazione seria,  è stata  la struttura  dati  usata per
memorizzare  le combinazioni:  usando  un array  di  bit si  ottengono
prestazioni da  paura rispetto ad un  vettore di interi,  specie se si
abbina  il tutto  ad una  tabella  di look-up  per fare  i test  sulle
combinazioni.
Comunque, tornando  a quel pezzo di  software, deriva da  un mio ormai
_vecchio_ progetto iniziato 3 anni  fa: inizialmente erano 40 righe di
codice, ora sono più di mille (tutto calcolo, niente interfaccia): via
via ho aggiunto pezzi,  feature, ho sviluppato la versione totocalcio,
totogol, lotto,  superenalotto... il programma  non mi è  scoppiato in
mano ed anzi si è evoluto splendidamente, senza mai buttare niente. Lo
sviluppo delle versioni degli  altri giochi è stato pressochè indolore
ed  ha  richiesto poco  tempo,  tutto questo  grazie  ad  un misto  di
programmazione ad oggetti  e generica. Ed è qui  che entra il discorso
sull'eleganza di quel codice, non sul codice in sè, ma sulla signature
della funzione.
Quella funzione prende 2 parametri:
- uno di tipo TCol, cioè  una classe che memorizza delle combinazioni,
  singole o integrali, e quindi anche un pronhostico
- una classe  _generica_ che fornisca  l'operatore (). Semamticamente,
  applicando l'operatore si ottiene  un booleano che dice se accettare
  o meno la colonna fornitagli come parametro.
Il vantaggio di tutta questa  apparente complicazione è qui: quale che
sia  il gioco  (totocalcio, lotto)  mi basta  definire una  class TCol
appropriata  e una funzione  integral che  sviluppi il  suo integrale.
Tutto il resto  del programma resta immutato, non  devo scrivere altre
righe di codice. Questo è _molto_ elegante e comodo direi, non credi?
Il codice in sè che sviluppa l'integrale fa schifo, questo lo so anche
io, ma mi interessava scriverlo  in fretta, senza perdere troppo tempo
a  ottimizzare e/o  debuggare. Io  ho  inziato quel  progetto sul  mio
vecchio 486  dx2 66MHz, il  semplice passaggio al mio  attuale Pantium
200 ha  'ottimizzato' l'esecuzione  in maniera impressionante...  e si
tratta pur sempre di hardware vecchio di anni...
Chissà  su un  PentiumIII, o  magari su  un  multiprocessore... potrei
elaborare 2  colonne in parallelo,  con solo modificando il  corpo del
ciclo for più interno alla funzione integral...
DG> In casi del genere la soluzione ottimale è una funzione ricorsiva
DG> che cioè richiama se stessa. Con 7,8 righe hai risolto il
DG> problema. 
Assolutamente no!
Come ha  già spiegato anche Marco  Fabiani, la ricorsione  è sempre la
soluzione  peggiore: la  scrivi in  3 secondi,  ma è  di  una lentezza
esasperante. Vista la mole di dati è da scartare in partenza.
Ciao
Marco
-- 
Gara di corsa nel manicomio.  Uno dei concorrenti: "Mi conviene arrivare
primo o terzo".  Un altro concorrente: "Perche'?".  "Mi hanno detto che
l'arbitro ha un cronometro che spacca il secondo!".
		-- Da it.hobby.umorismo

 writes:
DG> 
DG> con un pentium2 300 lo sviluppo integrale delle 49 milioni di cinquine del
DG> lotto comporta un'attesa inferiore ai 2 secondi.
DG> 
bhe, Davide, ma qui non  si parlava _SOLO_ di generare l'integrale, ma
di farci anche delle operazioni  sopra. Anzi, a voler guardare bene, i
tuoi 2 secondi sono addirittura troppi :-)
Tu usi 8 cicli di clock per una colonna, in C arrivo a meno di 4...
DG> che si chiede che fine abbia fatto lo standard SCH dopo anni e anni che non
DG> smanetta più con i segni 1x2
l'SCH è vivo e vegeto, ma usato solo nei prodotti Happysoft.
NTP ha il pregio di essere un  file di testo, quindi nel caso di poche
colonne da importare,  ad esempio, puoi scriverle a  mano... anche chi
non  abbia conoscenze appronfondite  di programmazione  è in  grado di
farsi il suo  programmillo per usare file NTP,  mentre diventa già più
complicato usare SCH.
Tra l'altro ancora  non mi spiego in cosa  consista il vantaggio dello
standard  SCH...  dimezzava lo spazio  su  disco,  ma  poi? 
Non  credo  che  in   programmi  commerciali  esistesse  qualcuno  che
rappresentava le  colonne in memoria  come vettori di  interi, anzichè
come vettori di bit...
Ciao
Marco
-- 
"Tutta la letteratura moderna americana deriva da un unico libro di Mark
Twain chiamato Huckleberry Finn."
		-- Ernest Hemingway

cicli per combinazione.
Grazie per le informazioni, non so quando mi deciderò ad impare il
C(++) anch'io. Allora, come pensavo, anche tu sei interessato al
totocalcio. Per quanto riguarda il NG niente ancora eh? Mi sembra sia
la terza volta che viene bocciato...:-( 

 ciclo for più interno alla funzione integral...
non vi siete mai chiesti se è possibile sviluppare dei sistemi integrali
senza fare dei cicli nidificati?
pensateci bene... perchè è possibile... e dà molti vantaggi!


> Comunque la soluzione iterativa e' piu' veloce.
DG> comunque ho stimato male l'attesa... altro che 2 secondi, saranno 2 decimi
DG> di secondo. 
stento a crederlo!?!?!?
sei proprio sicuro?
o forse il tuo 'cronometro' non funziona bene....
2  decimi  di   secondo  significa  1.36  cicli  di   clock  per  ogni
combinazione....  mi  sembra  veramente  TROPPO poco  per  essere  una
semplice ottimizzazione...
Ciao
marco
-- 
Vincere non e' sufficiente.  Tutti gli altri devono perdere.
		-- Gore Vidal

 writes:
MF> 
MF> ci mette 0.8 secondi sul PII 400.
MF> 
per  quanto  riguarda  il  'benchmarking'  credo  che  sarebbe  meglio
riferirsi, non ai tempi, bensì  al numero ci cicli di clock inpiegati,
per avere un'idea significativa, usando la formula:
nc = fc x T / op
dove:
nc = nuemro di cicli/operazione
fc = frequenza di clock in Hz
T  = tempo di esecuzione (modo utente+modo sistema)
op = numero di  operazioni elementari eseguite  (nel nostro  caso, il
      nuemro ero di combinazioni)
Quindi, il tuo codice usa 400'000'000*0.8/43'949'268 = 7.28 cicli/op
Lo stesso identico codice, compilato col gcc (di cui il djgpp dovrebbe
essere il porting per dos)  usa 5.78 cicli/op, mentre non inserendo il
count nel ciclo for più interno, ottengo 3.73 cicli/op
Il  tutto con  un  Pentium 200,  quindi  un'architettura peggiore  dei
vostri  PII...  quindi  questo  test  non vale  una  cicca,  oppure  i
compilatori in un esempio così  banale non sfruttano il meglio del PII
:-)
Ciao
marco
-- 
I veri geni non dicono di esserlo...  io ad esempio sono un vero genio.

 writes:
MF> 
MF> Piu' o meno ci siamo.
MF> 0.8 col p400 credo siano equivalenti a 3 col p100.
penso di no.
Il tuo codice impiega 1.27 sul mio Pentium 200 (non pII), anzichč 1.6.
Forse perň  sarebbe meglio  testare il tutto  su piů  combinazioni. Ad
esempio, passando all'enalotto (aggiungo il 6 contatore al tuo codice)
impiego   18.32  secondi  per   sviluppare  le   622'614'630  sestine,
mantenendo una media di 5.88 cicli/op
MF> Dipende dal compilatore che usi. Su alcuni int e' a 16 bit, su altri a 32
MF> bit.
credo che _tutti_ i compilatori a 32 bit usino i 32 bit per gli int e
64 per i long
Ciao
Marco
-- 
Telefono cellulare: il telefono dei microrganismi.
		-- Da it.hobby.umorismo

Ok, vado a vedere l'asm generato e conto le operazioni.
Marco

64 per i long
Si, ma era evidente che lui non usasse un compilatore a 32 bit.
Per quello che so, su Watcom, VC++, DJGPP il long e' comunque a 32 bit.
Marco

esasperante. Vista la mole di dati è da scartare in partenza.
Mi crolla il mito della programmazione ricorsiva! :(((
Però consentimi di dubitarne... :) ovviamente dubbio da profano: posso
dimostrare che la ricorsione è la soluzione peggiore?
Ciao Marcuzzoooooo!!! :))
MagoPeppe
"Il buon giorno si vede solo a sera". (Stefano Cassiani)
"Solitamente, quando qualcosa ti apre gli occhi,
prima ti ha già aperto il culo". (Giuseppe Liuzzo)
"Quando gli manca la Dama il Cavaliere si da' al maneggio". (Ignoto)
Staff Tecnico MPO & NuovaCornucopia
http://dreamlink.net/magopeppe
ICQ 9759626
Togli levaccà per contattarmi via email.

 writes:
AP> 
AP> non vi siete mai chiesti se è possibile sviluppare dei sistemi integrali
AP> senza fare dei cicli nidificati?
sì:   penso  che   codificando  opportunamente   le   combinazioni  la
generazione dell'integrale  si può  ridurre ad un  semplice conteggio,
solo che il vantaggio iniziale si perde nella conversione contatore ->
combinazione. 
Se era questo che intendevi...
Ciao
Marco
-- 
Ebbene, si', confesso: sono socialista.  E lo ammetto: Bettino qualche
volta ha delle idee giuste.  Specie se non sono le sue.
		-- Beppe Grillo

su richiesta vi mando il progr (1 k), dove c'è anche un progress bar.
Provate a pensare senza progress bar.
saluti

su richiesta vi mando il progr (1 k), dove c'è anche un progress bar.
Dov'e'?
Marco

 dimostrare che la ricorsione è la soluzione peggiore?
La ricorsione è un modo molto semplice ed elegante per risolvere problemi
ricorsivi... ma in genere, specialmente nelle elaborazioni in cui ogni ciclo
richiede pochi cicli di clock (scusate il giro di parole), hanno prestazioni
pessime.
La ricorsione conviene utilizzarla quando ogni ciclo che viene fatto,
richiede molte operazioni complesse.
Ciao
P.S. c'è differenza tra un programmatore professionista e un programmatore
dilettante... il primo si fa pagare molto di più del secondo! :-)))


>>>>> "MP" == MagoPeppe  <sydlevacc> writes:
MP> 
MP> Dunque Marcuzzo, ho sempre sentito parlare di tabella di look-up: in
MP> che consiste?
Una tabella in cui cerchi il risultato precalcolato.
come fai a calcolare il risultato di 7 x 5 ?
sommi 5 volte il 7?
certamente no,  hai imparato le tabelline  e sai che 7x5  fa 35, senza
calcolarlo ogni volta. In questo modo puoi fare le moltiplicazioni più
velocemente. 
MP> Beh credo che contribuisca anche il fatto di sminuzzare il problema in
MP> tanti piccoli elementi (approccio top-down, se non ricordo male) e
MP> alla conseguente costituzione di funzioni che si incaricano di compiti
MP> semplici (e quindi molto riutilizzabili), correggimi se sbaglio...
credo di sì :-)
MP> Mi crolla il mito della programmazione ricorsiva! :(((
è elegante dal punto di vista concettuale, ma è inefficiente
MP> Però consentimi di dubitarne... :) 
NO ;-)
MP> ovviamente dubbio da profano: posso
MP> dimostrare che la ricorsione è la soluzione peggiore?
MP> 
dipende dal criterio di 'peggiore'
In certi casi, con la ricorsione descrivi in poche righe e in modo del
tutto naturale algoritmi complessi: questo è _bene_
Ogni invocazione  di una  procedura richede cicli  di clock  e memoria
aggiuntiva  (oltre  a  quella  richiesta dal  codice  della  procedura
stessa),  cioè una richiesta  di risorse  (tempo e  memoria) superiore
alla soluzione  iterativa. Questo può  diventare critico se  hai molte
chiamate alla  funzione (e intanto il  tempo se ne  vaaaa... come dice
Adriano! mondo  cano!) in totale o  innestate (lo spreco  di memoria è
dato dalla profondità della ricorsione).
Se non  ti interessa aspettare e  usare memoria... la  ricorsione è la
soluzione migliore.
Ciao
Marco
-- 
In caserma un sergente interroga una recluta: "Soldato, cosa vedi la'?".
"Un militare, signore".  "Un militare?  Ma sei cieco?  Quelli sono due
carri armati!".  "Appunto, signore!  Ogni carro armato e' un mezzo
militare, quindi...".
		-- Da it.hobby.umorismo

dilettante... il primo si fa pagare molto di più del secondo! :-)))
Io sono un programmatore dilettante ignorante e per giunta shareware!
;)
Ciao e Grazie Alex!
MagoPeppe
"Il buon giorno si vede solo a sera". (Stefano Cassiani)
"Solitamente, quando qualcosa ti apre gli occhi,
prima ti ha già aperto il culo". (Giuseppe Liuzzo)
"Quando gli manca la Dama il Cavaliere si da' al maneggio". (Ignoto)
"Nessuna nuova, buona nuova... 
Due palle come due uova, ma buona nuova". (Giuseppe Liuzzo)



mole di dati ??? oè ma tu come lo svilupperesti un integrale con una
ricorsiva ?
la mole di dati si misura sulla profondità della funzione, cioè 10 volte per
una decina, 9 volte per una novina. Considerando che la maggior parte degli
sviluppi viene chiesto in terzine, quartine, cinquine, mi sembra che non sia
tanto esasperante come la vedi tu.
ciao
Davide

 writes:
AP> 
AP> non vi siete mai chiesti se è possibile sviluppare dei sistemi integrali
AP> senza fare dei cicli nidificati?
sì, si  potrebbe utilizzare la biunivocità tra  la combinazioni (poste
in  ordine crescente)  e  il loro  numero  d'ordine. A  quel punto  la
generazione dell'integrale si riduce  ad una semplice incremento di un
numero, ma pesa la conversione.
Se era a questo che ti riferivi...
AP> pensateci bene... perchè è possibile... e dà molti vantaggi!
come tutte  le soluzioni, ha  vantaggi e svantaggi, dipende  da quello
che ci devi fare.
Ciao
Marco
-- 
Se non riesci a fare la buona, stai attenta.  Se non riesci a stare
attenta, dammi un colpo di telefono.

 writes:
DG> 
DG> mole di dati ??? oè ma tu come lo svilupperesti un integrale con una
DG> ricorsiva ?
con un linguaggio di programmazione? :-)
DG> la mole di dati si misura sulla profondità della funzione, 
magari fosse solo questo...
DG> una decina, 9 volte per una novina. Considerando che la maggior parte degli
DG> sviluppi viene chiesto in terzine, quartine, cinquine, mi sembra che non sia
DG> tanto esasperante come la vedi tu.
e ti sembra male...
La profondità della ricorsione (per  cinquine è 5, ad esempio) impatta
direttamente  sulle richieste  di  memoria (5  istanze della  funzione
sullo stack, quindi  tutto sommato poco da questo  punto di vista), ma
impatta  più pesantemente sui  tempi di  esecuzione in  funzione della
quantità di combinazioni da generare.
Già in un altro messaggio ho mostrato come il codice C utilizzava meno
di  6  cicli  di  clock  per generare  una  cinquina  con  l'algoritmo
iterativo, ma con quello ricorsivo?
Prova  a  scrivere  il codice  e  poi  sappimi  dire quanti  cicli  ti
occorrono per  sviluppare una cinquina. Infine  moltiplia l'eccesso di
cicli di clock per 44 milioni di combinazioni.
Ciao
Marco
-- 
Caro Mike, mi sembra ieri che abbiamo cominciato...
		-- Piero Chiambretti a Mike Bongiorno, in apertura della
		   *seconda* serata del Festival di San Remo 1997

>>>>> "MP" == MagoPeppe  <sydlevacc> writes:
MP> 
MP> Qui urge un esempio... A parte il calcolo dei fattoriali, in cosa
MP> possiamo impiegare la programmazione ricorsiva? (esempi per me, comune
MP> mortale e ignorante), grazie! :)
MP> 
Ha già  risposto Alessandro Pulivirenti,  ma voglio provarci  anche io
con parole mie :-)
La ricorsione si  può usare quando la soluzione di  un problema si può
esprimere  come una  soluzione dello  stesso problema,  ma solo  pi in
piccolo :-) 
Lo so è una definizione....  ricorsiva!
Ammetti di avere una lista di elementi e di dover contare quanti sono:
un  modo è quello  di fare  un ciclo  for e  scorrerla fina  alla fine
(soluzione iterativa).  Nella soluzione risorsiva, si farebbe così:
fun  lunghezza(nil)=0
   | lunghezza(_::lista) = 1+lunghezza(lista)
In pratica enumero i casi possibili:
- lista vuota -> lughezza zero
- lista  con elementi aggiungo  al lunghezza  lista privata  del primo
  elemento
Un altro esempio è l'inversione di una lista di elementi:
inv([1 2 3 4 5]) = [5 inv([1 2 3 4]) 
Sebbene  possa sembrare  un metodo  assai strano  è  pressochè l'unico
usato nei linguaggi funzionali come il  Lisp e ML. E' un altro modo di
ragionare, piuttosto  interessante. Certi problemi  si risolvono molto
più elegantemente usando un stile funzionale che non procedurale.
Questi  linguaggi non  sono molto  usati perchè  non  abbiamo macchine
abbastanza   efficienti  nell'interpretarli,   però  c'è   un  esempio
fantastico  di  utilizzo reale  del  lisp:  l'editor (vabbè  chiamarlo
editor è come dire che una  Ferrari è un'automobile) EMACS, che io uso
per  scrivere,  come IDE  per  lo  sviluppo  del codice,  per  leggere
posta/news.  Qualcuno  lo  considera  una specie  disistema  operativo
perchè ci si fa tutto dentro lì, persino un browser per il web.
Ciao
Marco
-- 
Se amare Linux e' sbagliato, non voglio essere nel giusto.  
	-- Topic per il canale IRC #LinuxGER

domanda complicata! :-))
...Sì... mi viene in testa una domanda che può sembrare semplice,
invero penso che sia complessa... (preparati una risposta che sembri
complessa, ma che nella sostanza sia semplice): secondo te, per
vincere al lotto, non sarebbe il caso di ricercare le cose più
semplici?
Non ho altro modo di esprimermi meglio. Intuisci. :)
Ciao!


> Il tuo codice impiega 1.27 sul mio Pentium 200 (non pII), anzichč 1.6.
MF> 
MF> hmm... pero' girava in finestra windows (8 secondi per 10 sviluppi
MF> integrali)..
bhe, allora č tutto da rifare.
Io  ho  usato  una funzione  della  shell  per  misurare il  tempo  di
esecuzione effettivo, non quello trascorso dall'inizio alla fine.
Ciao
Marco
-- 
Sigmund Freud interpretava i sogni dell'uomo.
Linus Torvalds ne ha realizzato uno.
		-- Reinterpretazione di uno slogan letto di sfuggita,
		   by Zuse

 writes:
MF> 
MF> Ok, vado a vedere l'asm generato e conto le operazioni.
e dunque?
io ho dato un'occhiata all'ASM ma non ci capisco nulla :-)
Ciao
Marco
-- 
Il senso comune e' l'insieme dei pregiudizi acquisiti fino ai diciott'anni
di eta'.
		-- Albert Einstein

 che ci devi fare.
è vero...
quindi è meglio sapere entrambi le soluzioni!
Ciao


 Non ho altro modo di esprimermi meglio. Intuisci. :)
quanto è difficile intuire ciò che non si dice... per poi non dire qul che
si voleva dire... per non ascoltare quello che non si è detto... in modo da
non sapere ciò che non si è voluto dire... per non essere accusati di
sapere... ciò che non si è detto!
Chiarissimo! :-)))


perchè ci si fa tutto dentro lì, persino un browser per il web.
...Insomma si avvicina molto allo spom... di oggetti ipotizzato nel
'93 dall' Ing. G.P. Goku... ;)
ehehehheeh!!!
Grazie e ciao Marcuzzo!!!


io ho dato un'occhiata all'ASM ma non ci capisco nulla :-)
Questo e' venuto fuori dal Borland 3.0:
    // inizio ciclo di fuori
@1@86:
        mov     ax,word ptr [bp-14]
        inc     ax
        mov     word ptr [bp-12],ax
        jmp     short @1@422
@1@114:
        mov     ax,word ptr [bp-12]
        inc     ax
        mov     word ptr [bp-10],ax
        jmp     short @1@366
@1@142:
        mov     ax,word ptr [bp-10]
        inc     ax
        mov     word ptr [bp-8],ax
        jmp     short @1@310
@1@170:
        mov     ax,word ptr [bp-8]
        inc     ax
        mov     word ptr [bp-6],ax
        jmp     short @1@254
@1@198:
    // questo e' count++,. che siccome il comp. e' a 16 bit lo spezza in due
        add     word ptr [bp-4],1
        adc     word ptr [bp-2],0
        inc     word ptr [bp-6]
@1@254:
        cmp     word ptr [bp-6],90
        jl      short @1@198
        inc     word ptr [bp-8]
@1@310:
        cmp     word ptr [bp-8],89
        jl      short @1@170
        inc     word ptr [bp-10]
@1@366:
        cmp     word ptr [bp-10],88
        jl      short @1@142
        inc     word ptr [bp-12]
@1@422:
        cmp     word ptr [bp-12],87
        jl      short @1@114
        inc     word ptr [bp-14]
@1@478:
        cmp     word ptr [bp-14],86
        jl      short @1@86
        inc     si
@1@534:
        cmp     si,10
        jl      short @1@58
        lea     ax,word ptr [bp-22]
        push    ax
        call    near ptr _time
        pop     cx
// qui e' finito e' ha gia' chiamato la time().
Come vedi ci sono, contando solo il ciclo piu' interno (per essere buoni)
almeno queste operazioni:
@1@198:
    // questo e' count++,. che siccome il comp. e' a 16 bit lo spezza in due
        add     word ptr [bp-4],1
        adc     word ptr [bp-2],0
        inc     word ptr [bp-6]
@1@254:
        cmp     word ptr [bp-6],90
        jl      short @1@198
        inc     word ptr [bp-8]
@1@310:
che si traduce in (escludendo count++)
1 confronto
1 salto
1 incremento.
Totale come minimo sono tre istruzioni per cinquina. Piu', ovviamente, ci
sono quelle degli altri cicli e quelli di count++.
Se lo dovessi scrivere io in asm probabilmente non migliorerei di molto le
cose, traducendo ad esempio:
    for (v[5] = v[4] + 1; v[5]++; v[5] < 90)
in
    mov ax, [bp-qualcosa]
    inc ax
    mov [bp - qualcosa + 2], ax   // e questo era v[5] = v[4] + 1
    cmp [bp - qualcosa + 2], 90
    jge fine                                    // e questo era v[5] < 90
    inc [bp - qualcosa + 2]            // e questo era v[5]++;
:fine  // e continua.
Comunque ci metterei tre istruzioni per il ciclo interno (v[5] < 90 e
v[5]++).
Insomma, credo che minimo tre operazioni siano strettamente necessarie.
Dunque i 0.2 secondi del greco sembrano proprio una sparata colossale.
Sempreche, come gia' detto, il succitato non posti del codice piu' veloce.
Marco
PS col Borland ci mette 10 secondi per 10 gruppi di cicli, dunque 1 secondo
per ogni gruppo. Leggermente piu' lento del DJGPP, ma vedendo il codice
credo che il tutto dipenda dall'incremento di count che col borland richiede
minimo due istruzioni (count e' 32 bit, Borland e' 16) mentre il DJGPP se la
cava con una. Le ottimizzazioni c'entrano poco perche' il codice generato
dal Borland e' gia' piuttosto snello e (in questo caso) e' difficile
migliorarlo.

>>>>> "MP" == MagoPeppe  <sydlevacc> writes:
MP> 
MP> Credo di intuire, ma non conosco il lunguaggio usato da te...
volevo _solo_ farti intuire, mica spiegare l'ML :-)
MP> Stile funzionale e procedurale...? Cioè con il primo è possibile
MP> effettuare la ricorsione (in quanto funzione e quindi può essere
MP> funzione di se stessa) e con il secondo no?
MP> 
no.
Il discorso è luuungooo...
Con lo stile  funzionale si usano pesantemente le  funzioni (nel senso
matematico  del  termine):  applichi  una  funzione a  qualcosa  e  lo
trasformi  in  qualcos'altro. Con  lo  stile  procedurale descrivi  la
_sequenza_ di operazioni da compiere.
Vabbè mi sono spiegato malissimo... lascia perdere :-)
Cmq, lo stile non è necessariamente legato al linguaggio: ad esempio è
possibile entro certi limit usare lo stile funzionale anche in C++.
MP> ...Insomma si avvicina molto allo spom... di oggetti ipotizzato nel
MP> '93 dall' Ing. G.P. Goku... ;)
MP> ehehehheeh!!!
bho, non conosco MR. Goku
Ciao
Marco
-- 
Ti devo convincere, o almeno vincere...

 writes:
MF> 
MF> Se lo dovessi scrivere io in asm probabilmente non migliorerei di molto le
io non saprei neanche da dove partire :-(
MF> Dunque i 0.2 secondi del greco sembrano proprio una sparata colossale.
A meno  che Davide ci abbia  dato dentro di MMX,  facendo 4 incrementi
con un sol ciclo...
Ciao
Marco
-- 
La realta' e' solo una conveniente misura di complessita'.
		-- Alvy Ray Smith

con un sol ciclo...
Puo' essere. In effetti l'architettura dei MMX permette qualcosa di simile,
ma dubito che il VB la sfrutti a dovere.
Marco

bho, non conosco MR. Goku
Ah, un grande ingegnere in erba (fuma, fuma!) del nostro Ateneo... ;)
Ciao!


Chiarissimo! :-)))
Ehm... Qualcuno gli tolga la birra, grazie! ;)


> volevo _solo_ farti intuire, mica spiegare l'ML :-)
MP> 
MP> LDA $00
MP> CMP #$4000
MP> BNE $1F2C
MP> STA $FFFF
MP> 
MP> ehehhhe... qualcosa tentai di impararla ai tempi del C64... ah those
MP> were times... :( sigh...
no, ho scritto ML, no LM :-)
ML  è un  linguaggio funzionale,  mentre  quello che  hai riportato  è
Linguaggio  Macchina...   con  quest'ultimo   è  un  po'   diffile  la
programmazione funzionale, credo :-)
Ciao
Marco
-- 
- Mamma, mamma, perche' stiamo spingendo la macchina giu' dalla
  scogliera?
- Zitto, Pierino, altrimenti svegli tuo padre!
		-- Da it.hobby.umorismo

 writes:
MF> 
MF> Puo' essere. In effetti l'architettura dei MMX permette qualcosa di simile,
MF> ma dubito che il VB la sfrutti a dovere.
MF> 
da quanto ne  so io, l'unico modo di sfruttare  MMX, 3DNow e compagnia
bella č  l'assembler. Forse c'č  qualche compilatorino, ma  dubito che
sia un linguaggio diversodal C.
Ciao
Marco
-- 
Un sacco di persone hanno paura dell'altezza.  Io no.  Io ho paura della
larghezza.
		-- Steve Wright

 writes:
AP> 
AP> vedo che sei più in gamba di quanto pensassi!
AP> bravo!
tutt'altro, si tratta di cose vecchie, trite e ritrite, nulla di nuovo
sotto il sole.
Ciao
Marco
-- 
Se pensi che non importi a nessuno se tu sei vivo, prova a mancare un paio di
rate della macchina.
		-- Earl Wilson

in uno sviluppo integrale ?
E no, cosi' non vale, e' come sparare sulla croce rossa!
Se ti prendi in giro da solo che gusto c'e'?
Marco


solo adesso mi accorgo di questi ultimi due messaggi
cosa vi fa pensare che abbia utilizzato il VB ?
mai sentito parlare di MFC ?
ho dato uno sguardo al codice di fabiani, senza offesa ma è una vera cagata.
1 confronto
1 salto
1 incremento.
tre operazioni sono troppe !! e credo che siano pure concettualmente errate
innanzitutto il salto/incremento vanno considerati come un'unica cosa
(tant'è che si ha un incremento quando si ha un salto o quando si chiude un
ciclo). In secondo luogo mi spieghi a cosa ti serve il confronto (???????)
in uno sviluppo integrale ?
ciao

programmazione funzionale, credo :-)
Ah scusami Marcuzzo... Scusate tutti... E' da un po' di tempo che
piglio ca££i per brioches... (come dicevano i mitici Squallor)... :)


 writes:
DG> 
DG> cosa vi fa pensare che abbia utilizzato il VB ?
Sapevo che facevi programmi in VB...
DG> mai sentito parlare di MFC ?
dipende...
mai  sentito parlare  di  alcun linguaggio  di  programmazione che  si
chiami MFC. Le  uniche MFC che conosco io  sono le librerie Microsoft,
ma non  vedo come potrebbero aiutarti...  forse c'è una  classe per lo
sviluppo di combinazioni?
DG> ho dato uno sguardo al codice di fabiani, senza offesa ma è una vera cagata.
senza, offesa, ma mi sembri molto molto molto molto confuso...
DG> tre operazioni sono troppe !! e credo che siano pure concettualmente errate
DG> innanzitutto il salto/incremento vanno considerati come un'unica cosa
!?!?!?
DG> (tant'è che si ha un incremento quando si ha un salto o quando si chiude un
DG> ciclo). 
?!?!?
DG> In secondo luogo mi spieghi a cosa ti serve il confronto (???????)
DG> in uno sviluppo integrale ?
!?!?!??
sarà meglio che  spieghi in italiano le tue  perplessità: il codice di
Fabiani è,  credo, l'unico modo  possibile che ad una  persona normale
verrebbe in  mente di  usare per sviluppare  un integrale,  anzi direi
pure che è frutto di  una persona di intelligenza superiore alla media
dei programmatori.
NB1: si poteva considerare  la semplice enumerazione, come proposto da
     Pulvirenti,  ma  non  vale  perchè  lo scopo  era  sviluppare  le
     combinazioni di un integrale.
NB2:  un genio,  forse,  riuscirebbe a  scrivere  codice migliore,  un
     programmatore  mediamente  dotato  penso  che  farebbe  fatica  a
     scrivere qualcosa di meglio in un linguaggio di alto livello. Per
     l'assembler non mi esprimo perchè non lo conosco.
Quindi, aspettiamo di vedere il TUO codice.
Ciao
Marco
PS mi  viene un dubbio: non sarà  che tu hai calcolato  il _numero_ di
combinazioni, invece che _le_ combinazioni?
-- 
Colmo di un matematico: vivere in una frazione.
		-- Da it.hobby.umorismo

Quindi, aspettiamo di vedere il TUO codice.
Ecco, questo lo aspetto pure io. Ma se il greco sta aspettando di SCRIVERLO
quel codice, mi sa che ci tocca attendere parecchio.
Sempre senza offesa, neh greco?
Marco
PS : leggermente piu' veloce si puo' fare, in asm.
Escludendo count++ ci mette 45 secondi per 100 esecuzioni (sempre in win),
dunque 0.45 secondi per le 44 milioni di cinquine, cioe' 4 colpi di clock
per cinquina (a 400 mhz).
Siamo davvero ai limiti. Ma non diciamolo al greco, eh?
Se ti interessa il codice te lo mando in privato.

 writes:
MF> 
MF> ... ehm... eravamo d'accordo per centomila, no?
quale centomila?!?!?
s'era detto DUE-centomila... :-))
MF> Escludendo count++ ci mette 45 secondi per 100 esecuzioni (sempre in win),
MF> dunque 0.45 secondi per le 44 milioni di cinquine, cioe' 4 colpi di clock
MF> per cinquina (a 400 mhz).
pure in C: escludendo il count  ottengo 0.82 secondi sul mio P200, che
corrispondono a 3.72  cicli di clock per ogni  cinquina (compilato con
gcc -O2). Potenza del gcc...  arrivo persino a 0.60 secondi se compilo
con "gcc  -O", pari a  2.73 cicli per  cinquina. Nota che la  serie di
cicli for  viene effettivamente  eseguita, perchè provando  a generare
sestine,   anzichè  cinquine,  i   tempi  salgono   a  11.90   e  8.92
rispettivamente, quindi confermando i risultati precedenti.
Miracoli della scienza e della tecnica!
MF> Se ti interessa il codice te lo mando in privato.
manda pure, anche se sono già soddisfattissimo dal gcc pure.
Ciao
Marco
-- 
Se una cosa e' troppo bella per essere vera, non e' vera.

con "gcc  -O", pari a  2.73 cicli per  cinquina. Nota che la  serie di
Mi mandi l'asm generato? (forse gcc -s)
Marco


adesso ritorna l' eh, allora era meglio poppare :-)))))))

adesso in toscana si usa il neh ? meglio puppare :-)))
Se preferisci, puppa pure..
Marco

 Sono disponibile per ripetizioni di informatica. Se vuoi fatti sentire.
e invece ci sono 3 confronti e tre salti!
per confronti non si devono intendere solo gli "IF", ma ogni volta che si
effettua un ciclo (in ognuno dei 3 cicli) viene effettuato un confronto con
il valore finale del ciclo in modo da sapere quando finirlo, soltanto che
non è visibile...
e ci sono pure 3 salti, l'istruzione "Next n1,n2,n3" serve proprio a questo,
a saltare all'inizio di ogni ciclo.
Per finire...
mi sembra molto strano che tutti non si siano resi conto di un errore di
fondo!
inutile fare il calcolo dei cicli di clock e del tempo impiegato
dall'algoritmo di sviluppo delle 43 milioni di cinquine... dato che quelle
cinquine così come sono non servono a niente!
Perché il tempo lo avete calcolato solo per generare le cinquine... ma se
quelle cinquine (per assurdo) si dovevano mettere in un vettore... vedete
come salgono i cicli di clock per spostare i bytes che compongono le varie
cinquine! :-((
se poi si devono ridurre le combinazioni in modo da avere un sistema
ridotto, vedrete che il tempo di generazione delle cinquine è un tempo che
incide poco nel complesso dei calcoli che si devono fare.
fare un sistema integrale efficiente è una barzelletta rispetto a un sistema
ridotto efficiente!
Ciao a tutti
P.S. "in genere conviene sempre non vantarsi... dato che si trova sempre in
giro quaalcuno più bravo..." è un bel detto che dico sempre agli altri!
:-)))


:-)))
Concordo.
Ma e' meglio applicarli (".. programmi di un certo livello..") anche, i
consigli che si danno agli altri.
Ciao,
Marco

salve
come facevamo noi della nova a rimanere fuori da questo discorso.
premettiamo che ci sono diversi livelli della programmazione, sia esso in
basic, c++, o asm.
il nostro modo di programmazione(anzi il mio,pippo)non e' assolutamente a
prova di terremoti, o bombe varie, e non voglio certo confrontarmi in nessun
modo con altri programmatori sicuramente piu' capaci. poiche' non sono un
laureato di informatica e di matematica, e l'esperienza ventennale dei
compilatori, mi ha portato ad affinamenti continui e costanti. Non
dimentichiamoci che se ad una buona programmazione si associano delle buone
idee(senza essere dettate da altri) il prodotto finale e' sempre molto
buono. In genere non ci piace programmare per gli altri, ma solo per noi
stessi perche' ricordiamoci che dopo aver sudato sette camicie, i soli a
vantarsi e battere cassa sono i cosidetti lottologi.
capiamo il pulvirenti che e' strettamente legato per motivi di contratto,
anzi mi verrebbe di incontrarlo per chiedergli dei suggerimenti e migliorie
su certi aspetti della programmazione di cui sono ancora carente, lancio una
pietra....
l'ultima considerazione: un buon programmatore, indipendentemente dal suo
livello, riesce a superare sempre i problemi e trovare gli algoritmi giusti
per raggiungere lo scopo. e la carenza principale e quella di non dipendere
troppo dagli altri e sviluppare le sue idee. noi di idee crediamo di averne
e ci permette di tirare fuori dei programmi che serviranno sicuramente a
quelli che amano la statisica e quelli che cercano nuovi modi di vedere
questo affascinante mondo del lotto.
un piccolo ma creativo programmatore
pippo (e mario che mi istiga...)

 writes:
DG> 
DG> c'è anche una buona percentuale di scettici spammatori e anarchici
DG> flooddatori :-))
è uno sporco lavoro, ma qualcuno deve pur farlo :-)
DG> alla soluzione. Alla stessa soluzione ci sono arrivato da solo ricavandomi
DG> quelle formulette (che sono enormemente più veloci). Se ora le pubblicassi
DG> mi farei un grandissimo torto.
uè, calma e sangue freddo!
nei NG è prassi darsi una mano, è prassi condividere la conoscenza.
le  _VOSTRE_  gelosie, a  questo  punto,  fanno  pensare più  a  degli
spammatori in cerca di facile pubblicità o di idee altrui da sfruttare
aggratis...
DG> Veniamo al codice di una persona che ha un'intelligenza superiore alla media
DG> (sono contento che Marco ti stimi tanto), ma credo che quel codice non sia
DG> proprio una genialata
Io ti consideravo un programmatore medio.
Il codice che posti tu lo sarebbe, ma i tuoi commenti sono al di sotto
della media :-( mi devo ricredere...
DG> Elementi = 90
DG> Sviluppo = 3
DG>     n1 to (Elementi - Sviluppo)+1
DG>         n2 to (Elementi - Sviluppo)+2
DG>             n3 to (Elementi - Sviluppo)+3
DG>                     Colonne++
DG>                 Bolletta^Colonne = n1; n2; n3
DG>     Next n1,n2,n3
Ma  questo  codice,  zucchero  sintattico  a  parte,  è  ASSOLUTAMENTE
IDENTICO a quello di Fabiani.
Potrebbe  essere  altrettanto  veloce  se  _SOLO_ ci  fosse  sotto  un
compilatore con palle e contropalle,  ma dato che assomiglia più ad un
qualsiasi basic,  dubito fortemente  che possa uguagliare  i risultati
dell'analogo  in C,  i  cui compilatori  sono notoriamente  fortemente
ottimizzati e performanti.
DG> scrivendolo in linguaggio molto semplice la lunghezza del codice è pari a
DG> max 14 righe (per stare larghi) con una velocità di calcolo sicuramente
DG> buona. 
ti prego, dimmi che scherzavi...
quale importanza può avere il numero di righe rispetto all'efficienza?
perchè se  è rilevante, allora il mio  codice sta su una  riga sola di
196 caratteri, eccolo spezzato per comodità di lettura:
int main(void){int count=0;int v[5];for(v[0]=0;v[0]<86;++v[0])
for(v[1]=v[0]+1;v[1]<87;++v[1])for(v[2]=v[1]+1;v[2]<88;++v[2])
for(v[3]=v[2]+1;v[3]<89;++v[3])for(v[4]=v[3]+1;v[4]<90;++v[4])count++;}
questo si compila così com'è, senza modifiche!
DG> in questo codicillo non ci sono confronti, salti, zirigori ecc ecc,
DG> soltanto un contatore per la memorizzazione delle bollette.
siamo alla frutta...
sì, ma cotta! [1]
Forse   dovresti   leggerti    qualche   manuale   introduttivo   alla
programmazione, credo che ti chiarirebbe un po' di confusione.
Ciao
Marco
Note: 
[1]  notoriamente la frutta cotta ha proprietà lassative.
-- 
La mente e' una cosa meravigliosa.  Tutti dovrebbero averne una.

 writes:
M> 
M> 6-. Ti sei dimenticato degli incrementi delle variabili.
M> Quindi, in totale, come minimo ci sono 1 confronto, 1 salto e 1 incremento
M> per ogni cinquina.
hai analizzato l'asm prodotto dal gcc?
soprattutto, hai  verificato come sia possibile  macinare una cinquina
in meno di 4 cicli? merito dell'architettura del Pentium?
Ciao
Marco
-- 
 Liberi TUTTI !!!

 writes:
AP> 
AP> io sono geloso del mio codice per due motivi:
AP> 1) motivi contrattuali (non posso far vedere codice inserito nei miei
AP> programmi pena il pagamento di elevate somme come penali!; quindi al
AP> massimo potrei essere generico!)
dai..
vuoi dire che non puoi pubblicare cose tipo:
for( int i=0; i< N; ++i)
perchè avresti delle penali?
non scherziamo...
Un SW commerciale, specie quando dotato di interfaccia grafica, magari
pure generata (semi)automaticamente si spantega su migliaia e migliaia
di  linee  di codice  e  tu  vuoi farmi  credere  che  hai problemi  a
pubblicare le 5 linee meno importanti?
AP> 2) motivi di concorrenza (il mio codice è molto ottimizzato e antisismico!
AP> :-)    
siamo veramente all'assurdo!
ma ti rendi conto?!?!?
mi tiri 'ste paranoie mentre  le SH più importanti stanno abbracciando
l'Open Source Software? Linus Torwald pubblica linux, Richard Stallman
regala  Emacs, miglia  di sviluppatori  distribuiscono i  sorgenti con
licenza GPL (che si facciano pagare o meno per farlo), la Sun pubblica
i sorgenti del jdk e altre  valanghe di pacchetti e tu ti fai problemi
a  scrivere   5  righe  di  codice?    le  5  righe   di  codice  meno
caratteristiche del tuo SW per lotto?
nahh...
AP> inutile fare il calcolo dei cicli di clock e del tempo impiegato
AP> dall'algoritmo di sviluppo delle 43 milioni di cinquine... dato che quelle
AP> cinquine così come sono non servono a niente!
si  parlava   di  codice  per  la  generazione   delle  cinquine,  non
dell'elaborazione delle stesse, nè dell'output (in chissà quale strano
formato, su  chissà quale strano  dispositivo a chissà  quale transfer
rate)
AP> Perché il tempo lo avete calcolato solo per generare le cinquine... ma se
AP> quelle cinquine (per assurdo) si dovevano mettere in un vettore... vedete
AP> come salgono i cicli di clock per spostare i bytes che compongono le varie
AP> cinquine! :-((
lo scopo era solo di scrivere del codice efficiente per la generazione
di un integrale, indipendentemente da quello che poi uno ci fa.
AP> se poi si devono ridurre le combinazioni in modo da avere un sistema
AP> ridotto, vedrete che il tempo di generazione delle cinquine è un tempo che
AP> incide poco nel complesso dei calcoli che si devono fare.
Nessuno stava parlando di riduzione.
AP> fare un sistema integrale efficiente è una barzelletta rispetto a un sistema
AP> ridotto efficiente!
già,  perchè  'efficiente' è  un  termine  abbastanza  univoco per  un
integrale, mentre nel caso di un ridotto ci sarebbe da discutere molto
molto molto molto molto a lungo.
Ciao
Marco
-- 
Incubo del daino:
	"Stanotte ho sognato di pulire un parabrezza".
		-- Da it.hobby.umorismo

Ok ragazzi, VI DO LA SOLUZIONE VERA E PROPRIA.
Se vi ricordate il discorso logico che avevo postato quando avevo dato la
prima soluzione, il tutto continua a valere, ma.......... con la differenza
invece che sommare, SOTTRAIAMO!!! Ora vi spiego
Sappiamo tutti che le cinquine  che si possono formare con 90 elementi sono:
43.949.268; partiamo da qua. Prendiamo un cinquina a caso, e ordiniamola in
senso crecente, per esempio:
5-14-21-62-77
Malignamente la prima volta cosa vi avevo detto? Sommiamo tutte le cinquine
che iniziano 1,2,3,4 poi le quaterne che iniziano con 1,2,3,..,13 e cosi
via. Ve lo ricordate? Ma se aveste spremuto un po' le meningi, mi avreste
detto: "ma che sei matto?, č piů semplice..." Ora vi spiego cosa č piů
semplice:
invece che sommare le cinquine e le quaterne... etc, vediamo quante ne
mancano!!! Vi faccio i passaggi che sono meglio di qualsiasi spiegazione
allora abbiamo la cinquina 5-14-21-62-77
A = (90 - 5) = 85
S1 = 85 * 84 * 83 * 82 * 81 / 5! = 32.801.517
B (90 - 14) = 76
S2 = 76 * 75 * 74 * 73 / 4! = 1.282.975
C = (90 - 21) = 69
S3 = 69 * 68 * 67 / 3! = 52.394
D = (90 - 62) = 28
S4 = 28 * 27 / 2! = 378
E = (90-77) = 13
S5 = 13
 quindi se facciamo:
I = 43.949.268 - S1 - S2 - S3 - S4 - S5 = 9.811.991
CHE E' PROPRIO L'INDICE CERCATO!!!
Sempre in basic il discorso si ridurebbe a:
(indicando con N1,N2,N3,N4,N5, gli elementi ordinati crescenti della
cinquina)
....
S1 = (90-N1)*(89-N1)*(88-N1)*(87-N1)*(86-N1) / 120
S2 = (90-N2)*(89-N2)*(88-N2)*(87-N2) / 24
S3 = (90-N3)*(89-N3)*(88-N3) / 6
S4 = (90-N4)*(89-N4) / 2
S5 = (90-N5)
I = 43.949.268 - S1 - S2 - S3 - S4 - S5
......
6 operazioncine ed č tutto finito!!! piů veloce di cosě!!!
E' da notare che tale metodo, con le dovute sostituzioni, č valido anche per
cercare gli indici delle quaterne, dei terni, e degli ambi, riducendosi a 5,
poi a 4, poi a 3 operazioni rispettivamente nel primo, secondo e terzo caso.
Concordo con Pulvirenti, quando dice in poche parole, si ma cosa ci fate
poi? Anzi lo avevo fatto notare prima io....
Sicuramente se vogliamo per esempio controllare qual'č la cinquina piů
ritardo per ambo su una ruota o su Tutte, non mi metterň certo a controllare
tutte le 43.949.268 formazioni, ma utilizzerň un altro metodo.... vi
piacerebbe saperlo?
Non so se ve lo meritate (scherzo!!!). Provate a fare qualche sforzo prima,
poi caso mai vi do la soluzione.....
Bye bye....
DEVIL D.

ma lasciandolo sempre efficiente!)
Posso polemizzare su "i programmi di un certo livello" ? Se così
fosse, come mai Lottovelox ha bisogno di una cinquantina di patch ?
=))
Secondo me non esistono algoritmi universalmente migliori di altri,
tutto dipende dal contesto in cui vengono progettati e utilizzati. Per
un programma per il lotto, si può benissimo dire che (tranne casi
limite) tutti gli algoritmi si equivalgono
Wolf
"Lo stress è quell'apostrofo grigio tra le parole...M'INCAZZO"
[Remove numbers for correct e-mail address]
"Tariffe a tempo sviluppano pensieri a breve termine"
(Nicholas Negroponte contro la TUT)
Visitate e supportate: --> 
www.notut.org
 <---

in meno di 4 cicli? merito dell'architettura del Pentium?
Sinceramente non lo so.
L'unica cosa che mi viene in mente e' nella branch prediction, che 89 volte
su 90 (cioe' sempre tranne che all'uscita) ci prende, e questo toglie il
tempo per il salto. Quindi la BW di picco (come si direbbe..) e' di 2 colpi
per cinquina.
Ovviamente supponendo di avere le pipeline piene ecc.ecc.
Chiaro che gli accessi in memoria in pratica non ci sono, perche' sta tutto
in cache (e ci si accede un colpo al secondo), anzi nella mia versione piu'
veloce avevo pure messo tutto nei registri..
Occorre dire che sto considerando il solo ciclo interno, in quanto e'
responsabile della maggior parte del tempo di elaborazione, ma se si
considerano gli altri c'e' sicuramente un incremento (del numero medio di
colpi per cinquina).
Credo che questo possa essere un motivo, ma non ne sono sicuro. Ne' sono
sicuro che possa essere l'unico.
Morale: tecnicamente le tre istruzioni sono secondo me indispensabili (a
meno di non srotolare qualche loop, ovviamente), ma alcuni accorgimenti
particolari potrebbero portare il PII a comportarsi meglio.
Ad esempio un alignment a multipli di 8 (che il Borland non fa) potrebbe
migliorare l'accesso in memoria, o il classico trucchetto di mettere come
chiusura dei cicli
sopra:
    inc ax
    cmp ax, 89
    jl sopra
    jmp ciclo_precedente
piuttosto che
sopra:
    inc ax
    cmp ax, 90
    je ciclo_precedente
    jmp sopra
Ad esempio in questo caso, supponendo le condizioni piu' favorevoli, secondo
me il "jl sopra" non fa perdere un ciclo, e dunque si arriverebbe al minimo
di due cicli per colpo di clock (inc ax e cmp ax,90).
Sempreche' naturalmente la branch prediction ci prenda (Oddio, forse se e'
bene implementata ci prenderebbe anche nel secondo caso..).
Comunque, tornando al gcc, nelle mie prove ci mette ben di piu' di 3 colpi
(circa 6 o 7).
Non so se dipende dal DJGPP o da qualcos'altro. (gli asm erano piu' o meno
identici).
Marco

 piacerebbe saperlo?
visto che il linguaggio naturale (quello parlato dall'uomo) è molto
ambiguo... :-((
dobbiamo capire di cosa stiamo parlando!
Quando si parla di "Cinquina più in ritardo per Ambo", si possono intendere
due cose:
1) la cinquina che ha all'interno l'ambo più ritardatario (per questo basta
cercare qualsiasi cinquina che abbia l'ambo più ritardato in assoluto);
2) la cinquina che ha un valore di ritardo (formato dalla somma dei ritardi
dei 10 ambi possibili) più alto rispetto a tutte le altre cinquine!
Cosa intendi dire tu?
Ciao


 Wolf
Alex


 molto molto molto molto a lungo.
mi vengono in mente due tipi di efficienza...
1) a parità di numero di combinazioni ottenuto nel sistema ridotto, è più
efficiente quello che impiega meno tempo (efficienza temporale)
2) con tempo dello stesso ordine di grandezza, è più efficiente chi ottiene
meno combinazioni nel sistema ridotto (complessità sul numero di
combinazioni)
io mi riferivo alla prima...
comunque... "mamma"(1) Microsoft ci insegna che il software che ha più
successo non è quello più efficiente... ma quello meglio pubblicizzato! :-((
Ciao
(1) "mamma" tanto per dire... non va a genio neanche a me!... però si
debbono pur riconoscere i meriti che ha avuto... quali? :-)))


 pippo (e mario che mi istiga...)
in genere tutti i programmatori sono creativi, dato che dal niente (o quasi)
mettono insieme dei pezzi e sfornano dei programmi buoni o brutti che
siano...
Sfortunatamente il tempo a mia disposizione è inesistente!!! :-((
Debbo consegnare un lavoro per Febbraio e con tutte le altre cose che debbo
fare mi sembra difficile di trovare il tempo anche per respirare...
e va bene... non esagero... il tempo per respirare ce l'ho... però sono
molto occupato in questo periodo!
Ciao


debbono pur riconoscere i meriti che ha avuto... quali? :-)))
Beh, un merito ce l'ha.
Grazie a M$ chiunque si puo', a buon diritto, sentire un grande
informatico.. :-o
Marco

[1]  notoriamente la frutta cotta ha proprietà lassative.
devo credere che l'hai provata spesso per affermarlo ?

Sono disponibile per ripetizioni di informatica. Se vuoi fatti sentire.
devo fare bau bau o miao miao ?
ma vai va

N)lancio una pietra....
P>per fortuna che l'ho evitata... perchè se mi prendavate erano poi dolori
per
voi! :-)))
ti lanciero' tante pietre, durante il percorso sul ng, tanto sono sicuro le
saprai evitarle,  ma non si sa mai... se te dovesse arrivarne una...
concordo con le tue risposte, a certi livelli un programma deve essere
progettato sin dall'inizio con lo stesso criterio di come si progetta un
aereo.
una cosa che mi indispettisce molto e' quando sul ng credono che un folto
gruppo di programmatori siano presenti solo per vendere qualche cosa e
nessuno pensa che dal ng mi sono fatto moltissimi amici, piu' che in 40 anni
di vita. E invece a chi costruisce metodi vi e' una sorta di licenza a
vendere.
pippo (e mario anche se non c'e')

salve
Di fronte a queste gelosie, mi cascano le palle !
qui' nessuno deve dimostrare niente a nessuno, le capacita' singole di
ognuno e la genialita' nell'affrontare i problemi li lascio alla
soggettivita' di ognuno di noi, e' bello poter navigare nei codici senza
sapere di essere uno scenziato, sapendo che l'affinamento ci puo' sempre
essere anche dopo.
scusate il mio modo passionale e romantico della programmazione.
pippo (e mario che se la ride alle spalle...)

numeri e con efficienza temporale che lascia il tempo che trova...
Ahhh, ora ho capito... Vedi, il discorso, secondo me, è puramente
accademico, in quanto qualsiasi algoritmo di riduzione di 90 numeri
potrà pure essere una dimostrazione di bravura, ma ha un'utilità
pratica uguale a 0, così pure la riduzione di 32 o 25.
Sempre IMHO, la quantità di numeri massima da giocare deve essere
sempre <= 18, ma queste sono opinioni personali...
Wolf che gioca sempre al massimo 7/8 numeri


numeri e con efficienza temporale che lascia il tempo che trova...
Scusa, per "riduzione" intendi la riduzione classica (n-1, n-2 ecc) oppure
l'appilcazione di filtri?
Marco

Posto per conto di Saltafossi un contributo alla discussione:
Ciao.
Ecco di seguito una routine che permette,
dato un insieme di numeri ordinati e consecutivi (o resi tali),
di determinare l'indice di
qualsiasi ennupla
ordinata appartenente all'insieme dei numeri considerati
(non necessariamente 90; le limitazioni
sono date dalla capacita' del calcolatore e/o i tipi definiti).
La routine implementa una formula, non un algoritmo.
Provatela! probabilmente è la più veloce e versatile di quelle viste finora.
Sono gradite osservazioni.
Saluti, Saltafossi
Dim i As Integer, enne As Integer, numeri(10) As Integer
Dim qnum As Integer, num As Integer, kappa As Long
Dim indice As Double, piu As Double, meno As Double, pro As Double
'l'array numeri() memorizza l'ennupla ordinata
'inizializzazione
enne = 6 'sestine
qnum = 90 '90 numeri
'routine
numeri(0) = 0 'sempre vero
'calcolo della prima costante a dividere
kappa = 1
For i = 2 To enne
 kappa = kappa * i
Next i
indice = 1
For num = 1 To enne
 piu = qnum - numeri(num - 1): pro = piu
 For i = 1 To (enne - num)
  pro = pro - 1
  piu = piu * pro
 Next i
 meno = qnum - numeri(num) + 1: pro = meno
 For i = 1 To (enne - num)
  pro = pro - 1
  meno = meno * pro
 Next i
 indice = indice + (piu - meno) / kappa
 kappa = kappa \ (enne - num + 1)
Next num

 writes:
AP> 
AP> è vero che c'è l'Open Source Software, ma è anche vero che questo metodo per
AP> alcuni tipi di software non va bene! :-((
i videogiochi, ad esempio: in generale laddove non ci sia necessità di
un rapporto continuo con l'utente.
AP> mi vengono in mente due tipi di efficienza...
a me almeno altre due:
- l'algoritmo che massimizza le probabilità di vincita
- l'algoritmo che massimizza la vincita attesa
AP> (1) "mamma" tanto per dire... non va a genio neanche a me!... però si
AP> debbono pur riconoscere i meriti che ha avuto... quali? :-)))
un marketing fantastico!
incredibile  che  il settore  migliore  della  più  grossa azienda  di
informatica non sia una divisione tecnica, ma una commerciale...
Ciao
Marco
-- 
Un tarlo alla moglie: "Stasera ti porto a mangiare cinese; arriva un
carico di legname da Hong Kong...".
		-- Da it.hobby.umorismo

 Wolf che gioca sempre al massimo 7/8 numeri
Alex che i clienti gli chiedono (e pretendono) lo sviluppo di sistemi di
tutti i tipi possibili e immaginabili!


 l'appilcazione di filtri?
intendo dire riduzione N-1, ... per sistemi ridotti o ortogonali (simmetrici
o misti).
i filtri sono cose cosė banali (nella programmazione) che neanche li
consideravo!
Ciao


abbiano una certta lunghezza...
Sì, certo... Vallo a dire ai progettisti (per esempio) che fanno
programmi per il controllo direzionale dei satelliti
<ESEMPIO PARADOSSALE MA POSSIBILE>
"Scusi direttore, il satellite X è uscito dall'orbita ed è caduto su
un centro abitato per un bug nel programma... Niente di grave, basta
una patch e si risolve tutto..."
</ESEMPIO PARADOSSALE MA POSSIBILE>
Il mio discorso era un po' più "ampio", nel senso che nella mia
"pocaconoscenzasoloteoricadellaprogrammazione" sono propenso a credere
che c'è e ci sarà sempre una certa differenza tra i programmi per il
Lotto e altri tipi di softwares. Non era mia intenzione sminuire il
tuo lavoro (o quello degli altri autori), ma mi sembra che spesso ci
sia una tendenza a perdere il contatto con la realtà, considerando
come dei "sacri Graal" dei programmi (anche ottimi) che rappresentano
pur sempre un'applicazione hobbistica
Wolf che è diventato capoprogetto solo con la conoscenza teorica


 Wolf che è diventato capoprogetto solo con la conoscenza teorica
Alex che sviluppa programmi commerciali solo dopo una buona conoscenza
teorica e molta sperienza pratica


danni per più di 3.000 miliardi di lire!!!!!!
Davvero l'esplosione dipese da un bug?
Per quello che ricordo era un tubo che perdeva...

teorica e molta sperienza pratica
Ehm, la mia era una battuta, la realtà è esattamente opposta. Ho
comiciato a programmare a 14 anni su un PET-CBM (un cassone con 5 kb
di memoria Ram VOLATILE e che all'epoca costava 12/13 testoni) e non
ho più smesso
Wolf che a 33 anni fa finalmente lavorare gli altri


 Wolf che a 33 anni fa finalmente lavorare gli altri
Alex che a 27 anni non è ancora stanco di lavorare :-)))


ho detto che mandavo l'Exe
No. Hai detto che *avevi mandato* l'exe, ma non s'e' visto.
Marco

> programmazione, credo che ti chiarirebbe un po' di confusione.
DG> 
DG> 
DG> salto sempre l'introduzione per evitare  di leggere il tuo nome in
DG> calce alla prefazione
DG> 
mi spiace che tu l'abbia presa male.
Non volevo  denigrarti, ma solo darti un  suggerimento costruttivo.
Pazienza, non  mi sembra  il caso di  continuare una  discussione così
sterile
Cordialmente
Marco
-- 
Legge di Malek:
	Ogni idea semplice sara' espressa nella maniera piu' complicata.

 writes:
MF> 
MF> Davvero l'esplosione dipese da un bug?
MF> Per quello che ricordo era un tubo che perdeva...
ah, meno male che non ero il solo a saperla cosě...
si trattň di un componente meccanico difettoso, non di un SW bacato...
Ciao
Marco
-- 
Quella non e' una luna...
		-- Obi-wan Kenobi

 writes:
AP> 
AP> per la precisione il bug era dovuta a una semplice assegnazione a una
AP> variabile a 16 bit del valore contenuto in una a 32 bit.
mah, tanto  per cambiare sono scettico:  qualunque compilatore segnala
conversioni di tipo pericolose... 
BTW, sai dove posso trovare informazioni più dettagliate?
Ciao
Marco
-- 
Carcarlo Pravettoni: davanti l'uomo, di dietro il manager, e di fianco
l'infermiere con le siringhe.
		-- Scheda di C. Pravettoni, "Mai Dire Gol",
		   by Walter Fontana

cosa diceva fabiani ???
"se il codice lo devi ancora scrivere....."
"quando vuoi ti do lezioni di programmazione...."
mmmmmmmmmmmmmmmmmmm
mmaaaaa vaaaaaaaaaiiiii va
Indice =5
Nn = 90
    For x = 1 To Indice
        Indici(x) = x
            Next x
While Indici(1) <= Nn - Indice + 1
    Colonne = Colonne + 1
    For x = Indice To 1 Step -1
        Indici(x) = Indici(x) + 1
    If Indici(x) <= Nn - (Indice - x) Then
        If x = Indice Then Exit For
            w = 1
        For Y = x + 1 To Indice
            Indici(Y) = Indici(x) + w
                w = w + 1
                    Next Y
                        Exit For
                                End If
        Next x
            Wend
Questo è un bel codice.. e non è solo una questione soggettiva.
Davide
(che fa regali tutto l'anno... e a natale che fa ??)

"quando vuoi ti do lezioni di programmazione...."
Confermo.
Ma dopo aver letto quanto hai scritto credo che dovremo ripartire proprio
dall'ABC, e ti costera' qualcosa in piu'.
Marco

 writes:
DG> 
DG> Indice =5
DG> Nn = 90
DG> 
DG>     For x = 1 To Indice
DG>         Indici(x) = x
DG>             Next x
DG> 
DG> While Indici(1) <= Nn - Indice + 1
DG>     Colonne = Colonne + 1
DG>     For x = Indice To 1 Step -1
DG>         Indici(x) = Indici(x) + 1
DG> 
DG>     If Indici(x) <= Nn - (Indice - x) Then
DG>         If x = Indice Then Exit For
DG>             w = 1
DG>         For Y = x + 1 To Indice
DG>             Indici(Y) = Indici(x) + w
DG>                 w = w + 1
DG>                     Next Y
DG>                         Exit For
DG>                                 End If
DG>         Next x
DG>             Wend
DG> 
con che programma l'hai indentato?
con Khulo 0.2 beta? :-)
DG> Questo č un bel codice.. e non č solo una questione soggettiva.
meno  male  che  pochi   messaggi  fa  parlavi  di  "stile,  eleganza,
chiarezza...."
E' un algoritmo  piů generale di quello di  cui discutevamo, in quanto
al codice... fa venire i brividi, meglio soprassedere...
comunque, nel caso  te lo fossi dimenticato, la  questione di partenza
era: in C riesco a generare una cinquina in poco meno di 3 cicli clock
(pari a 0.61  secondi sul mio P200), mentre  tu affermavi di riuscirci
in  un battibaleno.   Ti sei  vantato, hai  denigrato, ma  ancora devi
mostrarci i tuoi prodigi.
Attendendo
Marco
-- 
Alberto Tomba ha abbordato [l'attrice] Lorena Forteza dicendole: "Sono
iscritto all'AIDO; ti serve qualche organo?".
		-- Panfilo Maria Lippi, "TABLOID TABLOID"@"Mai Dire Gol"

al codice... fa venire i brividi, meglio soprassedere...
non riesci ad interpretarlo oppure ormai non puoi fare a meno di criticare
sempre tutto e tutti ?
boh

> con Khulo 0.2 beta? :-)
DG> 
DG> non fa ridere
non _TI_ fa ridere
è diverso.
DG> non riesci ad interpretarlo oppure ormai non puoi fare a meno di criticare
DG> sempre tutto e tutti ?
leggi quello che scrivo prima di rispondere.
Ho parlato del codice, non  dell'algoritmo: il codice è tutt'altro che
bello, già  solo per l'indentazione...  no, quella non si  può neanche
definire indentazione... 
Marco
-- 
Orgasmo, s.m.:
        Retroazione positiva che porta all'instabilita' il sistema.
		-- Andrea `Zuse' Balestrero

l'appilcazione di filtri?
Scusa, per "applicazione di filtri" non si intende il condizionamento?
Ciao.
MagoPeppe
"Il buon giorno si vede solo a sera". (Stefano Cassiani)
"Solitamente, quando qualcosa ti apre gli occhi,
prima ti ha già aperto il culo". (Giuseppe Liuzzo)
"Quando gli manca la Dama il Cavaliere si da' al maneggio". (Ignoto)
"Nessuna nuova, buona nuova... 
Due palle come due uova, ma buona nuova". (Giuseppe Liuzzo)
Staff Tecnico MPO & NuovaCornucopia
http://dreamlink.net/magopeppe
ICQ 9759626
Togli levaccà per contattarmi via email.

Scusa, per "applicazione di filtri" non si intende il condizionamento?
Si. Ma molti usano "riduzione" anche per il condizionamento.
Marco
--
Il sito di riferimento per gli scommettitori:
www.totoclub.com

Si. Ma molti usano "riduzione" anche per il condizionamento.
E' giusto ed errato, credo. :)
Ciao Marco.
