Newsgroup: it.hobby.lotto
Titolo: idee per la riduzione di un sistema

ok lancio la mia tesi per l'ottimizzazione dei sistemi ridotti
la finalità è la seguente:
ottenere da uno sviluppo il minor numero di colonne possibili cercando
dunque di evitare la riduzione classica alla quale, come sappiamo, si può
ovviare in tanti modi ma al momento senza una alternativa che si possa dire
veramente valida e unica per tutti i sistemi. La finalità è ovviamente
rivolta a coprire tutte le combinazioni richieste con il minor numero di
colonne. Ad esempio con 15 numeri in cinquine vogliamo il terno con 3 numeri
esatti.
ci sono due strade:
A) ortogonali puri (cioè senza ripetizioni)
B) ortogonali impuri o misti (cioè con ripetizioni)
la strada B pare che sia quella più agevole (e anche l'unica percorribile)
perchè consente di raggiungere buoni sviluppi anche se con qualche colonna
ripetuta (ovviamente non in tutti i sistemi, ma quando è necessario). La
strada A ha il forte limite di risultare praticamente "impossibile" per
risolvere tutte le combinazioni di tutti i sistemi. La strada A può, però,
portare a dei buoni sviluppi ridotti con i quali in seguito, aggiungendo
combinazioni (con annesse ripetizioni),  possiamo risolvere l'integrale.
Cioè inevitabilmente la ricerca dello sviluppo integrale ci porta alla
strada B
innanzitutto occorre partire da una base valida.
Pasquale credo che abbia qualcosa da dirci (magari il cobol lasciamolo a
dopo), per adesso cerchiamo di puntualizzare per iscritto il da farsi... poi
a scrivere codice penseremo dopo.
Il mio punto di vista per partire "bene" è quello di cercare tutte le
possibili colonne con zero punti in comune, poi quelle con un punto in
comune, e via dicendo fino a quando tutte le combinazioni richieste saranno
state coperte. Questo punto di partenza credo sia abbastanza semplice per
tutti. Però c'è da fare i conti con diverse questioni quali potrebbero
essere le consecutività e le possibilità di sviluppo per ogni grado
successivo (0 punti, 1 punto, 2 punti in comune, ecc ecc)
cordiali saluti
Davide Greco

 writes:
DG> 
DG> La finalità  è ovviamente rivolta a coprire  tutte le combinazioni
DG> richieste con il minor numero di colonne. 
io non limiterei l'obbiettivo  alla minizzazione delle colonne: alcune
colonne  potrebbero essere  preferibili  ad altre,  ad esempio  perchè
considerate  più probabili.   'Ovviamente' non  mi riferisco  al lotto
(dove  comunque a  molti potrebbe  far  comodo), ma  ad altri  giochi.
Infatti,  IMHO, visto  che il  problema della  riduzione è  generale a
tutti i giochi  dovrebbe mantenere un certo livello  di astrazione, in
modo  da  riutilizzare  tutto  anche  in  altri  giochi  (che  più  mi
interessano :-)).
Questo è un obbiettivo molto semplice da raggiungere se progettiamo ad
oggetti: basta definire una  classe 'combinazione' differente per ogni
gioco.
DG> Pasquale  credo  che abbia  qualcosa  da  dirci  (magari il  cobol
DG> lasciamolo  a dopo),  per  adesso cerchiamo  di puntualizzare  per
DG> iscritto il da farsi... poi a scrivere codice penseremo dopo.
d'accordo
In un  altro messaggio  ho accennato ai  benefici pratici  che avremmo
utilizzando 
sourceforge.net
:
- mailing list
- forum web
- nome di dominio di terzo livello
- repository CVS
- 100 MB di spazio web per la home page
Se  approvate,  posso  preoccuparmi  io  di  aprire  l'account,  basta
decidere un nome per il progetto!
Io butto "ridux", e voi?
Ciao
Marco
-- 
Fino all'anno scorso avevo un solo difetto: ero presuntuoso.
		-- Woody Allen

