Wikipedia

Tablebase

Negli scacchi, una tablebase è un database di tutte le posizioni possibili in un finale. Grazie ad esse è possibile conoscere il risultato finale di una data posizione (vittoria del Bianco, del Nero o patta) e anche il numero delle mosse necessarie per la vittoria nel caso che i due giocatori giochino nel miglior modo possibile. Le tablebase indicano inoltre le migliori mosse possibili in ogni posizione.

La tipica interfaccia di una tablebase: per ogni mossa del Bianco è indicato il numero di mosse necessario per vincere.

Attualmente sono state risolte tutte le posizioni in cui sono presenti sulla scacchiera sette o meno pezzi (inclusi i due re). La soluzione di queste posizioni ha migliorato la comprensione dei finali: alcune posizioni che venivano considerate patte sono state invece risolte come vittorie, in alcuni casi con sequenze di più di cento mosse, molto al di là della possibilità di calcolo di un umano o di un motore scacchistico. Le tablebase hanno inoltre facilitato la composizione degli studi.

Le tablebase sono generate attraverso analisi retrograda, calcolando all'indietro da ogni posizione possibile di scacco matto o di stallo.

Storia e contesto modifica

In linea di principio, è possibile risolvere ogni gioco che non prevede scelte casuali e in cui lo "stato del gioco" è noto ad ogni scelta, cioè stabilire quale dei giocatori ha la possibilità, muovendo nel modo migliore possibile, di vincere (oppure se il gioco finirà in un pareggio). Alcuni semplici giochi, come forza quattro, il tris o la dama inglese, sono stati risolti (il primo è vinto per il giocatore che inizia, gli altri due sono pareggi), mentre altri giochi, come il go e gli scacchi, sono troppo complessi per poter attualmente valutare tutte le possibilità e tutte le posizioni. Per ovviare a questo problema, si è cominciato con lo studiare posizioni in cui è ridotta la grandezza della scacchiera (come per il go), oppure in cui sono presenti pochi pezzi sulla scacchiera (ad esempio negli scacchi).

Uno dei primi campi di applicazione dell'intelligenza artificiale furono gli scacchi: dopo esser cominciata negli anni Trenta, nel 1949 Claude Shannon propose dei criteri per valutare delle mosse, mentre due anni più tardi Alan Turing creò un primitivo motore scacchistico che assegnava dei valori al materiale e alla mobilità dei pezzi.[1] Nel tempo, nonostante il loro miglioramento, i software che giocavano a scacchi esibivano sempre una debolezza nel finale; i programmatori aggiunsero così degli elementi euristici per rafforzarli, ad esempio che il re si dovesse muovere verso il centro della scacchiera.[2]

Nel 1965, Richard Bellman propose la creazione di un database per risolvere i finali di scacchi e di dama inglese usando l'analisi retrograda.[3][4] Anziché calcolare le mosse a partire da una data posizione, si sarebbe dovuta analizzare la posizione all'indietro, partendo dalle posizioni finali, cioè da quelle di scacco matto o di stallo. In questo modo un motore non avrebbe più avuto la necessità di analizzare le posizioni di un finale, perché avrebbe avuto in memoria la miglior mossa possibile.

Nel 1970 Thomas Ströhlein pubblicò una tesi di dottorato[5] in cui analizzava alcuni finali (re e donna contro re, re e torre contro re, re e pedone contro re, donna contro torre, torre contro pezzo minore).[6][7] Ken Thompson e altri estesero in seguito le tablebase fino a coprire tutti i finali con quattro e cinque pezzi.[8][9] Nel 1995 Lewis Stille pubblicò una tesi con l'analisi di alcune posizioni con sei pezzi.[10] Contributi più recenti sono venuti, tra gli altri, da Eugene Nalimov (che dà nome alle popolari tablebase di Nalimov), Eiko Bleicher (che ha adattato il concetto delle tablebase ad un programma chiamato "Freezer"), Guy Haworth, Marc Bourzutschky e Yakov Konoval (questi ultimi due hanno collaborato all'analisi di alcuni finali con sette pezzi).

L'analisi di tutti i finali con sei o meno pezzi è stata completata nel 2006, sebbene non siano state prodotte quelle relative alle posizioni con cinque pezzi contro il solo re, in quanto il risultato è ovvio, mentre le tablebase a sette pezzi sono state completate nel 2013.[11] Le tablebase fino a sei pezzi sono disponibili su internet sia per il download gratuito che per la consultazione on-line.

