L
LuigiB
Guest
Allora proviamo ad imbarcarci nell'impresa , è previsto per ora che il progetto venga seguito a 4 mani ma non disdegnamo la collabaorazione degli altri.
Ho creato questo thread per discutere di problematiche tecniche ai fini della realizzazione del progetto.
mi scuso in anticipo per la lunghezza di questo primo post e per l'eventuale noiosità ...maq prima di agire bisogna parlare.
Lo stesso twinbasic è basato su tecnologia COM io direi di creare come si era ipotizzato anche noi un componente COM che sarà quello istanziato dai programmi (script) che lo useranno e che conterrà le funzioni di scripting.
Cosi facendo (creare il componente com) gli script potranno girare da qualsiasi host in grado di gestire COM, ad esempio Excel.
Naturalmente è preferibile creare i propri script in twinbasic piuttosto che in excel ma è comunque giusto sottolineare che con questa impostazione la cosa è possibile.
Internamente questo componente per lo scripting dovrà essere suddiviso in vari moduli , ovvero ci saranno apposite classi per gestire i vari aspetti delle esigenze operative
Il primo componente da realizzare sarà senz'altro una classe Archivio , che si occupi della lettura/modifica/cancellazione/inserimento delle estrazioni e che metta a disposizione degli altri moduli l'archivio delle estrazioni.
Quindi per poter iniziare a fare qualcosa bisogna discutere alcuni aspetti
Come base dati la cosa migliore è usare i file di testo lo abbiamo già detto, tuttavia dobbiamo decidere se i record che compongono il file debbano avere delle
caratteristiche di formattazione tali da renderli omogenei ovvero tutti della stessa lunghezza , oppure se vogliamo rinunciare a questa caratteristica.
Per esempio l'archivio potrebbe contenere righe di lunghezza diversa pur avendo la stessa quantità di estratti , questo potrebbe capitare se in una riga i numeretti
vengano formattati con lo 0 e in un'altra riga invece no.
Nel primo caso la lettura dell'archivio sarebbe più rigida , modificarlo a mano è rischioso perche si potebbe inserire un record di lunghezza differente,
in compenso si avrebebro diversi vantaggi dati dal fatto che avendo record a lunghezza fissa è possibile calcolare gli offset per leggere uno specifico blocco di estrazioni.
Io propenderei per questa soluzione
Comunque sapere come sarà fatta la base dati è indispensabile per poter scrivere le funzioni che la gestiscono.
Tenendo in considerazione la versatilità sui giochi che vogliamo ottenere il record del file di testo con le estrazioni dovrebbe avere una sequenza prevista dei valori che lo compongono , quando il tipico valore non esiste lo si lascia vuoto .
Ad esempio nel lotto abbiamo la data estrazione , l'indice annuale e quello mensile , nel 10 e lotto 5M si aggiunge l'ora e l'indice giornaliero.
Il record del nostro file dovra prevedere sempre tutti i valori possibili nelle posizioni previste , se questi valori non ci sono per quel tale archivio dovrà essere lasciato vuoto il campo ma assolutamente non ometterlo
Quindi per esempio un ipotetico record potrebbe avere questa sequenza
DataOra;IndiceAnnuale;IndiceMensile;IndiceGiornaliero;Num1;....;NumN
tutti i valori di ciascun campo devono essere formattati affinche il record finale sia sempre della stessa lunghezza in byte.
Spaziometria era nato inizialmente per il lotto e solo a posteriori negli script sono state inserite le funzioni per altri giochi
questo ha fatto si che ci siano funzioni quasi con lo stesso nome che si riferiscono a giochi e quindi archivi diversi.
Per esempio da Estratto derivano le relative EstrattoDL , EstrattoFT ,EstrattoSE , spaziometria internamente ha archivi con strutture diverse una per ciascun gioco.
Dovendo rispettare un requisito di versatilità non si possono prevedere funzioni a priori , la funzione Estratto (come tutte le altre) ad esempio sarà sempre la stessa a prescindere dal tipo di archivio collegato.
Al contrario di spaziometria qui è necessario usare una struttura dati unica che sia in grado di contenere i numeri di un'estrazione
qualsiasi , da lotto ,al superenalotto ,al 10elotto e via dicendo , oltre ai numeri le informazioni di riferimento per l'estrazionew come data ,numroannuale , mensile e perfino orario come nel caso del 10elotto 5m
Dobbiamo pensare al perimetro che possono occupare i dati di estrazioni di giochi differenti al fine di vedere come creare una struttura dati che sia valida per tutti i giochi
Per esempio il lotto ha 11 ruote con 5 numeri ciascuna , gli altri giochi hanno per cosi dire "una sola ruota" magari con 20 numeri come il 10 e lotto.
Internamente per esperianza posso dire che se l'estrazione è rappresentata da un oggetto come una classe e l'archivio fosse costituito da una collection che contiene le istanze di ciascuna classe estrazione il tutto sarebbe piu ottimizzato come occupazione ma anche più lento , quindi per contenere internamente le estrazioni è meglio pensare ad una struttura dati e ad un array di quel tipo dati da noi definito , è meglio usare gli UDT (User defined type)
Ora per problematiche tecniche non è possibile definire a posteriori il rank degli array dichiarati in un UDT quindi la type definition dovrà considerare per l'appunto che un'estrazione possa contenere anche a sua volta 11 estrazioni diverse con 5 numeri oopure una sola estrazione con 20 numeri , la stessa struttura dati deve poter contenere tutte e due le tipologie , è chiaro che un record di questo tipo possa sprecare un po' piu di memoria ma non siamo in c++ e non credo che qui sia possibile fare un tipo dati che si comporta in modo differente a seconda dei casi per ottenere un'ottimizzazione dello spazio occupato.
Quindi per non sprecarne troppa di memoria dobbiamo imporre comunque dei limiti , io direi 11 ruote e 30 numeri per ruota massimo.
Questo vuol dire che ipotetici giochi che non rientrano in queste caratteristiche non possano essere gestiti. Comunque mi sembrano abbastanza larghe da coprire tutti i giochi che ha gia spaziometria.
come struttura udt io avrei pensato a questo , non so se a Rooke vien in mente un sistema piu efficente che occupi meno spazio,
L'idea sarebeb di avee in memoria non appena si istanzia la classe di script l'intero archivio delle estrazioni che altro non è che un array del tipo struct_estrazione.
Ho creato questo thread per discutere di problematiche tecniche ai fini della realizzazione del progetto.
mi scuso in anticipo per la lunghezza di questo primo post e per l'eventuale noiosità ...maq prima di agire bisogna parlare.
Lo stesso twinbasic è basato su tecnologia COM io direi di creare come si era ipotizzato anche noi un componente COM che sarà quello istanziato dai programmi (script) che lo useranno e che conterrà le funzioni di scripting.
Cosi facendo (creare il componente com) gli script potranno girare da qualsiasi host in grado di gestire COM, ad esempio Excel.
Naturalmente è preferibile creare i propri script in twinbasic piuttosto che in excel ma è comunque giusto sottolineare che con questa impostazione la cosa è possibile.
Internamente questo componente per lo scripting dovrà essere suddiviso in vari moduli , ovvero ci saranno apposite classi per gestire i vari aspetti delle esigenze operative
Il primo componente da realizzare sarà senz'altro una classe Archivio , che si occupi della lettura/modifica/cancellazione/inserimento delle estrazioni e che metta a disposizione degli altri moduli l'archivio delle estrazioni.
Quindi per poter iniziare a fare qualcosa bisogna discutere alcuni aspetti
Come base dati la cosa migliore è usare i file di testo lo abbiamo già detto, tuttavia dobbiamo decidere se i record che compongono il file debbano avere delle
caratteristiche di formattazione tali da renderli omogenei ovvero tutti della stessa lunghezza , oppure se vogliamo rinunciare a questa caratteristica.
Per esempio l'archivio potrebbe contenere righe di lunghezza diversa pur avendo la stessa quantità di estratti , questo potrebbe capitare se in una riga i numeretti
vengano formattati con lo 0 e in un'altra riga invece no.
Nel primo caso la lettura dell'archivio sarebbe più rigida , modificarlo a mano è rischioso perche si potebbe inserire un record di lunghezza differente,
in compenso si avrebebro diversi vantaggi dati dal fatto che avendo record a lunghezza fissa è possibile calcolare gli offset per leggere uno specifico blocco di estrazioni.
Io propenderei per questa soluzione
Comunque sapere come sarà fatta la base dati è indispensabile per poter scrivere le funzioni che la gestiscono.
Tenendo in considerazione la versatilità sui giochi che vogliamo ottenere il record del file di testo con le estrazioni dovrebbe avere una sequenza prevista dei valori che lo compongono , quando il tipico valore non esiste lo si lascia vuoto .
Ad esempio nel lotto abbiamo la data estrazione , l'indice annuale e quello mensile , nel 10 e lotto 5M si aggiunge l'ora e l'indice giornaliero.
Il record del nostro file dovra prevedere sempre tutti i valori possibili nelle posizioni previste , se questi valori non ci sono per quel tale archivio dovrà essere lasciato vuoto il campo ma assolutamente non ometterlo
Quindi per esempio un ipotetico record potrebbe avere questa sequenza
DataOra;IndiceAnnuale;IndiceMensile;IndiceGiornaliero;Num1;....;NumN
tutti i valori di ciascun campo devono essere formattati affinche il record finale sia sempre della stessa lunghezza in byte.
Spaziometria era nato inizialmente per il lotto e solo a posteriori negli script sono state inserite le funzioni per altri giochi
questo ha fatto si che ci siano funzioni quasi con lo stesso nome che si riferiscono a giochi e quindi archivi diversi.
Per esempio da Estratto derivano le relative EstrattoDL , EstrattoFT ,EstrattoSE , spaziometria internamente ha archivi con strutture diverse una per ciascun gioco.
Dovendo rispettare un requisito di versatilità non si possono prevedere funzioni a priori , la funzione Estratto (come tutte le altre) ad esempio sarà sempre la stessa a prescindere dal tipo di archivio collegato.
Al contrario di spaziometria qui è necessario usare una struttura dati unica che sia in grado di contenere i numeri di un'estrazione
qualsiasi , da lotto ,al superenalotto ,al 10elotto e via dicendo , oltre ai numeri le informazioni di riferimento per l'estrazionew come data ,numroannuale , mensile e perfino orario come nel caso del 10elotto 5m
Dobbiamo pensare al perimetro che possono occupare i dati di estrazioni di giochi differenti al fine di vedere come creare una struttura dati che sia valida per tutti i giochi
Per esempio il lotto ha 11 ruote con 5 numeri ciascuna , gli altri giochi hanno per cosi dire "una sola ruota" magari con 20 numeri come il 10 e lotto.
Internamente per esperianza posso dire che se l'estrazione è rappresentata da un oggetto come una classe e l'archivio fosse costituito da una collection che contiene le istanze di ciascuna classe estrazione il tutto sarebbe piu ottimizzato come occupazione ma anche più lento , quindi per contenere internamente le estrazioni è meglio pensare ad una struttura dati e ad un array di quel tipo dati da noi definito , è meglio usare gli UDT (User defined type)
Ora per problematiche tecniche non è possibile definire a posteriori il rank degli array dichiarati in un UDT quindi la type definition dovrà considerare per l'appunto che un'estrazione possa contenere anche a sua volta 11 estrazioni diverse con 5 numeri oopure una sola estrazione con 20 numeri , la stessa struttura dati deve poter contenere tutte e due le tipologie , è chiaro che un record di questo tipo possa sprecare un po' piu di memoria ma non siamo in c++ e non credo che qui sia possibile fare un tipo dati che si comporta in modo differente a seconda dei casi per ottenere un'ottimizzazione dello spazio occupato.
Quindi per non sprecarne troppa di memoria dobbiamo imporre comunque dei limiti , io direi 11 ruote e 30 numeri per ruota massimo.
Questo vuol dire che ipotetici giochi che non rientrano in queste caratteristiche non possano essere gestiti. Comunque mi sembrano abbastanza larghe da coprire tutti i giochi che ha gia spaziometria.
come struttura udt io avrei pensato a questo , non so se a Rooke vien in mente un sistema piu efficente che occupi meno spazio,
L'idea sarebeb di avee in memoria non appena si istanzia la classe di script l'intero archivio delle estrazioni che altro non è che un array del tipo struct_estrazione.
!!!