Io butto "ridux", e voi?
molto bene.... giusto per iniziare a coprire quei 100 mb di spazio potremmo
invitare tutti a pubblicare sistemi (qualsiasi genere) in modo che tutti ne
possano usufruire. Ovviamente parlo di sistemi "particolari" e non di quelli
che si ricavano coi soliti riduttori n-x
Intanto ideuzza per i più volenterosi: chi crea lo script Java per ridurre
un qualsiasi sistema On-Line ? ho visto qualcosa del genere in qualche sito
ma non ricordo quale... solo che li era lentissimo... noi lo dobbiamo far
girare a "palla"
ok per quanto dicevi della generalizzazione del sistema per qualsiasi tipo
di gioco. Sulla maggior incidenza di determinati numeri possiamo studiarci.
per il nome del progetto.... più che "ridux" direi
"The_Last_System_Of_Human_Intelligence" eheheheheheh
ciao
Davide

 writes:
DG> 
DG> molto bene.... giusto per iniziare a coprire quei 100 mb di spazio
DG> potremmo invitare tutti a pubblicare sistemi (qualsiasi genere)
al tempo :-)
1) i 100 MB sono a disposizione, ma non mi pare saggio e sicuro dare a
   *chiunque* la possibilità di scriverci dentro.
1b) ce li spari tu 100MB di roba via telefono?!?! :-)
2) prima ancora  dovremmo stabilire un  formato comune e  adeguato per
   registrare i sistemi su  disco. Possibilmente un formato abbastanza
   parametrizzato in modo da risultare adeguato ai vari giochi.
DG> Intanto ideuzza per i più volenterosi: chi crea lo script Java per
DG> ridurre  un qualsiasi  sistema  On-Line ?  ho  visto qualcosa  del
DG> genere in  qualche sito  ma non ricordo  quale... solo che  li era
DG> lentissimo... noi lo dobbiamo far girare a "palla"
il che mi sembra quasi impossibile :-(
Un programma  java è  circa 10-20 volte  più lento  dell'equivalente C
(proprio  per  una questione  fisiologica)  a  meno  di utilizzare  la
Virtual Machine per  linux di "non mi ricordo chi"  che però, oltre ad
essere  la  più  veloce  attualmente,  costa la  bellezza  di  qualche
migliaio di dollari.
L'alternativa è fare un programmino che esegue SUL SERVER un programma
C, ma è  difficile convincere un provider a regalarti  i suoi cicli di
CPU... :-( e noi ne abbiamo bisogno parecchi per fare la riduzione.
DG> per il nome del progetto.... più che "ridux" direi
DG> "The_Last_System_Of_Human_Intelligence" eheheheheheh
il fatto  è che il progetto  potrebbe avere il  suo sito all'indirizzo
nome_progetto.sourceforge.net
, quindi è conveniente utilizzare un nome
alfanumerico da massimo 8 caratteri.
Ciao
Marco
-- 
Certamente le macchine possono risolvere problemi, memorizzare informazioni,
correlarle, e giocare  --  ma non con piacere.
		-- Leo Rosten

 writes:
PF> 
PF> Per quanto  riguarda la universalita',  credo che cio'  che stiamo
PF> per intraprendere si adatta bene al lotto, superenalotto e totgol,
PF> ma certamente  non all'enalotto, ne'  al totocalcio, che  hanno un
PF> modo di pronosticare completamente diverso.
in che senso?
dal punto di vista di efficienza degli algoritmi? puň darsi.
Se perň  il progetto di  base č buono,  costa molto poco  estenderlo a
tutti  i  giochi.  Io l'ho  fatto  con  un  algoritmo banale  e  posso
confermarlo.
Ho scritto un classe "combinazione"  differente per ogni gioco, con il
suo algoritmo di generazione  dell'integrale. La classe fornisce anche
un  metodo  per  contare  quanti  punti  in comune  ha  con  un  altra
combinazione.
A questo punto, per ridurre  un sistema totocalcio o uno superenalotto
basta cambiare la dichiarazione iniziale, ma si potrebbe fare una cosa
anche piů elegante e funzionale.
PF> Relativamente al totocalcio ritengo che quella decina di antichi
PF> sistemini ridotti, sia il meglio che esiste.
non lo so. Un esperto di queste cose mi ha detto un gruppo di studiosi
israeliani,  ha notato  una certa  somiglianza tra  il  problema della
riduzione e un altro problema di cui si stavano occupando. Utilizzando
i loro algoritmi hanno  polverizzato alcuni nostri sistemi considerati
imbattibili. Purtroppo non ho dettagli piů precisi.
Ciao
Marco
-- 
In politica, un'assurdita' non e' uno svantaggio.
		-- Napoleone Bonaparte

alfanumerico da massimo 8 caratteri.
si vabbeh.... era tanto per dire...
Ridux per me va bene.. magari però in italiano..... Ridotti, Ortogon,
RSystem, Matrix,
ciao
Davide

 in che senso?
1) Per lotto e derivati, immagino di poter dire al programma:
   dammi le combinazioni di 20 numeri, in ottine, garanzia del 6;
   Per il totocalcio devo invece dire: 2 triple e 6 doppie,
   garanzia del 12, o 11 (= bi-ridotto, per chi si accontenta).    
2) Il metodo di sviluppo del pronostico integrale e' certamente
   diverso.
