Newsgroup: it.hobby.scacchi
Titolo: Tablebase: Alcuni chiarimenti!

Da alcuni messaggi ricevuti in questi giorni, mi sembra che ci siano in giro un
po' di idee confuse a proposito delle famose "tablebase" dei finali e quindi
provo a chiarire qualche punto fondamentale!
1. Le "tablebase" sono file che contengono tutte le posizioni possibili per
un determinato tipo di finale, in modo che il computer, consultandole, possa
dare una risposta immediata ed esatta sull'andamento del finale stesso, non
a caso in passato venivano chiamate "L'Oracolo"!
Usando le tablebase per analizzare una posizione, si possono avere risposte
del tipo "Matto in 40"!
Per ora esistono le tablebase per TUTTI i finali di 3, 4, e 5 pezzi (COMPRESI i
Re!) e per qualche finale di 6 pezzi.
2. Esistono fondamentalmente due tipi di tablebase:
A) Il tipo "Thompson", detto anche "Distance to change", indica la distanza
alla quale avverra' un cambiamento radicale di posizione.
B) Il tipo "Nalimov", detto anche "Distance to mate", indica la distanza della
posizione dal matto per una delle due parti.
Un esempio:
Bianco: Re2 Pd2
Nero Rf6
Le tablebase "Thompson" mi danno come risposta: 
"1.Rd3  P13
1. d4 M0
1. d3 M0 ecc. ecc.
che vuol dire, in parole povere, che con la mossa 1.Rd4 dopo 13 mosse si
verifica un cambiamento drastico, radicale, mentre con le altre mosse si patta!
Le tablebase "Nalimov" mi danno come risposta:
1. Rd3 #20
2. d4 M0
3. d3 M0 ecc. ecc.
che vuol dire che con 1.Rd3 il Bianco da' matto in 20, mentre con le altre mosse
patta!
Come vedete, sono piu' facili da capire le tablebase "Nalimov"!
3. Le tablebase di tipo "Thompson", diffuse su Internet tempo fa e poi dalla
ChessBase su 4 CD, ora vengono utilizzate in pratica SOLO da ChessBase.
Infatti ChessBase ha una sua DLL (Cdrom400.eng per CB7, Cdrom110.dll per CB6)
che consente l'accesso diretto a questi file dei finali.
In CB imposto un finale di quelli contenuti nei CD, poi vado alla lista dei
motori e faccio partire il comando "Start CD-ROM 1-4" e CB mi dice quale
CD devo inserire (1-4). Dopo l'inserimento del CD, CB lo legge e mi da' il
"responso"!
Fritz 5.16 e 5.32 utilizzano le tablebase "Thompson" (credo anche Junior 5, ma
non ne sono sicuro!) e ne hanno alcune contenute nei rispettivi CD. 
Pero' e' molto difficile usare i 4 CD di Thompson con Fritz,
perche' NON dispone di un "CD selector" come ChessBase e quindi bisognerebbe
PRIMA inserire il CD giusto e POI impostare la posizione e far partite
l'analisi.
Devo confessare che non sono mai riuscito a far funzionare i CD di Thompson
con Fritz, mentre funzionavano bene quei 6 o 7 finali contenuti nei CD di Fritz!
4. Ormai TUTTI i programmi ChessBase utilizzano le tablebase "Nalimov", di cui
una buona serie di file (tutti i finali di 3 o 4 pezzi e alcuni di 5 pezzi) sono
inclusi su tutti i CD ChessBase.
Queste tablebase sono scaricabili dal sito di Bob Hyatt:
ftp://ftp.cis.uab.edu/pub/hyatt/TB
ma quelle fino a 5 pezzi occupano in tutto ben 6 GB!!!
C'e' da dire che un progresso e' stato gia' fatto, perche' le tablebase
originali di Nalimov occupavano ben 21 GB e quelle che si usano adesso
sono di formato compresso!!!!
Attualmente possono accedere a queste tabelbase (nell'ambito dei prodotti CB):
Fritz 6
Hiarcs 7.32
Nimzo 7.32
Crafty (dalla versione 16.15 in poi)
Doctor 3 (pero' solo  a partire dalla versione aggiornata contenuta sul CD 
di Fritz 6).
4. Nimzo 7.32 e' un po' una sorpresa, perche' oltre a usare le tablebase
"Nalimov", ne usa anche un altro tipo che hanno il formato file, per esempio,
"kbbk_btm.ncd".
Durante l'installazione Nimzo 7.32 si crea una sottocartella, nella cartella
Engines, chiamata "NzEndGam", in cui inserisce le sue tablebase.
La cosa stupefacente e' che queste tablebase occupano solo
circa 11 MB!
Mi sono riproposto da tempo di scoprire le caratteristiche di questo
formato e come mai i file sono cosi' "piccoli"!
Credo che per ora basti!
A risentirci
Ivo

 formato e come mai i file sono cosi' "piccoli"!
Ti ringrazio per avere illustrato così bene le differenze, che non conoscevo, tra i
due tipi di tablebase.
Provo ad immaginare il primo punto: perché Thompson dà una risposta meno
significativa dal nostro punto di vista rispetto a Nalimov?
Io suppongo che il motivo risieda nel fatto che già alcuni finali a 5 pezzi
potrebbero avere un numero di mosse per vincere che supera 128. Non lo so con
certezza perché il mio PC non è in grado di generarle, ma questo è sicuro quando i
pezzi sono almeno 6. Allora se io dedico un byte ad ogni posizione, in tale byte
dovrò codificarvi il numero di mosse per vincere o per perdere, ad esempio 128+127,
lasciando una posizione alla patta.
Se si supera 128 mosse per vincere/perdere si devono usare 2 byte raddoppiando lo
spazio occupato. Quindi con il sistema Thompson vi sono meno rischi di dover
codificare numeri superiori a 128 perché il "cambiamento radicale" certamente accade
prima del matto. Mi sembra che con questa logica, indipendentemente dal discorso sul
cambiamento radicale, si può risolvere il problema da me citato, rinunciando però a
conoscere il numero di mosse necessario a dare il matto, a cui in genere si è
interessati.
Sai qualcosa in proposito?
Per quanto riguarda il secondo punto faccio la seguente supposizione:
Le tablebase servono ad un programma in 2 diverse situazioni:
1. Quando il numero attuale di pezzi è maggiore del numero di pezzi per il quale si
possiedono le tablebase.
In questo caso io posso costruire tablebase in cui per ad ogni posizione dei pezzi
corrispondono 2 bit, che contengono l'informazione di vittoria, sconfitta o patta.
Se mi limitassi a cercare solo la vittoria potrei avere un solo bit (vittoria, non
vittoria).
Non mi interessa disporre dell'informazione relativa al numero di mosse perché il
programma nel corso della ricerca della mossa migliore, quando perviene ad una
situazione rientrante in una tablebase, ha unicamente interesse al risultato che
corrisponde al punteggio da prendere in considerazione per quel nodo terminale.
Quello che è importante è disporre della massima velocità in quanto dobbiamo
esaminare il numero più grande possibile di alternative e quindi dovremmo tenere in
memoria quante più tablebase sia possibile, per evitare di caricarle da disco tutte
le volte che servono.
2. Quando la partita è entrata in un finale contenuto nelle tablebase.
In questo caso il numero delle mosse per vincere è fondamentale perché si avrebbe il
rischio di fare una mossa che ci allontana dalla vittoria invece di avvicinarci. Qui
si deve tenere in memoria solo la tablebase che interessa in quel momento ma il
tempo di calcolo è praticamente trascurabile. Peraltro la tablebase potrebbe anche
non essere caricata in memoria ma rimanere su disco in quanto è necessario fare un
numero assai limitato di accessi. Se la tablebase è compressa, forse è necessario
seguire il primo metodo decomprimendo la tablebase durante il caricamento.
Detto questo, è probabile che nel caso delle tablebase ridotte per Nimzo 7.32 ci si
trovi nel primo caso e non nel secondo, in cui si userebbero invece quelle di
Nalimov. Si avrebbe quindi già una riduzione per un fattore 4. Ma non basta: se non
è richiesto il numero di mosse è possibile realizzare straordinarie compressioni di
spazio, come è stato fatto presso l'Università di Alberta nel programma Chinook per
la Dama. Guarda se i file tipo "kbbk_btm.ncd" di cui parli hanno dei file indice
ausiliari, che invece non sono necessari per le tablebase di Nalimov.
Potrebbe essere questa la spiegazione.
Ciao
Guido
--
Posted from 
smtp2.libero.it
 [193.70.192.52]
via Mailgate.ORG Server - 
http://www.mailgate.org


Non ci sono file indici ausiliari, ma sicuramente le informazioni di queste
tablebase sono molto ridotte, perche' occupano troppo poco spazio.
Ci sono anche dei file del tipo: "kbpkpblo_btm.ncd", dove quel "blo" forse
sta per "block", ad indicare che le informazioni delle tablebase sono
divise a "blocchi" o qualcosa del genere, per diminuirne le dimensioni!
Per ora non ne so di piu'!
Saluti
Ivo