Newsgroup: it.hobby.scacchi
Titolo: Forum arbitrale: Buchholz col software Diena

Mi sono state segnalate delle differenze nel computo del Buchholz tra il
(software) Diena e un applet Java (scritto da me), utilizzato alla
Societa` Scacchistica Torinese per mostrare on-line l'andamento di un
torneo gestito col Diena.
Cercando di capire piu` in dettaglio donde nascessero queste
discrepanze, mi sembra di aver evidenziato un comportamento "anomalo" da
parte del Diena. Magari era cosa notissima, io pero` non la sapevo...
Intanto preciso che i problemi si verificano soltanto quando sono
coinvolte partite non giocate. In questi casi, l'applet Java segue molto
rigorosamente la cosiddetta regola italiana: nei casi di riposo/bye (da
uno o mezzo punto) o assenza giustificata/ritiro, il giocatore, dal
punto di vista del buchholz ovviamente, prende uno zero (sorry per la
terminologia bridgistica:-). In caso di forfait, invece, prende
normalmente i punti dell'avversario.
Il Diena, invece, non sembra fare questa distinzione. Anche se un
giocatore non e` mai stato messo in tabellone, nel database del Diena
(nome pomposo per indicare i file .A, .B, .C, .D o .E) viene comunque
accoppiato ad un avversario teorico. Purtroppo sembra che la risultante
partita -di per se' inesistente- finisca per avere piena dignita`
durante lo spareggio tecnico, portando quindi a risultati che non sono
quelli corretti.
Esemplifico quanto appena scritto: mettiamo che il numero 14 dichiari di
non giocare il terzo turno. Il numero 27 prende il bye da un punto. Nel
database del Diena, la partita 14-27 viene registrata e, ai fini dello
spareggio tecnico, sara` effettivamente considerata, per cui al 14
saranno conteggiati i punti del 27 (e viceversa), quando invece per loro
avrebbe dovuto essere conteggiato zero.
Ammesso che la cosa sia un problema del Diena (e non un mio errore di
analisi - e alla fin fine e` questo che chiedo ai colleghi arbitri di
verificare), e` rimediabile? Ovviamente si`, da parte di Diena :-), ma
nel frattempo che fare?
- ignorare il problema (che per altro non e` evidentissimo ed emerge
  solo in casi particolari), rifugiandosi nell'abusatissima scusa "E`
  colpa del programma" :-)
- ricalcolare sempre a manina il Buchholz per tutti i giocatori
  coinvolti in qualche partita non giocata (calcolo non proprio facile
  da fare a fine torneo quando c'e` un organizzatore che alita sul collo
  perche' vuole conoscere i risultati finali:-)
- intervenire manualmente sul database del Diena (che e` soluzione
  praticabile da chi ha le idee sufficientemente chiare su come sono
  organizzati internamente i file del Diena)
Io adottero` questa terza soluzione. Se qualcuno e` interessato a
conoscerla e/o discuterla puo` scrivermi privatamente (non e` difficile
intuire il mio indirizzo corretto).
-- 
Roberto Ricca
2006: GO GIANTS (Anybody but the Dodgers) [Magic Number: 163]


Con tutto il rispetto per l'autore del programma, che credo lo abbia
sviluppato circa 20 anni fa,  per la sua buona volonta' e disponibilita',
mi sono sempre chiesto perche' si continui ad usare questo programma.
Come scacchista valgo poco, come informatico ritengo molto di piu'.
Non sarebbe ora che la Federazione si decidesse per l'adozione
di qualcosa di sicuramente affidabile o magari ne promuovesse
lo sviluppo ex novo a professionisti del settore?

Forse nel 2107 la FSI si deciderà di cambiare il Diena, devono trascorrere 
almeno 120 anni
sai e per via dei tempi regolamentari altrimenti il cambiamento non è 
valido...non ci resta che aspettare :-)

 settore?
Non ne vale la pena. Non dimentichiamoci che si tratta di collezionare i
dati di un torneo di scacchi, che non e` esattamente "rocket science".
Nessuno poi vieta l'utilizzo di altri software (gia` presenti sulla
piazza). Primo o poi lo faro` anch'io...


Sono stato affezionato al Diena per molti anni, riconoscendogli una
iniziale funzionalità e la eccellente manipolabilità dei dati.
Poi, negli anni, mi sono rimasti solo l'affetto e la gratitudine e ho
fatto di tutto per evitarlo (incontrando, a dire il vero, una certa
resistenza da parte degli arbitri).
Già nei primi anni Novanta mi sono convertito a PROTOS di Christian
Krause, il cui algoritmo era eccellente (a dispetto di una certa
"rigidità" del programma, comunque ampiamente gestibile). Non so perché,
ma in Italia questo programma non ha mai fatto breccia...
E dire che Krause era il presidente della Commissione Svizzero della
FIDE e che insieme abbiamo anche tenuto un corso di aggiornamento per
arbitri a Roma, quando nessuno sapeva ancora cosa fosse davvero lo
svizzero. Ricordo di aver scritto su carta l'algoritmo dello svizzero,
che poi Christian ed io avremmo spiegato a tutti gli arbitri. Nemmeno
quello bastò per convertire i nostri arbitri a PROTOS...
Oggi guardo con favore a Swissmaster e a Vega, che spero di contribuire
a sviluppare in questo 2007. Ho infatti chiesto a Luigi Forlano di
implementare lo Svizzero accelerato decrescente, così da metterci al
pari con il resto d'Europa. Cominceremo a lavorare dal 8 gennaio,
presumibilmente. L'idea è di avere il programma in tempo per
inaugurarlo a Porto Mannu (19-26 maggio).
Temo comunque che il problema principale del passaggio ad altro
programma non sia la funzionalità della parte accoppiamenti quanto
piuttosto la compatibilità con gli elenchi elo prodotti dalla FSI.
Ciao,
YG
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 YG
ciao,
michele
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it