3) Anche l'esposizione dei risultati e' diverso.
Una volta definito l'algoritmo dello sviluppo integrale,
la scelta delle combinazioni, - in questo hai ragione -, puo'
essere "assimilabile".
Per la esposizione dei risultati dobbiamo comunque fare
due diverse presentazioni:
a) per il lotto, superenalotto e totogol, i numeri da 01 a n, esposti
   in terzine, quartine, sestine, ecc.;
b) per enalotto e totocalcio, 1 x 2, esposti in colonne.  
Forse potrebbe risultare complicato tenere, o in memoria,
o su disco, delle combinazioni con 13 simboli.
In passato, molto lontano, mi sono dedicato a questo
problema, - con dei mezzi molto limitati rispetto a quelli attuali -;
ed ho ottenuto dei risultati peggiori di questi 2 classici,
che io ritengo ottimi, e a cui dovremmo tendere:
7 doppie ridotte: 16 colonne; 4 triple ridotte: 9 colonne.
.... ed avevo abbandonato.
Ciao
Pasquale

1) Scopo del programma e' quello di creare dei prototipi   
   di sistemi ridotti, in base alla scelta dei Numeri
   da mettere in gioco, Posti_sorti, minimo Garantito: N:P:G.
2) Siccome non riesco ad immaginare velocita' e occupazione,
   metterei, per il momento, questi limiti:
   Massimo dei Numeri: 32
      "     "  Posti :  8 
   Minimo garantito  : da 2 a Numero Posti  
3) Appena metteremo mano al programma, vaglieremo l'opportunita'
   di "inglobare" anche i sistemi tipo_totocalcio, le cui 
   richieste saranno: voglio "d" doppie e "t" triple, con garanzia
   del 12 oppure dell' 11; 
4) Io terrei le due cose separate, anche se il "cuore" del 
   programma, quello che dovra' scegliere le combinazioni migliori,
   puo' essere unico.
5) I risultati di ogni elaborazione, essendo dei semplici prototipi,
   saranno tenuti in dei files separati, con queste caratteristiche.
   Esempio: 15:5:3; Nome del file: Sis1553L.rid, oppure Rid1553L.sis   
1553  1  2  3  4  5  
1553  6  7  8  9 10  
1553 11 12 13 14 15  
1553  1  2  6  7 11  
1553  3  4  8  9 12  
1553  5 10 13 14 15  
1553  1  2  8 13 14  
1553  3  4  6  7 15  
1553  3  5  9 10 11  
1553  1  2  4 10 12  
1553  5  6  7  9 12  
1553  4  5  8 11 15  
1553  1  2  9 13 14  
1553  3  6  7 13 14  
1553  1  4  6  7 11  
1553  1  2  3  8 12  
6) Se il programma trova il prototipo gia' creato, non dovra' fare
   nessuna elaborazione, ma limitarsi a evidenziare questa circostanza.
7) Marco Pozzato si incarichera' di prenotare i 100Mb di sourceforge,
   il cui utilizzo, credo, dovra' essere opportunamente regolamentato.
   Immagino di mettervi dentro: il programma sorgente, il programma
   eseguibile, i prototipi che man mano vengono prodotti, non
   necessariamente on-line.
8) Il linguaggio proposto e' C, poiche' e' gratuito, e una volta
compilato
   non ha piu' bisogno di altro.
9) Chi e' il fortunato che si candida per la realizzazione ?
Ciao
Pasquale

 Pasquale