Metriche: DTC e DTM modifica

abcdefgh
8
 
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
Differenza tra DTC e DTM: secondo la prima il Bianco dovrebbe catturare la torre, mattando in tre mosse dopo 1.Dxd1 Rc8 2.Dd2 Rb8 3.Dd8#, mentre per la seconda è più efficiente giocare 1.Dc7+ Ra8 2.Da7#(?)

Prima di creare una tablebase, il programmatore deve decidere un modo di scegliere la "migliore" possibilità tra le varie mosse possibili; detto in un altro modo, deve decidere quali posizioni considerare vinte, per poter poi contare quante mosse sono necessarie per arrivarvi. Generalmente sono usate due di queste metriche:

  • DTM (depth to mate, distanza dal matto): l'unica posizione vinta è considerata lo scacco matto;
  • DTC (depth to conversion, distanza dalla conversione): il colore più forte vince anche catturando del materiale, arrivando così in un finale più semplice. Ad esempio, in un finale di donna contro torre, il Bianco converte catturando la torre.

Quando si mette in conto anche la regola delle cinquanta mosse, vengono considerate anche due altre metriche, la DTZ (depth to zeroing-move) e la DTR (depth by the rule): tuttavia queste ultime non sono in genere state calcolate, mentre le tablebase DTZ sono state pubblicate dopo molti anni e sono disponibili per l'analisi e lo studio.[12][13]

In molti finali, la metrica DTC è più piccola della DTM, ma quest'ultima porta allo scacco matto più rapido. In alcuni casi DTC=DTM: questo avviene ad esempio quando il lato debole ha solamente il re (e non è possibile quindi convertire in un altro finale), oppure nel finale di due cavalli contro un pedone, nel quale l'unico modo di arrivare al matto è di non catturare il pedone.

Generare le tablebase modifica

Passo 1: generare tutte le possibili posizioni modifica

David Levy e Monty Newborn, How Computers Play Chess
abcdefgh
8
 
 
 
 
 
 
 
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
Le dieci case in cui può essere posto il re nero, contando la simmetria.

Una volta scelta la metrica, il primo passo nel calcolare le tablebase è generare tutte le posizioni con una data combinazione di materiale. Ad esempio, nel finale di re e donna contro re, il computer deve descrivere tutte le circa 40.000 posizioni in una matrice.

Il numero di 40.000 deriva da un ragionamento di simmetria. Il re nero può essere posto in una qualsiasi tra le case a1, b1, c1, d1, b2, c2, d2, c3, d3 e d4 (contrassegnate da una X nel diagramma): se fosse in un'altra casa, infatti, la posizione potrebbe essere trasportata tramite riflessione o rotazione in una già considerata con questo metodo. Ad esempio, non c'è differenza se il re è in uno degli angoli a1, a8, h1 o h8. Moltiplicando quindi 10 per le 63 case in cui può trovarsi re bianco e per le 62 possibilità offerte alla donna, si ottiene  . Alcune di queste sono tuttavia illegali (perché i due re sono a contatto), e quindi il numero effettivo è più piccolo.[14][15]

Ogni posizione è valutata sia nel caso sia il Bianco a muovere, sia che il tratto sia al Nero. Assumendo che il Bianco abbia la donna, quasi tutte le posizioni sono vinte per il Bianco, con il matto forzato in non più di dieci mosse, ad eccezione di casi di stallo e di inevitabile perdita della donna.

Nei finali senza pedoni, ogni pezzo moltiplica il numero di possibili posizioni circa di un fattore 60; nel caso dei pedoni, la situazione è più complessa, in quanto la simmetria è ridotta. Potendo infatti questi muoversi solo in avanti ma non di lato, le posizioni che risultano attraverso riflessione verticale o rotazione non possono essere considerate equivalenti. La miglior simmetria possibile è limitare un pedone nel rettangolo a2-a7-d7-d2, composto da 24 case, e poi sistemare gli altri pezzi nel resto della scacchiera. Di conseguenza, la complessità dei finali con pedoni è circa 24/10=2,4 volte quella di un finale con lo stesso numero di pezzi, ma senza pedoni.

Passo 2: valutare le posizioni con l'analisi retrograda modifica