Sicuramente non io, in quanto non conosco i linguaggi di programmazione.
Però mi piacerebbe poter collaborare all'iniziativa in senso più generale,
se la cosa non disturba.
Ho poco tempo a disposizione, ma me lo gioco volentieri per una causa
comune.
Ciao!
--
Paolo Onnis
www.lottonnis.com
paolo...@lottonnis.com

 writes:
DG> 
DG> Ridux per me va bene.. magari però in italiano..... 
andiamo sul classico? un bel CONTRAHO?
DG> Ridotti, 
banale  e abusato...
DG> Ortogon,
un caso particolare...
DG> RSystem, 
hey, questo è inglese...
DG> Matrix,
forse...
E  tutti  gli  altri,  anche  se non  partecipano  direttamente,  cosa
propongono?
Ciao
Marco
-- 
Legge di Heller:
	Il primo mito del management e' che esiste.
Corollario di Johnson:
	Nessuno sa veramente mai quel che succede in un qualsiasi punto
	dell'organizzazione.

 writes:
PF> 
PF> 2) Siccome non riesco ad immaginare velocita' e occupazione,
PF>    metterei, per il momento, questi limiti:
PF>    Massimo dei Numeri: 32
PF>       "     "  Posti :  8 
PF>    Minimo garantito  : da 2 a Numero Posti  
io non porrei  limiti a priori: la potenza  di calcolo ormai raddoppia
in  meno di  un anno,  quindi  se 32  numeri sono  tanti oggi,  l'anno
prossimo il 'tanti' potrebbe essere 35 numeri.
PF> 4) Io terrei le due cose separate, anche se il "cuore" del 
PF>    programma, quello che dovra' scegliere le combinazioni migliori,
PF>    puo' essere unico.
ho commentato nel messaggio dal titolo "architettura"
PF> 5) I risultati di ogni elaborazione, essendo dei semplici prototipi,
PF>    saranno tenuti in dei files separati, con queste caratteristiche.
PF>    Esempio: 15:5:3; Nome del file: Sis1553L.rid, oppure Rid1553L.sis   
invece che affidarsi  alla sintesi di un nome  file, io preferirei una
bella intestazione all'inizio del sistema con tutti i dati che possono
sembrare più  utili e/o importanti,  comprese delle note  testuali (ad
esempio  due  sistemi  uguali,  ma  con  sviluppo  differente  avranno
proprietà  e  garanzie di  vincita  diverse  e  potrebbe essere  utile
descriverle), ad esempio:
----------------------------------------------------------------------
pronostico:     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ; 
sviluppo:       5 ;                     //cinquine
garanzia:       1 3 ;                   //1 terno
note:           1 terno con probabilità 100% all'uscita di 5 numeri
                1 terno con probabilità 10% all'uscita di 4 numeri
                .....
                ;
 
1  2  3  4  5  
6  7  8  9 10  
....
1  2  3  8 12  
----------------------------------------------------------------------
PF> 6) Se il programma trova il prototipo gia' creato, non dovra' fare
PF>    nessuna elaborazione, ma limitarsi a evidenziare questa circostanza.
ok
PF> 7) Marco Pozzato si incarichera' di prenotare i 100Mb di sourceforge,
PF>    il cui utilizzo, credo, dovra' essere opportunamente regolamentato.
URGE  stabilire un nome per il progetto, innanzitutto
PF>    Immagino  di   mettervi  dentro:  il   programma  sorgente,  il
PF>    programma  eseguibile,   i  prototipi  che   man  mano  vengono
PF>    prodotti, non necessariamente on-line.
utilizzando CVS per il controllo  di versione avremo tutto il codice e
relative   modifiche  e  aggiornamenti   in  linea.    Sarà  possibile
restringere l'accesso  al codice  in scrittura o  anche in  lettura ai
soli sviluppatori ufficiali.
Per avere  accesso alle risorse  di sourceforge è  comunque NECESSARIO
che il progetto venga rilasciato col codice sorgente.
PF> 8) Il linguaggio  proposto e' C, poiche' e'  gratuito, e una volta
PF> compilato non ha piu' bisogno di altro.
idem per il C++, ma noi cosa useremo?
PF> 9) Chi e' il fortunato che si candida per la realizzazione ?
penso  che  più   o  meno  tutti  abbiamo  poco   tempo  da  dedicare,
specialmente in un progetto  gratuito. L'importante è avere un'idea di
chi intenda fare qualcosa, nel limite delle proprie possibilità. 
Per quel che potrò, io sottoscrivo.
Ciao
Marco
-- 
Non siamo qui per caso, ma per molto meno.
		-- Giorgio Melazzi, il cronista di
		   That's Entertainment TV, "Scatafascio"

 writes:
PO> 
PO> Sicuramente non io, in quanto non conosco i linguaggi di programmazione.
ma sarai  sicuramente in grado  di dare indicazioni su  come impostare
una  interfaccia grafica  perchè sia  semplice e  intuitiva,  su quali
caratteristiche sarebbero utili oppure ancora sarai capace di scrivere
la documentazione.
Ciao
Marco
-- 
Qualunque cosa puo' essere registrata sotto la voce "miscellaneous".

 writes:
DG> 
DG> _NN_NN_NN_NN_NN_NN_NN_NN_NN
DG> 
DG> al posto di underscoreci mettiamo uno spazio, 
sicuramente,  anche più  d'uno  :-) con  una  scanf o  un  cin su  una
variabile intera interpreta  automaticamente la stringa, senza neanche
bisogno di metterci lo zero iniziale.
DG> altro.... Ogni numero si compone di due cifre con lo zero davanti per i
DG> numeretti... mi sembra abbastanza facile... Oppure possiamo scrivere le
DG> colonne in binary
tendenzialmente  mi sembra  preferibile utilizzare  un  formato testo:
permette a  chiunque di leggere,  editare e scrivere gli  sviluppi. Ad
esempio,  chi non  sa  programmare potrebbe  impegnarsi a  trascrivere
alcuni sviluppi già esistenti e particolarmente buoni. 
DG> vabbeh mettiamo  uno sviluppo massimo  per 20-25 numeri..  i tempi
DG> non sono impossibili
Pasquale diceva  che 25 numeri potevano richiedere  già qualche giorno
su un PC. E'  vero che un server (ammesso che ti  diano il permesso di
eseguire il programma) è molto più potente, ma la potenza va suddivisa
con molti altri utenti.
Ciao
Marco
-- 
I Romulani sono molto...  morali, Capitano.  Essi hanno una certezza
assoluta su cosa e' giusto e cosa e' sbagliato, chi e' un amico e chi e'
un nemico.
		-- DeSeve, "Face of the Enemy", data astrale 46519.1

 writes:
PF> 
PF> Marco Pozzato ha scritto:
PF> 1) Per lotto e derivati, immagino di poter dire al programma:
PF>    dammi le combinazioni di 20 numeri, in ottine, garanzia del 6;
PF>    Per il totocalcio devo invece dire: 2 triple e 6 doppie,
PF>    garanzia del 12, o 11 (= bi-ridotto, per chi si accontenta).    
PF> 2) Il metodo di sviluppo del pronostico integrale e' certamente
PF>    diverso.
PF> 3) Anche l'esposizione dei risultati e' diverso.
questo  è  il modo  in  cui  ho risolto  io  il  problema  per un  mio
programma in C++:
class Combinazione;
ostream& operator << (Combinazione&); // output
istream& operator >> (Combinazione&); // input
int operator &  (Combinazione& c1, Combinazione& c2); //quanti numeri in comune
Le classi dei vari giochi sono figlie di questa.
La generazione dell'integrale era affidata ad una procedura differente
per  ogni  gioco  che  riceveva  in input  un  oggetto  "Combinazione"
contenente il pronostico. Sarebbe più elegante spostare la generazione
*dentro* la classe combinazione.
Con questo approccio è  tutto completamente parametrizzato rispetto al
gioco,  quindi  l'algoritmo  di   riduzione  si  può  applicare  senza
ulteriori distinzioni  perchè i dettagli  specifici vengono mascherati
all'interno degli operatori di IO e di confronto.
Con gli stream operator puoi leggere e scrivere lo standard io, i file
o le stringe  indistintamente: 3 piccioni con una  fava. Ovviamente la
cosa si complica dovendo fare un  front end grafico (e si dovrà fare),
ma basterà fare  dei componenti visuali differenziati in  base al tipo
di combinazione.
PF> Per la esposizione dei risultati dobbiamo comunque fare
PF> due diverse presentazioni:
questo,  IMHO, è  un  passo ulteriore  e  riguarda l'architettura  che
vogliamo  adottare:   un  progetto   monolitico  o  qualcosa   di  più
flessibile? 
Io credo  che dovremmo  tenere ben separate  la parte di  calcolo (che
effettua   la  riduzione   vera   e  propria,   cioè   il  back   end)
dall'interfaccia grafica (il front end), per due ragioni:
1) avremmo due  blocchi abbastanza indipendenti, quindi  più facili da
   sviluppare, testare.