L'idea delle tablebase è di costruire, a partire dalle posizioni di matto, tutte le posizioni da cui si può raggiungere la vittoria; per questo si creano, in sequenza, dei sotto-database in cui:

  • il Bianco dà matto;
  • il Nero è forzato ad entrare in una posizione in cui subisce matto;
  • il Bianco forza il Nero ad essere mattato alla mossa successiva, eccetera.

In generale, uno di questi elenchi è formato dalle posizioni in cui il Bianco entra in una posizione presente nel sotto-database precedente, oppure il Nero è forzato ad entrarvi (a seconda del tratto).

I diagrammi illustrano l'idea dell'analisi retrograda: la prima posizione è generata per prima, in quanto il Bianco può dare matto (con Dd7#); nella seconda, il Nero non può evitare il matto (1...Rb8 2.Db7#, 1...Rd8 2.Dd7#), mentre nella terza il Bianco può raggiungere la seconda con 1.Rc6. La posizione del terzo diagramma è quindi un "matto in tre semimosse" (o ply), mentre le altre due sono un "matto in due semimosse" e un "matto in una semimossa": ogni posizione viene valutata come vittoria o sconfitta dopo un certo numero di mosse. Le posizioni che non appaiono né nel database delle vittorie né in quello delle sconfitte sono patte.

abcdefgh
8
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
Mossa al Bianco: matto in una semimossa
abcdefgh
8
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
Mossa al Nero: matto in due semimosse
abcdefgh
8
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
Mossa al Bianco: matto in tre semimosse

Passo 3: verifica modifica

Dopo che le tablebase sono state generate e ogni posizione è stata valutata, il risultato deve essere verificato in maniera indipendente, per controllare la coerenza dei risultati.[16]

Per esempio, a partire dall'ultimo diagramma, il programma di verifica legge che, attraverso Rc6, vi è matto in tre semimosse; poi passa alla posizione dopo questa mossa, e verifica che essa è classificata come "matto in due semimosse". In questo caso le due valutazioni sono coerenti l'una con l'altra; in caso contrario, sarebbe stato necessario correggere le tablebase.

Problemi e strategie modifica

Catture, promozioni e mosse speciali modifica

Una tablebase con quattro pezzi sulla scacchiera deve basarsi sulle tablebase di tre pezzi che possono risultare quando un pezzo viene catturato. Allo stesso modo, se si considerano posizioni con almeno un pedone, è necessario possedere già una tablebase in cui sono presenti i pezzi che risulterebbero da un'eventuale promozione. Il programma deve tenere conto, durante l'analisi, della possibilità di una cattura o di una promozione.[17]

Le tablebase, inoltre, assumono che l'arrocco non sia possibile: questa è un'ipotesi ragionevole nella gran parte dei finali (sebbene l'arrocco sia ammesso in alcuni studi), e inoltre non in tutte le posizioni in cui re e torre sono nelle case di partenza è possibile effettuare questa mossa. A causa di questa ambiguità, sarebbe necessario effettuare valutazioni separate nel caso in cui l'arrocco sia o meno possibile.

Lo stesso problema esiste nel caso delle catture en passant, in quanto la possibilità di questa mossa dipende dalla mossa precedente dell'avversario. Questo problema è più delicato del precedente, in quanto la cattura en passant appare frequentemente nei finali di pedoni; per questo motivo le tablebase devono essere calcolate nel caso in cui entrambi i giocatori abbiano almeno un pedone.

Usare informazioni a priori modifica

abcdefgh
8
 
 
 
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
Un finale in cui è possibile usare informazioni a priori. Il Bianco dà matto in 72 mosse attraverso l'unica mossa 1.Rh7!

Usando il metodo generale, le tablebase devono considerare la possibilità che ogni pezzo occupi una qualsiasi delle 64 case della scacchiera. In alcune posizioni è possibile restringere la ricerca senza cambiare il risultato finale, diminuendo la richiesta di risorse computazionali e permettendo analisi altrimenti impossibili.

Un'analisi di questo tipo fu pubblicata nel 1987, in un finale di torre contro alfiere camposcuro, con pedoni in a2 e a3 (rispettivamente del Bianco e del Nero), una posizione del quale è illustrata a lato.[18] In questa posizione, possiamo assumere che:

  1. se un pezzo è catturato, possiamo controllare nelle tablebase risultanti con cinque pezzi;
  2. il pedone bianco è in a2 e quello nero in a3; nel caso di catture possiamo ancora passare alle tablebase con cinque pezzi.[19]

Attraverso questa semplificazione è possibile, anziché analizzare tutte le   posizioni dei due pedoni, analizzarne soltanto una, velocizzando i calcoli.

Bleicher ha creato un programma commerciale, chiamato "Freezer", che permette di costruire nuove tablebase da quelle esistenti attraverso supposizioni a priori. Il programma può produrre tablebase a sette pezzi con pedoni bloccati, anche se le tablebase con sette pezzi non sono generalmente disponibili.[20]

Applicazioni modifica

Scacchi per corrispondenza modifica

Kasparov - Resto del mondo, 1999
abcdefgh
8
 
 
 
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
La posizione dopo Dxb4, quando la partita fu ridotta ad una posizione con sei pezzi. Un'analisi condotta attraverso le tablebase mostra oggi che la posizione è senza speranza per il Nero; tuttavia, al tempo della partita non era ancora disponibile, e la partita continuò per altre sette mosse prima dell'abbandono del Nero.

Negli scacchi per corrispondenza, nel caso che le regole della competizione lo permettano, un giocatore può consultare le tablebase: ad esempio una di esse fu usata per analizzare un possibile finale risultante dalla promozione di due pedoni (che avrebbe portato ad un finale di due donne contro due donne) nella partita Kasparov - Resto del mondo.[21] Le tablebase sono usate anche per analizzare partite giocate sulla scacchiera dopo che sono concluse.

I giocatori per corrispondenza devono tenere conto, nell'uso delle tablebase, che esse ignorano la regola delle cinquanta mosse, secondo la quale la partita è patta se per cinquanta mosse consecutive non vi sono state né mosse di pedone né catture di pezzi: di conseguenza una posizione identificata dalle tablebase come vinta o persa potrebbe essere, nella pratica di gioco, patta. A partire dal 1974, con la scoperta (effettuata anche grazie alle tablebase) dell'esistenza di finali in cui più di cinquanta mosse erano necessarie per vincere, la FIDE cambiò la regola permettendo al gioco di continuare più a lungo in questi particolari finali; nel 1992, queste eccezioni sono state cancellate.[12]

Esistono tablebase, create da Haworth, che producono risultati in accordo con la regola delle cinquanta mosse; tuttavia tale limite "artificiale" non è generalmente tenuto in conto, in quanto queste cercano per il più breve matto forzato, anche se richiede centinaia di mosse.

Software scacchistico modifica

La conoscenza racchiusa nelle tablebase dà al computer un grande vantaggio nel finale: non soltanto infatti li giocano perfettamente, ma possono anche semplificare una posizione complessa in una che, attraverso le tablebase, sanno essere vinta.[22] Per quest'ultimo scopo, alcuni programmi usano "bitbases", che danno il valore teorico di una posizione senza il numero di mosse necessario alla conversione (cioè rivelano soltanto se la posizione è vinta, persa o patta): queste occupano meno spazio e sono generalmente di più rapido accesso.[23]

Tuttavia, alcuni esperti di software per giocare a scacchi hanno osservato alcuni svantaggi nell'uso delle tablebase da parte dei computer.[24] Oltre ad ignorare la regola delle cinquanta mosse, un computer in una posizione inferiore potrebbe evitare il lato perdente di una tablebase anche se il suo avversario non può in pratica vincere senza conoscere egli stesso le tablebase. L'effetto potrebbe essere un abbandono prematuro, oppure la scelta di una linea di gioco inferiore che perde con meno resistenza di quanto potrebbe offrire una tablebase.

Un altro inconveniente è che le tablebase richiedono molta memoria per essere immagazzinate: ad esempio le tablebase di Nalimov, che usano le attuali tecniche di compressione, richiedono 7,05 gigabyte di spazio per tutti i finali con cinque pezzi, mentre quelli con sei pezzi richiedono circa 1,2 terabyte[25][26] e quelle a sette pezzi quasi 140 terabyte.[11] Le bitbase richiedono molto meno spazio; ad esempio quelle usate dal programma Shredder comprimono tutti i finali con tre, quattro e cinque pezzi in 157 megabyte, meno di un quarantesimo delle tablebase di Nalimov.[27]

Alcuni computer giocano nel complesso meglio se la loro memoria è dedicata, invece che alle tablebase, all'ordinaria valutazione e ricerca delle varianti; inoltre, i programmi moderni analizzano abbastanza in profondità per trattare i finali elementari senza aver bisogno delle tablebase, ed è solo nel caso di posizioni più complesse che le tablebase migliorano significativamente il gioco.

Teoria dei finali modifica

abcdefgh
8
 
 
 
 
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
Muove il Nero. Il Bianco cattura la torre dopo 517 mosse e vince.

Le tablebase hanno permesso di rispondere a diverse domande sulla possibilità di vincere con certe combinazioni di materiali. Alcuni dei risultati sono stati:

  • due pedoni contro un cavallo: Josef Kling e Bernhard Horwitz, nel 1851, hanno proposto che il Nero può pareggiare entrando in una fortezza difensiva; le tablebase hanno dimostrato che generalmente si ha invece una vittoria, con DTC al più 67 e DTM minore di 78;[28]
  • due cavalli contro pedone: Aleksej Troickij aveva già stabilito che il Bianco può vincere forzatamente nel caso che il pedone non avesse passato la cosiddetta linea di Troickij; le tablebase hanno mostrato che anche se il pedone ha passato questa linea il Bianco può a volte forzare la vittoria attraverso zugzwang, con DTC=DTM=115 al massimo;[29]
  • nel caso di quattro cavalli contro donna, i primi vincono nel 62,5% delle posizioni, in non più di 85 mosse;[30][31]
  • donna e torre contro donna e torre: malgrado la parità di materiale, il giocatore con il tratto vince nel 67,74% delle posizioni, con massimo DTC uguale a 92;[32] sia in questo finale che nel caso di due donne contro due donne, il primo giocatore a dare scacco usualmente vince;[33]
  • torre e cavallo contro due cavalli e torre e alfiere contro due cavalli: le tablebase mostrano che questi sono vinti per il giocatore con la torre, rispettivamente, il 78%[34] e il 95%[35] delle volte; in questi casi la vittoria è a volte molto lunga, tanto che in una posizione si ha DTC=243.

Quest'ultima posizione ha avuto per qualche anno il record per il più lungo matto forzato generato da un computer (Ottó Bláthy, nel 1889, aveva già composto un problema con matto in 292 mosse[36]); nel maggio 2006, Bourzutschky e Konoval hanno scoperto una posizione, mostrata a lato, in cui DTC=517.[37][38]

Studi di finali modifica

E. Pogosyants, 1978
abcdefgh
8
 
 
 
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
Il Bianco muove e vince. Il compositore aveva in mente la soluzione 1.Ce3, ma le tablebase hanno rivelato che anche 1.h4 porta alla vittoria.
Harold van der Heijden, 2001
abcdefgh
8
 
 
 
 
 
 
8
77
66
55
44
33
22
11
abcdefgh
Il Bianco muove e patta

Poiché molti studi trattano posizioni coperte dalle tablebase, queste possono essere usate per verificare la loro correttezza. Alcuni studi sono stati provati errati in questo modo, o perché la soluzione del compositore non è corretta o perché esiste un altro modo per vincere (il che non è permesso); in un altro senso, alcuni studi possono essere distrutti cambiando la valutazione del finale risultante dalla soluzione: ad esempio il finale di donna e torre contro due torri era creduto essere una patta, ma le tablebase hanno dimostrato che è generalmente vinto dalla donna, distruggendo la maggior parte degli studi basati su questo finale.[39]

Per esempio, Erik Pogosyants ha composto il primo studio a destra, in cui il Bianco muove e vince. La linea principale voleva essere 1.Ce3 Txh2 2.0-0-0#, ma le tablebase hanno rivelato che il Bianco ha un altro modo per vincere, cioè 1.h4, anche se il Nero cattura il pedone. Ironicamente, le tablebase non riconoscono la soluzione di Pogosyants, perché include l'arrocco.[40]

Le tablebase hanno anche aiutato nella creazione di altri studi: i compositori possono esplorarle alla ricerca di posizioni interessanti (ad esempio in cui è presente uno zugzwang), usando un metodo chiamato data mining. Per tutti i finali da tre a cinque pezzi, ad esempio, sono stati raccolte e pubblicate tutte le posizioni di "zugzwang reciproco", cioè in cui il giocatore che ha il tratto è in zugzwang.[41][42][43]

Ci sono state alcune controversie sull'eventualità di permettere nei tornei di composizione degli studi prodotti con l'aiuto delle tablebase. Nel 2003, il compositore John Roycroft ha così riassunto il dibattito:

(EN)

«...not only do opinions diverge widely, but they are frequently adhered to strongly, even vehemently: at one extreme is the view that since we can never be certain that a computer has been used it is pointless to attempt a distinction, so we should simply evaluate a 'study' on its content, without reference to its origins; at the other extreme is the view that using a 'mouse' to lift an interesting position from a ready-made computer-generated list is in no sense composing, so we should outlaw every such position.»

(IT)

«...non solo le opinioni divergono, ma frequentemente vi si aderisce con forza, anche veementemente: ad un estremo c'è la visione che siccome non possiamo essere certi che un computer è stato usato è inutile tentare una distinzione, così dovremmo semplicemente valutare uno 'studio' per il suo contenuto, senza nessun riferimento alle sue origini; all'altro estremo c'è la visione che usare un 'mouse' per rubare un'interessante posizione da una lista preconfezionata generata col computer non è in alcun senso comporre, così dovremmo proibire ogni posizione del genere.»

(John Roycroft, EG 149[44])

Lo stesso Roycroft è d'accordo con quest'ultima affermazione, affermando che la differenza tra comporre con o senza l'aiuto del computer dovrebbe essere preservata il più a lungo possibile, mentre altri, come il Maestro Internazionale Mark Dvoreckij, hanno una visione più permissiva. Commentando nel 2006 uno studio di Harold van der Heijden, in cui, dopo alcune mosse, si raggiungeva la seconda posizione a destra, dove la mossa pattante era 1.Rb4!! (e non 1.Rb5, basata uno zugzwang reciproco che può avvenire tre mosse dopo, disse:

(EN)

«I am sure that this unique endgame position was discovered with the help of Thompson’s famous computer database. Is this a 'flaw,' diminishing the composer's achievement?
"Yes, the computer database is an instrument, available to anyone nowadays. Out of it, no doubt, we could probably extract yet more unique positions – there are some chess composers who do so regularly. The standard for evaluation here should be the result achieved. Thus: miracles, based upon complex computer analysis rather than on their content of sharp ideas, are probably of interest only to certain aesthetes.»

(IT)

«Sono sicuro che questa'unica posizione è stata scoperta con l'aiuto del famoso database di Thompson. È un 'difetto', che diminuisce il risultato del compositore?
Sì, il database computerizzato è uno strumento disponibile a chiunque oggigiorno. Da esso, senza dubbio, possiamo estrarre ancora più posizioni uniche - ci sono alcuni compositori che fanno questo regolarmente. Lo standard per la valutazione qui dovrebbe essere il risultato raggiunto. Così: miracoli, basati su complesse analisi con computer invece che con il loro contenuto di idee taglienti sono probabilmente di interesse solo di certi esteti.»

(Mark Dvoretsky, Study Composing Tourney[45])

"Giocare a scacchi con Dio" modifica

Sul sito web dei Bell Laboratories, Ken Thompson mantiene un link ad alcune delle sue tablebase. Il titolo recita "Play chess with God", cioè "Giocare a scacchi con Dio".[46]

A proposito delle vittorie lunghe scoperte da Stiller, Tim Krabbé ha scritto qualcosa di simile:

(EN)

«A grandmaster wouldn't be better at these endgames than someone who had learned chess yesterday. It's a sort of chess that has nothing to do with chess, a chess that we could never have imagined without computers. The Stiller moves are awesome, almost scary, because you know they are the truth, God's Algorithm – it's like being revealed the Meaning of Life, but you don't understand one word.»

(IT)

«Un Grande Maestro non giocherebbe meglio questi finali di qualcuno che ha imparato a giocare a scacchi ieri. È un tipo di scacchi che non ha nulla a che fare con gli scacchi, degli scacchi che non avremmo nemmeno potuto immaginare senza computer. Le mosse di Stiller sono imponenti, quasi paurose, perché tu sai che sono la verità - l'Algoritmo di Dio - è come avere la rivelazione del Significato della Vita, ma senza capirne una sola parola.»

(Tim Krabbé[35])

Note modifica

  1. ^ D. Levy e M. Newborn, How Computers Play Chess, p. 25-38
  2. ^ D. Levy e M. Newborn, op. cit., p.129-130
  3. ^ B. L. Stille, Exploiting symmetry on parallel architectures, p.84
  4. ^ R. E. Bellman, On the application of dynamic programming to the determination of optimal play in chess and checkers, in Proceedings of the National Academy of Sciences of the United States of America, vol. 53, n. 2, febbraio 1965, pp. 244–246, DOI:10.1073/pnas.53.2.244.
  5. ^ T. Ströhlein, Untersuchungen über kombinatorische Spiele [Translation: Investigations on Combinatorial Games] Ph.D. Thesis, Technical University of Munich, 1970.
  6. ^ Vedi anche The 'End-Papers' (PDF), in EG, n. 52, luglio 1978, p. 25. URL consultato il 1º aprile 2007 (archiviato dall'url originale il 25 marzo 2009).
  7. ^ T. Niblett, A. J. Roycroft, How the GBR Class 0103 Data Base was Created (PDF), in EG, n. 56, giugno 1979. URL consultato il 5 aprile 2007 (archiviato dall'url originale il 28 settembre 2007).
  8. ^ D. Levy e M. Newborn, op. cit., p.144
  9. ^ Vedi anche K. Thompson, Retrograde analysis of certain endgames, in ICCA Journal, 1986. e K. Thompson, The Programs that Generate Endgame Data Bases (PDF), in EG, n. 83, maggio 1986, p. 2. URL consultato il 5 aprile 2007 (archiviato dall'url originale il 28 settembre 2007).
  10. ^ L.B. Stiller, op. cit., p.68-113
  11. ^ a b (EN) Lomonosov Endgame Tablebases, su chessok.com. URL consultato il 15 giugno 2013 (archiviato dall'url originale il 1º maggio 2013).
  12. ^ a b G. McC. Haworth, Strategies for Constrained Optimisation (PDF), in ICGA Journal, marzo 2000. URL consultato il 1º aprile 2007 (archiviato dall'url originale il 29 settembre 2007).
  13. ^ 7-piece Syzygy tablebases are complete, su lichess.org. URL consultato il 26 maggio 2020 (archiviato dall'url originale il 13 luglio 2020).
  14. ^ D. Levy e M. Newborn, op. cit., p.140-143
  15. ^ L. B. Stille, op. cit, p.93-98
  16. ^ M. Bourzutschky, 7-man endgames with pawns [collegamento interrotto], su kd.lab.nig.ac.jp, CCRL Discussion Board, 27 agosto 2006. URL consultato il 1º aprile 2007.
  17. ^ Stiller, op. cit., p.99-100.
  18. ^ H. J. Herik, I. S. Herschberg, N. Naka, A Six-Men-Endgame Database: KRP(a2)KbBP(a3), in ICGA Journal, vol. 10, n. 4, 1987, pp. 163–180.
  19. ^ E. Bleicher, Building Chess Endgame Databases for Positions with many Pieces using A-priori Information. (PDF), su knowledge4it.de, 26 agosto 2004.. URL consultato il 1º aprile 2007 (archiviato dall'url originale il 27 settembre 2007).
  20. ^ K. Müller, Freeze! (PDF), su Endgame Corner, ChessCafe.com, maggio 2005. URL consultato il 1º aprile 2007 (archiviato dall'url originale il 25 marzo 2009).
  21. ^ E. V. Nalimov, C. Wirth, G. McC. Haworth, KQQKQQ and the Kasparov–World Game, in ICGA Journal, vol. 22, n. 4, 1999, pp. 195–212.
  22. ^ Steven A. Lopez, Shredderbases, su chessbase.com, 11 novembre 2006. URL consultato il 1º aprile 2007 (archiviato il 9 novembre 2012).
  23. ^ Aaron Tay, A guide to Endgames Tablebase, su horizonchess.com. URL consultato il 9 agosto 2007 (archiviato dall'url originale il 27 giugno 2007).
  24. ^ A. Tay, Can use of endgame tablebases weaken play?, su horizonchess.com, 30 giugno 2002. URL consultato il 1º aprile 2007 (archiviato dall'url originale il 30 gennaio 2009).
  25. ^ David Kirkby, Endgame Tablebases, su ChessDB Tutorial, 12 marzo 2007. URL consultato il 1º aprile 2007 (archiviato dall'url originale il 9 agosto 2007).
  26. ^ Stefan Meyer-Kahlen, Shredder Computer Chess Download - Endgame Database Info, su shredderchess.com. URL consultato il 17 agosto 2008 (archiviato dall'url originale il 2 febbraio 2009).
  27. ^ Shredder Computer Chess Download - Shredderbases, su shredderchess.com. URL consultato il 9 agosto 2008 (archiviato dall'url originale il 5 luglio 2008).
  28. ^ A. J. Roycroft, Two Bishops Against Knight (PDF), in EG, n. 75, 1984, p. 249. URL consultato il 5 aprile 2007 (archiviato dall'url originale il 28 settembre 2007)..
  29. ^ D. V. Hooper, GBR Class 0002.01 (PDF), in EG, n. 83, 1986, p. 3. URL consultato il 5 aprile 2007 (archiviato dall'url originale il 28 settembre 2007).
  30. ^ Tim Krabbé, 282. First 7-piece endgame database, su Open Chess Diary, 12 aprile 2005. URL consultato il 25 marzo 2007 (archiviato l'11 marzo 2007).
  31. ^ Emil Vlasák, News in 7 piece EGTB, su web.quick.cz, 21 luglio 2005. URL consultato il 25 marzo 2007 (archiviato dall'url originale il 1º aprile 2007).
  32. ^ G. McC. Haworth, Discarding Like Pieces (PDF), su is.reading.ac.uk, agosto 2001. URL consultato il 1º aprile 2007 (archiviato dall'url originale il 29 settembre 2007).
  33. ^ J. Nunn, Secrets of Pawnless Endings, p.379, 384
  34. ^ Tim Krabbé, 60. Play chess with God, su Open Chess Diary, 8 aprile 2000. URL consultato il 13 maggio 2007 (archiviato il 30 giugno 2007)..
  35. ^ a b Tim Krabbé., "Stiller's Monsters or Perfection in Chess.", su xs4all.nl. URL consultato il 1º aprile 2007 (archiviato il 31 marzo 2010).
  36. ^ Blathy, su geocities.com, 21 giugno 2003. URL consultato il 5 aprile 2007 (archiviato dall'url originale il 25 ottobre 2009).
  37. ^ Tim Krabbé, 311. White plays and wins in 330 moves, su Open Chess Diary, 31 marzo 2006. URL consultato il 4 maggio 2007 (archiviato dall'url originale il 9 maggio 2007)..
  38. ^ Tim Krabbé, 316. A 517-move win, su Open Chess Diary, 26 maggio 2006. URL consultato il 5 aprile 2007 (archiviato dall'url originale il 9 maggio 2007)..
  39. ^ J. Nunn, op. ct., p.367-368
  40. ^ Tim Krabbé, 324. A cooked, correct study, su Open chess diary, 15 settembre 2006. URL consultato il 5 aprile 2007 (archiviato l'11 marzo 2007).
  41. ^ G. McC. Haworth, Editor: J.W.H.M. Uiterwijk, 3–5 Man Mutual Zugzwangs in Chess, in Proceedings of the CMG 6th Computer Olympiad Computer-Games Workshop, TR CS 01-04, 2001.
  42. ^ G. McC. Haworth, Ken Thompson's 6-man Tables, in ICGA Journal, 2001.
  43. ^ G. McC. Haworth, P. Karrer, J. A. Tamplin, and C. Wirth, 3–5 Man Chess: Maximals and Mzugs, in ICGA Journal, vol. 24, n. 4, 2001, pp. 225–30.
  44. ^ A. J. Roycroft, Editorial (PDF), in EG, n. 149, luglio 2003, p. 51. URL consultato il 5 aprile 2007 (archiviato dall'url originale il 28 settembre 2007).
  45. ^ Mark Dvoretsky, Study Composing Tourney (PDF), su The Instructor, ChessCafe.com, luglio 2006. URL consultato il 1º aprile 2007 (archiviato il 25 marzo 2009).
  46. ^ Ken Thompson, Play chess with God, su plan9.bell-labs.com, 21 agosto 2002. URL consultato il 15 marzo 2007 (archiviato il 24 gennaio 2007).

Bibliografia modifica

Voci correlate modifica

Collegamenti esterni modifica

Estratto da "https://it.wikipedia.org/w/index.php?title=Tablebase&oldid=132193192"