2) lo sviluppo potrebbe avvenire in  parallelo: un gruppo si dedica al
   'motore' (C o C++?),  mentre l'altro si dedica all'interfaccia (VB,
   Delphi o addirittura Java)
Una volta  fissate le  modalità di interazione  tra back e  front end,
ognuno dei  due può  essere rivoltato come  un guanto  senza impattare
sull'altro. Potremmo avere anche più  di un front end, a seconda delle
esigenze,  oppure  ancora il  back-end  potrebbe  essere integrato  in
programmi più generali della 'sola' riduzione. 
PF> Forse  potrebbe risultare complicato  tenere, o  in memoria,  o su
PF> disco, delle combinazioni con 13 simboli.
affatto!
dipende dalla rappresentazione che utilizzi.
ad esempio: 
- una colonna lotto  potrebbe essere "1 5 50 78 15  32", ma in memoria
  verrebbe  rappresentata come  array di  caratteri o,  meglio ancora,
  come vettore  di 90 bit  (per rappresentare combinazioni  di diverse
  lunghezze con un'unica struttura dati), per un totale di 12 byte.
- una colonna totocalcio può essere  scritta in molti modi. A me, come
  rappresentazione sintetica,  ma pur sempre testuale,  piace un simil
  NTP,  cioé: il simbolo  "1" *pesa*  1, il  "2" pesa  2 e  l'"X" pesa
  4. Facendo la somma si ottiene  il risultato singolo, la doppia o la
  tripla. Si ottiene una stringa di 13 caratteri, ma in memoria occupa
  39 bit=5 byte.
La  rappresentazione  mediante vettori  di  bit,  unita  a tabelle  di
look-up permette di effettuare confronti  tra le colonne in modo molto
veloce ed  efficiente. Giusto a titolo di  esempio: l'algoritmo banale
di riduzione ha  impiegato 36 ore sul mio 486DX2  66MHz per ridurre il
90 numeri supernalotto a garanzia del 3.
Ciao
Marco
-- 
E' giustissimo scagliare la prima pietra, se ne hai qualche altra nelle
tasche.
		-- Bob Kaufman

90 numeri supernalotto a garanzia del 3.
E non e' affatto male.
Per curiosita', quante colonne sono venute fuori?
--
Marco Fabiani
in...@fabisoft.it
www.fabisoft.it
www.totoclub.com

... ecco qua che hai trovato gli amici :-)
Ciao
Pasquale

> 90 numeri supernalotto a garanzia del 3.
MF> 
MF> Per curiosita', quante colonne sono venute fuori?
se non  erro si  trattava di 3738  colonne, ma  non ho tenuto  il file
colonnare.  Come  già detto si  trattava dell'algoritmo banale  che si
limita a generare le colonne e man mano le scarta se sono già coperte.
Un programmuzzo  scritto in  C++, parametrico sul  tipo di  gioco, nel
modo che ho spiegato in un altro messaggio.
Ciao
Marco
-- 
Eppur non si muove...

 
Io mi nutro di pane&cobol. 
Ho intenzione di imparare "C" e "C++", e qualche altra cosa, 
pero' passera' qualche anno prima di usarli correntemente.
Il mio apporto puo' essere nel controllo dei risultati, oltre che
nel suggerire, se serve, qualche tecnica di programmazione.
Ciao
Pasquale

 writes:
PF> 
PF> a) anch'io ho immaginato di rappresentare la varie combinazioni
PF>    in bit accesi o spenti; quindi 32 numeri possono esseri tenuti 
PF>    in 4 bytes;
mumble...
quindi immagini di utilizzare sempre i primi 32 numeri e di rimapparli
poi sul pronostico effettivo.
PF> c) per quanto possibile, bisogna tenere tutto lo sviluppo in memoria, 
PF>    per velocizzare l'esecuzione
ok
PF> f) ... comincio a pensare che anche 32 sia troppo ... 
può  darsi,  ma  quanta  ram  ha  il  tuo PC  oggi?  e  fra  un  anno?
riprogettiamo da capo tutto il programma? 
Io eviterei un limite 'fisico' a priori e lascierei aperta la porta ai
90 numeri, anche perchè non potremo forse fare 40 numeri in ottine, ma
sicuramente 45 in cinquine.
PF> ogni colonna,  che e'  una sequenza di  13 caselle,  dove ciascuna
PF> puo' assumere  il valore di 1,  2, 0(=X), e  puo' rappresentata da
PF> essere un numero decimale,  convertito in "trinario", e viceversa,
PF> forse occupa meno di 5 byte.
è esattamente quello che dicevo, col meccanismo di pesi abbiamo:
1       -> 1
X       -> 4
2       -> 2
1X      -> 1+4=5
12      -> 1+2=3
X2      -> 4+2=6
1X2     -> 1+4+2=7
per  ogni partita abbiamo  8 simboli  (da 0  a 7),  quindi 3  bit. Una
combinazione totocalcio sta in 39 bit.
PF> Un  nome  simbolico,  sintetico,   ed  univoco,  serve  al  nostro
PF> programma per  poterne verificare, - piu' facilmente,  credo -, la
PF> presenza o meno nella cartella di lavoro.
bho, può darsi
PF> Le righe di commento le dovremmo far cominciare con: "Comm, oppure
PF> "Rem", oppure con un semplice "*"; 
perchè?  per come le intendo  io le "proprietà" del sistema non devono
essere  dei  commenti,  ma  parte integrante  delle  informazioni  sul
sistema stesso. Proprio perchè  potremmo avere molti sistemi identici,
ma con sviluppi  differenti che danno garanzie di  tipo differente una
stringa  sintetica  (tra  cui   il  nome  file)  potrebbe  non  essere
sufficiente nel futuro. Al  limite si potrebbe usare un identificativo
per  separare l'intestazione  dallo sviluppo  effettivo,  ma qualunque
programma dovrebbe leggere le proprietà per sapere a cosa si riferisce
lo sviluppo.
PF> forse C++ va bene; lasciamolo decidere a chi lo dovra' realizzare
io preferisco C++
PF> Io mi nutro di pane&cobol. 
nessuno è perfetto :-)))))
Ciao
Marco
-- 
- Cosa fa un cavallo quando ha l'alito pesante?
- Giu'...menta!
		-- Da it.hobby.umorismo

 
Ok, vada per il solo identificativo tra le proprieta' e lo sviluppo,
pero' lasciamo, - per_futuri_utilizzi (fidati ;-) -, in testa ad ogni
riga del sistema, la base di partenza, es. L1553, oppure piu'
esplicativo, o addirittura lo stesso nome del file. 
Ciao
Pasquale

 writes:
PF> 
PF> il massimo numero  che puo' venir fuori e'  (3^13)-1 = 1594322, il
PF> quale e' contenuto in 3 byte.
certo. Una codifica di questo tipo sarebbe anche relativamente banale,
però  inefficiente,  credo.  Per  succhiare  al  massimo sullo  spazio
occupato   da   una   combinazione  occorrerebbe   memorizzare   tutto
l'integrale  (in  modo cristiano)  in  un  array  e riferirsi  a  alle
combinazioni  usando  l'indice  corrispondente nell'array.   A  questo
punto,  però non  vedo il  risparmio  e una  buona soluzione  potrebbe
essere  di memorizzare  la singola  combinazione, invece  che  anche i
pronostici con doppie e triple:  si potrebbero usare 2 bit (4 simboli,
sprecandone  1)   per  ogni  partita,   ma  arrivamo  a  26   bit  per
combinazione, cioè comunque 4 byte,  quindi non penso che il risparmio
valga la pena.
PF> Ok,  vada  per il  solo  identificativo  tra  le proprieta'  e  lo
PF> sviluppo, pero' lasciamo, -  per_futuri_utilizzi (fidati ;-) -, in
PF> testa ad  ogni riga del sistema,  la base di  partenza, es. L1553,
PF> oppure piu' esplicativo, o addirittura lo stesso nome del file.
non capisco, ma mi adeguo :-)
Ciao
Marco
-- 
- Cosa ha ricevuto in dono Topolino a Natale?
- Un orologio di Dan Quayle.

perdonatemi se mi intrometto :-))
ma il problema reale qual'è ? cioè voglio dire si parla di contenere lo
spazio ma il motivo qual'è ? forse vogliamo mettere sul sito web un'applet
che riduca i sistemi ? in tal caso sarebbe bene far scaricare un prog di
pochi KB all'utente in modo da sfruttare lo spazio e la memoria dell'HD
dell'utente che nel frattempo è collegato al server il quale a sua volta
elabora il tutto con un normale DO UT DES... praticamente il solito magna
magna
ciao
Davide
NB
le colonne totocalcio si possono salvare con gli standard ntp, sch. Le
colonne con numeri si possono salvare con pochi byte in migliaia di modi...

 writes:
DG> 
DG> cioč  voglio dire si  parla di  contenere lo  spazio ma  il motivo
DG> qual'č ?  
che  un   algoritmo  intelligente  di  riduzione,   per  questioni  di
efficienza,  ha bisogno di  tenere in  memoria lo  sviluppo integrale,
cioč tanti bei MB di ram, in certi casi.
DG> forse  vogliamo  mettere  sul  sito  web un'applet  che  riduca  i
DG> sistemi?
no, non č fattibile nč sarebbe lontanamente efficiente.
DG> in  tal  caso sarebbe  bene  far scaricare  un  prog  di pochi  KB
DG> all'utente in  modo da  sfruttare lo spazio  e la  memoria dell'HD
DG> dell'utente che nel frattempo č collegato al server il quale a sua
DG> volta elabora 
il server non si puň permettere  di buttare cosě tanti cicli ci CPU, a
meno che  tu non  voglia mettere  un tuo dual  PIII in  housing presso
qualche provider... :-)
Ciao
Marco
-- 
"Quando si  ama davvero, le  parole non servono", disse  il pesciolino
alla pesciolina.
		-- Da it.hobby.umorismo

qualche provider... :-)
ehhhh
allora facciamo scaricare l'exe all'utente... pochi KB + le runtime
necessarie
ciao
Davide

> no, non è fattibile nè sarebbe lontanamente efficiente.
DG> 
DG> 
DG> come non  è fattibile ??  tutto se pò  fa... tra l'altro  credo di
DG> aver visto  qualcosa del genere  su qualche sito.. ma  non ricordo
DG> quale
si parlava di applet, quindi java...
già l'efficienza è un problema,  se poi facciamo il programma in java,
buonanotte  ai suonatori:  viene sicuramente  elegante,  portabile, ad
oggetti, ma stai dei giorni anche per sistemi semplici.
L'alternativa è fare in modo che il programma bello ottimizzato 'giri'
sul server:  il programma ciuccerebbe  molte delle risorse  del server
(memoria, cicli  di CPU) che  sono oltretutto condivise con  gli altri
utenti  che stanno  accedendo. In  pratica si  inchioda per  il troppo
carico. Quindi, finisce che se ti  hanno permesso di far girare i TUOI
programmi sul server, ti disabilitano subito.
DG> allora  facciamo  scaricare  l'exe  all'utente... pochi  KB  +  le
DG> runtime necessarie
pochi o tanti KB di programma lo sapremo quando sarà finito
Al limite si potrebbe lasciare sul server i sistemi già calcolati.
Ti sei registrato su 
sourceforge.net
? 
Ti sei iscritto alla mailing list?
Ciao
Marco
-- 
Regola di Barach:
        Un alcolista e' una persona che beve piu' del suo psicanalista.

Ti sei iscritto alla mailing list?
sourceforge si, la ML credo di no....
ciao
Davide

 writes:
DG> 
DG> sourceforge si, la ML credo di no....
DG> 
fammi  sapere con  login ti  sei registrato,  altrimenti non  ti posso
aggiungere al gruppo del progetto.
-- 
BTW: ho un nome migliore per il software... Microsoft Internet Exploder.
		-- George Bonser