Newsgroup: it.hobby.scacchi
Titolo: motore svizzero Olandese per JavaPairing !!

sono lieto di annunciare che il motore di abbinamento 'svizzero
Olandese' è ora pienamente corrispondente alle regole ufficiali FIDE.
 la release 1.9, appena rilasciata, è come sempre all'indirizzo
 
http://javapairing.sourceforge.net/ITA/index.html
Attendo fiducioso il vostro feedback!
Eugenio

 Olandese' è ora pienamente corrispondente alle regole ufficiali FIDE.
E` un'affermazione estremamente impegnativa, soprattutto considerando 
che le regole FIDE sono finalmente state pubblicate (dopo una decina 
d'anni!) solo a fine novembre (pero` ad agosto 2009 ti avevo fornito le 
regole 2006 e da allora non ci sono stati grandi cambiamenti).
Ti interessa effettuare dei test? Non e` nulla di ufficiale, ma ti posso 
garantire che se i test saranno accurati (e verranno superati), non 
avrai poi problemi con la procedura di endorsement da parte della FIDE.
-- 
Roberto Ricca
2010:  1st time WORLD SERIES CHAMPIONS SAN FRANCISCO GIANTS
2011: GO GIANTS (Anybody but the Dodgers)  [Magic Number: 163] 

Roberto quando lo sforni un sistema  per alzare di botto anche l'elo
FIDE ? 
Se è pronto lascia un email che lo collaudiamo.
Io continuo a colare a picco nel frattempo.
Saluti
Alexander D.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Se pronto lascia un email che lo collaudiamo.
basta cambiare segno a tutte le formule

Vorrei sapere che differenza c'è tra un software approvato dalla FIDE 
(Vega,JavaFo,SwissManager e spero JavaPairing) e quelli non 
approvati(Sys,SwissPerfect,SwissMaster ecc. ecc.)dal momento che la FIDE 
accetta i rapporti dei tornei di qualsiasi software.
Forse mi si risponderà che con quelli approvati si possono gestire i tornei 
FIDE,a questo punto bisogna vedere cosa si intende per tornei FIDE dal 
momento che tutti i tornei hanno qualche partecipante con l'Elo FIDE.
Perchè mai dovrei fare dei test accurati al mio software quando tutti gli 
altri non lo fann?.
Grazie per la risposta.
Voltolini Luigi 

 FIDE accetta i rapporti dei tornei di qualsiasi software.
Precisiamo: l'elenco dei software approvati dalla FIDE e`
[Dutch System]
 SWISS MASTER (Koninklijke Nederlandse Schaakbond  NED)
 SWISS MANAGER (Heinz Herzog AUT)
 WINSWISS (Franz-Josef Weber GER)
 TURNERING SERVICE (Harald Heggelund NOR)
 Tournament Director (Neil Hayward ENG)
[Dubov System]
 VEGA (Luigi Forlano ITA)
(da: 
http://www.fide.com/fide/handbook.html?id=143&view=article
- l'ultimo punto). E` in esame JavaPairing per il Dubov.
Per tornare alla domanda fatta sopra, l'osservazione e` corretta: al 
momento non c'e` differenza tra software approvati e software che non lo 
sono. Ma quello che vale oggi non e` destinato a valere per sempre. 
L'obiettivo della FIDE e` evidente: che un torneo possa essere omologato 
solo se in esso e` stato usato un sistema di abbinamento approvato. Non 
e` un obiettivo che verra` raggiunto rapidamente, ma prima o poi ci si 
arrivera`.
Tieni conto che al momento attuale, ci sono programmi approvati che 
*non* rispettano le regole pubblicate di recente (alcune delle quali in 
vigore da quasi dieci anni, ma cosa conosciuta solo a pochi eletti).


Ti ringrazio per la risposta,dato che fai parte della Commissione sul 
regolamento dei sistemi svizzeri,non si potrebbe semplificare questi 
regolamenti sullo svizzero in modo tale che i giocatori possano calcolare 
abbastanza facilmente di loro mano gli accoppiamenti?
Per esempio abolendo il conteggio sui floaters e assegnando il colore 
spettane solo dopo che gli abbinamenti sono stati fissati,lo so si perde in 
equità,ma si guadagna in semplicità e chiarezza.
Grazie per l'attenzione
Voltolini Luigi 

 perde in equità, ma si guadagna in semplicità e chiarezza.
Gia`. Purtroppo il sistema italo-svizzero, nella sua straordinaria 
semplicita`, era terribilmente iniquo.
Diciamo pure che saremmo tutti piu` felici se si trovasse un sistema sia 
equo che semplice (e le proposte complete saranno sicuramente valutate). 
Fino a quel momento, pero`, sara` l'equita` il criterio guida.



Ciao, ho provato a scaricare il tuo programma, ma in esecuzione si
apriva il prompt dei comandi, poi più nulla.
Allora l'ho eseguito dal prompt e ho intercettato l'errore, te lo
posto:
C:\JavaPairing\dist>JavaPairing.jar
Exception in thread "main" java.lang.NoClassDefFoundError: C:
\JavaPairing\dist\J
avaPairing/jar
Caused by: java.lang.ClassNotFoundException: C:\JavaPairing\dist
\JavaPairing.jar
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:
301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: C:\JavaPairing\dist\JavaPairing.jar.
Program wil
l exit.
A programmazione (sono al 1°anno di informatica, e facciamo java),
abbiamo appena fatto le eccezioni e il try-catch (XD), per cui so cosa
vuol dire il messaggio, ma non riesco a capire il perchè, mi potresti
aiutare?
Grazie e ciao
Federico Zermian

  VEGA (Luigi Forlano ITA)
Posso chiederti quanti e quali di questi software sono con licenza di tipo
Open Source? 
Al momento il discorso della FIDE verte su dare *regolamenti* ed approvare
*software*. In realta' cio' che davvero conta sono *algoritmi* e
*implementazioni*. Se il software di Eugenio verra' approvato, e se come
penso si tratta del primo di tipo Open Source, questo costituira' una
pietra miliare. 
Questo perche' la discriminante nell'approvazione di un software non e'
"quanto e' bello nella grafica" o "quanto e' facile da usare" o "quanto e'
carino il suo manuale", ma solo e unicamente se implementa correttamente
l'algoritmo che attua il regolamento. Di conseguenza, qualsiasi altro
software Open Source che dovesse riutilizzare la porzione di codice
implementata da Eugenio (eventualmente tradotta in altro linguaggio di
programmazione) non potra' che essere automaticamente approvato "ad una
rapida occhiata".
Da quel momento in poi, e col tempo, la differenza la fara' per l'appunto
l'estetica, l'usabilita', la manualistica disponibile... ma non altro.
Ovviamente questo vale per i software Open Source... ma non vedo come
potranno alla lunga competere quelli di altro tipo, contro una concorrenza
che gode di questi vantaggi e che e' pure gratuita.
Ciao, Bruno.


 potra' che essere automaticamente approvato "ad una rapida occhiata".
Temo che una traduzione dovrebbe comunque essere sottoposta a controllo, 
ma per il resto potrebbe essere cosi`. Uso il condizionale perche' 
rimarrebbe comunque da verificare che il codice utilizzato sia proprio 
quello.
Ma ammettiamo che cio` sia fattibile (e non ho dubbi che lo sia) e a 
quel punto non vedo perche' la FIDE non potrebbe dire che chiunque usi 
quel software vedra` automaticamente approvato il suo programma (di 
getsione torneo).
Anche se, sotto questo punto di vista, sarebbe forse preferibile una 
libreria chiusa.


mi state caricando di una bella responsabilità ...
grazie comunque della fiducia ... ho passato e ripassato tantissimo
tempo a fare le verifiche sui file di test passati da Mr. Krause
Eugenio

mah! E' la prima volta che mi imbatto in questa eccezione 'Exception
in thread "main" java.lang.NoClassDefFoundError'
che versione hai del JRE, per che sistema operativo?


ho l'ultima (build 1.6.0_23-b05), per Windows x64:
forse è perchè è per x64?
Però non dovrebbe farlo, java è fatto apposta per essere ultra-
compatibile...
Comunque c'ho su anche il JDK, ma non credo che c'entri qualcosa:
adesso lo provo su Ubuntu poi ti faccio sapere
Ciao
Federico Zermian


Provato su Ubuntu e gira bene
Come mai non gira su win? XD
Comunque ottimo il programma, ma quando apro una nuova finestra spesso
taglia alcune cose (bottoni, campi, etc): non si può far niente per
questo?
Poi ho visto il sorgente, hai usato Netbeans, giusto? Magari tra
qualche mese forse ci potrò mettere su mano XD
Ciao
Federico Zermian

 libreria chiusa.
E perche' ?
Ciao,
Marco


 regole 2006 e da allora non ci sono stati grandi cambiamenti).
Hai un link per le ultime regole pubblicate ?


 E perche' ?
Premesso che e` opinione personale dettata da ignoranza in materia, ma 
credo che sia piu` facile certificare qualcosa che non possa poi essere 
modificato.


 Hai un link per le ultime regole pubblicate ?
Sito della federazione moldava, settore "Amenita`"?
.
.
.
.
.
.
.
Dove si possono trovare regole della FIDE *pubblicate* (e sottolineo: 
pubblicate), se non sul sito della FIDE? Magari nell'handbook? Magari 
la` dove si parla di "FIDE Swiss Rules"? :-)



Sono riuscito ad aprilrlo su win: lo aprivo con java 6.22 invece di
aprirlo con la piattaforma java 6.23
Mi sa che c'era un conlitto con la 6.22
Ho disinstallato il JDK 6.22, ho impostato come programma predefinito
la 6.23 e poi ha funzionato, però mi sembra strano: bisogna per forza
avere il JDK per aprirlo?
Ciao
Federico Zermian

 avere il JDK per aprirlo?
mah! la potenza di Java ... va oltre le mie capacità di
comprensione :-)

 modificato.
acc ... speriamo che non prevalga questa logica ... il SW libero
subirebbe un colpo mortale ;-)

  la release 1.9, appena rilasciata
sto già pensando ad ulteriori migliorie per la prossima release ...
- possibilità di fondere due file di torneo in modo da
a) consentire l'inserimento dei giocatori su più PC nei grossi open
b) riutilizzare i tornei  (si può già comunque duplicare il torneo e
poi fare editing su di esso)
c) convertire un torneo a squadre in individuale ?!
se vi viene im mente qualcos'altro ... si avvicinano le vacanze di
Natale e avrò ancora tempo da dedicare
Eugenio

 Natale e avrò ancora tempo da dedicare
Io non trascurerei tutto quello che riguarda il contorno al tuo programma.
Tre suggerimenti:
1. Il sito web non e' molto ben fatto (in particolare quelle immagini
gif). Non trascurare questo: e' il primo impatto, e chi passa da li'
potrebbe farsi subito un'impressione tanto negativa quanto immeritata.
2. Il manuale in Inglese. Al momento quello che ho visto ha un formato
stranissimo (forse e' derivato da una presentazione PowerPoint), e ci sono
qua e la' degli errori di inglese facilmente evitabili (schema invece di
scheme, diversi wont invece di want... questi sono solo quelli che ricordo
perche' ripetuti piu' volte).   
3. L'interfaccia utente. Se hai un po' di tempo, fai un piccolo
esperimento. Prendi un tuo amico (possibilmente arbitro, ma non
necessariamente), e dagli da fare un piccolo compito col tuo programma (ad
esempio condurre a termine un piccolo torneo simulato da 10 giocatori e
5-6 turni). Osservalo mentre smanetta col tuo programma, senza intervenire
in alcun modo. Sicuramente potrai trarre informazioni preziose su come
rendere il tutto piu' facile e immediato per l'utente.
Just my 2 cents,
Bruno.


 subirebbe un colpo mortale ;-)
Non ho nulla contro l'open source, che anzi mi piace e perciò gli auguro 
vita lunga e prospera, però...
Per certificare un qualsiasi oggetto, è necessario apporgli un "sigillo 
  inalterabile" che sia in grado di assicurare all'utente finale che 
l'oggetto è assolutamente identico al campione di riferimento. Anche 
quando si tratti di un oggetto immateriale come un software, e quindi il 
sigillo sia del tutto virtuale, il concetto non cambia minimamente.
Perciò, quando sia necessaria una certificazione del software, non vedo 
proprio come sia possibile accettare che resti possibile modificare il 
software dopo la certificazione ma nel contempo quest'ultima resti 
valida. Tu accetteresti una contabilità scritta a matita? :)
Dal punto di vista dell'utente "ignorante di cose tecniche", sarebbe 
impossibile essere sicuri che il software sia effettivamente conforme a 
quello certificato, a meno che al codice non fosse apposta una firma 
digitale che lo rendesse effettivamente inalterabile (vanificando però 
così in buona misura la natura dell'open source).
Ma anche così, pur essendo risolto il problema per l'utente finale, dal 
punto di vista del destinatario dei dati (nel nostro caso la FIDE) non 
sarebbe possibile accettare per buoni gli abbinamenti senza sapere se 
magari l'utente stesso abbia pasticciato in qualche modo con i sorgenti 
ed alterando così, magari senza volerlo, le regole del sistema. Perciò 
un software open source, anche se certificato, a mio parere dovrebbe 
necessariamente essere considerato esattamente alla stessa stregua di 
uno non certificato.
Ciao!
mario
-- 
73 es 51 de i3hev, op. mario
Non è Radioamatore, se non gli fuma il saldatore!
- Campagna 2006 "Il Radioamatore non è uno che ascolta la radio"
it.hobby.radioamatori.moderato
http://digilander.libero.it/hamweb
http://digilander.libero.it/esperantovenezia

Caro Eugenio,
dovresti implementare i cartellini per i giocatori con la loro storia
Poi ampliare i TieBreak per i tornei a squadre,almeno quello in base al peso 
delle scacchiere.(Prima,seconda,ecc.)
Ma qui credo si debba modificare verso il sicuro l'inserimento dei giocatori 
sulle varie scacchiere.
Ho apprezzato molto l'aggiunta sul calcolo della TrancheFide anche se 
all'inizio non capivo bene come funzionava la cosa,poi ho capito.
Appena hai tempo sarebbe auspicabile spiegarlo anche nel manuale.
Condivido che il software dovrebbe essere blindato e non OpenSource,fino a 
quando non sarà approvato dalla FIDE si puo' tenere OpenSource,ma poi 
sarebbe una pazzia non farlo.
Qualcuno ha avanzato l'ipotesi che qualche malintenzionato possa 
modificare(senza che nessuno se ne accorga)l'algoritmo per poi mettere in 
circolazione il tutto,dato che ormai il codice lo sa tutto il mondo,la mia 
idea per essere sicuri che l'algoritmo non sia contraffatto è quella di fare 
in modo che all'avvio del software il programma esegua almeno un test su uno 
dei tornei di test ufficiali,se lo passa siamo sicuri.
Il problema comunque non è solo del tuo OpenSource JavaPairing,ma di tutti 
gli altri software diciamo blindati,infatti io potrei benissimo ricostruire 
una interfaccia grafica del tutto uguale per esempio a Vega5,inserire un 
semplice algoritmo svizzero
ACCETTABILE ma comunque scorretto e compilare il tutto.
Si ritorna a quanto detto sopra,l'unica soluzione è un test ad ogni avvio 
del programma,magari solo su un turno specifico abbastanza complesso da 
risolvere.
Per il momento per me dovresti mantenere ancora l'open source,pero' non 
credo che tu abbia degli aiuti sul codice,
quanti sono i programmatori all'altezza di darti un qualche aiuto valido?Per 
me nessuno,troppo complicato!!
Dimenticavo,nei tornei a squadre l'abbinamento è fatto in base ai punti 
squadra o in base ai punti giocatori?
Ho fatto delle prove,una volta sembrava la prima un altra volta sembrava la 
seconda.
Mi permetto di avanzare una domanda: JavaPairing tiene presente che nei 
tornei a squadre la ricerca del colore dovuto non è diciamo "importante" in 
quanto le scacchiere sono a colore alternato?
Ma qui entriamo in troppi particolari.
Di nuovo complimenti
Voltolini Luigi


 valida. Tu accetteresti una contabilità scritta a matita? :)
Quello che dici e' vero, ma non e' una cosa che riguarda solo il software
Open Source. Anche per il software a sorgente chiusa e' lo stesso: se la
FIDE certifica il programma proprietario X nella versione 1.0, chi ti dice
che la versione 1.1 che sosteneva di aver cambiato solo il modo in cui il
programma stampa l'output non abbia invece alterato in qualche modo
l'algoritmo di abbinamento, magari anche solo per errore? 
Anzi, col software proprietario e' anche peggio: non avendo accesso al
codice, tutto quello che puoi fare e' testare di nuovo il programma e
ragionare per induzione (se i primi 1000 casi testati mi vengono uguali
alla versione 1.0, questo mi induce a pensare che il codice sia lo
stesso). Col codice Open Source invece si puo' accertare molto piu'
facilmente e in modo deduttivo. 
Non vorrei che l'equivoco nascesse dal fatto che la parola Open Source
richiama il fatto che tutti possono accedere al codice e modificarlo.
Questo e' vero, ma non e' vero che puoi aggiornare la versione di quel
software se non sei il legittimo "proprietario". Ti faccio un esempio: se
io prendo per intero il codice di Eugenio, lo chiamo "BrunoPairing 10.0" e
lo distribuisco con licenza libera, e' tutto ok. Se pero' lo chiamo col
nome originale, "JavaPairing 10.0", allora Eugenio puo' farmi causa.
JavaPairing e' suo, ed e' lui decide cosa mettere in quel programma!
Ciao, Bruno.


> JavaPairing e' suo, ed e' lui decide cosa mettere in quel programma!
credo che Bruno abbia detto giusto ... la garanzia che non ci siano
manomissioni la dà chi gestisce il sito ufficiale di distribuzione. Tu
sai che vai a ....JavaPairing .... e ti scarichi l'ultima release e
sei sicuro.
Poi è chiaro, anche la FIDE ha scritto che l'endorsment è valido
finchè non vengono modificate le regole (e ci facciamo aggiungere che
dovrebbe comunque eseguire dei test di tanto in tanto sulle release
successive) così stiamo tutti + tranquilli.
Aggiungo che nulla vieta all'arbitro di alterare arbitrariamente i
turni a mano .... perciò ??

 l'algoritmo di abbinamento, magari anche solo per errore?
Secondo me hai colto appieno il nocciolo della faccenda.
Per esempio, nel 2006 la FIDE ha certificato il Dubov in Vega.
Era la versione 4.2.7
La FIDE scrive nel handbook, elencando i sw certificati:
----------------------
..............
d.VEGA (Luigi Forlano ITA) Dubov System
----------------------
Posso testimionare che con onestà intellettuale, Luigi Forlano ha
sempre detto - e scritto - che l'algoritmo certificato era quello
indicato sopra.
Dopo più di 4 anni Vega è alla versione 5.8 (esce a giorni :-).
L'algoritmo del Dubov non è stato più toccato, salvo ipotetici errori
casuali e involontari come esemplifichi.
Il Dubov in questa versione e ancora l'algoritmo certificato dalla
FIDE?
Secondo me si, ma nessuno può averne la certezza.
Come se ne esce?
Ciao
Franco

 turni a mano
Questo no :-)
E' scritto in più parti nel handbook che i tornei e gli eventi FIDE
sono da gestire con uno dei sistemi Svizzeri approvati.
Significa che le regole vanno approvate meticolosamente.
Non ci sono margini di discrezione per l'arbitro. Punto.
Aggiungo che le citate regole ammettono che un torneo sia gestito con
regole (sistemi di abbinamento) non approvati dalla FIDE. In tal caso
al report del torneo sono da abbinare le regole usate, per una
valutazione della SPP.
Ma questo è altro discorso.
Ciao
Franco

 Non ci sono margini di discrezione per l'arbitro. Punto.
Qui mi riferisco ad abbinamenti prodotti da un sw certificato, a meno
di palesi e grossolani errori che fanno pensare a un mal funzionamento
del sw.
Franco De Sio

<In tal caso
<al report del torneo sono da abbinare le regole usate, <per una
<valutazione della SPP.
Con le migliaia di report di tornei che la FIDE riceve da parte di software 
non certificati dubito che ci sia una valutazione da parte della SPP.
Sarebbe auspicabile che la FIDE dia l'incarico ad un team di programmatori 
(2,3 persone) per implementare una DLL blindata (ho scritto bene?)contenente 
una volta per tutte l'algoritmo esatto,poi fare in modo che questa DLL sia 
accessibile(ma non modificabile) in qualche modo dai vari programmatori per 
i loro software di abbinamento,in pratica un motore comune e tante 
interfaccie diverse a seconda dei gusti.
Voltolini Luigi
Voltolini Luigi

 Come se ne esce?
Come se ne esce... e lo chiedi a me?! :)
Io direi che se ne esce con un po' di buonsenso. Se il programma X e' 
certificato, la certificazione si puo' estendere automaticamente anche 
alle versioni successive, salvo agire tempestivamente nel caso in cui 
qualcuno segnali qualcosa di strano.
In un futuro piu' o meno lontano, spero che la FIDE provveda a 
promulgare, insieme ai regolamenti per gli abbinamenti, anche delle 
implementazioni immediatamente disponibili. E in forma utilizzabile sia 
dai software Open Source che da quelli proprietari.
Ciao, Bruno.

 richiama il fatto che tutti possono accedere al codice ...
purtroppo non c'� nessun equivoco, il fatto � che � proprio cos�: 
chiunque pu� accedere al codice e modificarlo! E quello di lasciare la 
version label inalterata � un abuso di natura civilistica che, prima di 
essere corretto, pu� richiedere i tempi (biblici) di un procedimento 
giudiziario, magari internazionale; per cui l'assumere a priori che 
l'integrit� del codice sia rispettata, in pratica, � ben poca 
garanzia... io (che, detto per inciso, mi occupo di informatica 
professionalmente da quasi un quarto di secolo) di sicuro non me ne 
fiderei :)
E' ben vero che, in linea puramente teorica, lo stesso tipo di abuso 
potrebbe essere perfezionato anche in un software blindato; ma, in 
pratica, la cosa � *molto* improbabile, dato che le difficolt� tecniche 
dell'introduzione di una modifica non casuale e non distruttiva 
sarebbero davvero notevoli, per non dire proibitive.
Ciao!
mario
-- 
73 es 51 de i3hev, op. mario
Non � Radioamatore, se non gli fuma il saldatore!
- Campagna 2006 "Il Radioamatore non � uno che ascolta la radio"


 fiderei :)
Capisco tutto il tuo ragionamento, e continuo a darti ragione. Pero', 
sintetizzando al massimo, cio' che dici si puo' riassumere in questi 
termini: un software OS e' meno sicuro perche' il codice si puo' 
ricompilare piu' facilmente dopo una modifica.
Infatti, come tu stesso dici, anche il software non-OS si puo' 
tecnicamente modificare (illegittimamente), anche se meno facilmente. E, 
aggiungo io, anche il software non-OS, una volta  modificato (sempre 
illegittimamente), puo' richiedere i tempi biblici di un procedimento 
giudiziario perche' cio' venga ufficialmente riconosciuto.
Pero' questa e' piu' che altro una possibilita' teorica. Nella realta', 
se io vado sul sito ufficiale di un software OS e lo scarico, sto tanto 
sicuro (e addirittura anche *piu'* sicuro, per quanto spiegavo nel mio 
post precedente) che non se scarico un software proprietario. Nella 
pratica, questo e' quanto basta.
Ciao, Bruno.

 non certificati dubito che ci sia una valutazione da parte della SPP.
Non ho scritto di uso di sw non certificati, ma di sistemi di
abbinamenti non autorizzati dalla FIDE.
Riporto dal Handbook, C.04.5:
While reporting a tournament to FIDE the Arbiter shall declare which
of the official FIDE Swiss systems was used. If another system was
used, the Arbiter has to submit the rules of  this system for checking
by the Swiss Pairing Committee.
Significa due cose:
a) la FIDE non si rifiuta di omologare un torneo giocato con regole
non ufficiali, a patto che siano state preventivamente dichiarate nel
bando del torneo (cfr C.06 FIDE tournament rules);
b) l'ufficiale di gara è espressamente tenuto a dichiarare l'uso di
tali regole nel Tournament Report e quando lui (o la federazione)
invia la documentazione del torneo alla FIDE per l'omologazione, deve
espressamente chiedere il passaggio alla SPP.
Questa procedura non prevede un azione attiva della SPP sui report che
arrivano alla FIDE, che sarebbe impercorribile per ovvi motivi.
Poi, ragionevolmente, se sono state usate regole diverse, e interesse
di chi le ha usate a far si che siano valutate ed eventualmente
certificate.
Ciao
Franco De Sio

 quanto le scacchiere sono a colore alternato?
il motore è lo stesso e si applica ad entrambi i tipi di torneo,
quindi con gli stessi vincoli di colore e float. non sono d'accordo
che nel torneo a squadre la scelta del colore sia meno importante,
considera che 4 giocatori che stanno in formazione fissa vogliono
anch'essi l'alternanza del colore!

 uno non certificato.
Mah?!
Ciao,
Marco.


 sarebbero davvero notevoli, per non dire proibitive.
Scusa, ma cosa ti fa pensare che coloro che sarebbero in grado di mettere
le mani su un software "open" per modificarlo in maniera "maliziosa" e tra
l'altro facendo anche si' che i risultati della modifica maliziosanon
siano individuabili (altrimenti si vedrebbe subito che il software usato
non e' compliant con la certificazione) non sarebbero in grado anche di
fare un reverse engineering di un codice java ?
Ciao,
Marco


 pratica, questo e' quanto basta.
Concordo fino all'ultima virgola.
 Ciao, Marco


 qualcuno segnali qualcosa di strano.
Cosa che tra l'altro e' piu' probabile che possa avvenire (nel caso in cui
ci sia in effetti qualcosa di strano) con algoritmi "open", perche' in
quel caso eventuali problemi possono essere notati da tutti (tutti quelli
che si mettono a leggere il codice) e quindi uno puo' avere un sistema
"piu' testato": 
Program testing can be used to show the presence of bugs, but never to
show their absence! (Dijkstra)
Lo scrivo sempre sui kit di test che scrivo io, sperando che qualcuno di
quelli del management capisca, ma finora ho ottenuto scarsi risultati.
Ciao,
Marco


 giudiziario ...
su questo non c'è alcun dubbio; la differenza sta nel fatto che mentre 
di un OS hai a disposizione i sorgenti * per definizione *, nel caso di 
un software proprietario i sorgenti non li hai praticamente mai e la 
probabilità di riuscire a fare una modifica qualsiasi che non faccia 
semplicemente andare il processo in crash è praticamente zero...
Ciao!
mario
-- 
73 es 51 de i3hev, op. mario
Non è Radioamatore, se non gli fuma il saldatore!
- Campagna 2006 "Il Radioamatore non è uno che ascolta la radio"


 semplicemente andare il processo in crash è praticamente zero...
Condivido pienamente!!
Voltolini Luigi 

 fare un reverse engineering di un codice java ? ...
evidentemente non mi sono spiegato bene, e il risultato è che parliamo 
di cose diverse; ti faccio un esempio pratico: supponiamo che, per 
motivi suoi, un programmatore decida di abrogare un controllo 
regolamentare relativamente "raro", come ad esempio B.6 dell'olandese, e 
far quindi circolare una revisione ricompilata di un software open ma 
certificato, senza evidenziare la modifica (per inciso, spesso basta 
poco, come commentare una if; non va nemmeno vicino alla complessità di 
un reverse engineering su un software del quale non possiedi il 
sorgente). E' chiaro che il problema verrà prima o poi scoperto e 
corretto, ma intanto il software modificato andrà certamente a finire in 
mano ad un certo numero di utenti finali che, per svariati motivi, non 
si accorgeranno della modifica (quanto meno, non subito: la complessità 
dei sistemi di abbinamento è tale che prima che si evidenzino certi casi 
particolari potrebbero passare dei mesi), producendo così un certo 
numero di tornei che magari non verranno omologati dalla FIDE perché al 
test i turni risulteranno difformi - ed avrà quindi prodotto dei danni. 
Secondo te va bene? A me pare di no...
Per quanto riguarda la possibilità che il tampering venga attuato 
direttamente dal proprietario del codice, be', questa è tutt'altra 
questione: è chiaro che il programmatore, se vuole può modificare il 
prodotto come e quando vuole, ma in questo caso le garanzie sono fornite 
dal fatto che non ha alcun interesse ad introdurre modifiche che lo 
rendano non conforme (ci rimette!), tanto più alla luce del fatto che la 
FIDE può rivedere l'endorsement come e quando lo ritenga opportuno (e, 
come s'è visto dalle recenti liste di software approvati, lo fa).
Ripeto: non ho * assolutamente * nulla contro il software open source, 
ne faccio uso e lo apprezzo, ma in certi casi secondo me non è adatto...
Ciao!
mario
-- 
73 es 51 de i3hev, op. mario
Non è Radioamatore, se non gli fuma il saldatore!
- Campagna 2006 "Il Radioamatore non è uno che ascolta la radio"


 ha
scritto:
Per quanto riguarda la possibilit?he il tampering venga attuato
direttamente dal
proprietario del codice, be', questa ?utt'altra questione: ?hiaro che
il programmatore,
se vuole pu?dificare il prodotto come e quando vuole, ma in questo
caso le garanzie sono
fornite dal fatto che non ha alcun interesse ad introdurre modifiche
che lo rendano non
conforme (ci rimette!), tanto pi?a luce del fatto che la FIDE pu?
vedere l'endorsement
come e quando lo ritenga opportuno (e, come s'?isto dalle recenti


 degli arbitri si riduca ad un insieme quasi vuoto.
tento di rispondere qui cumulativamente a tutti gli interventi
precedenti sul tema open source si/no.
proprio per questo è necessario unire le forze di quei pochi che ci
sono e l'unico modo per farlo garantendo tutti i partecipanti è l'open
source, temo che nessuno collaborerebbe al software proprietario di un
altro.
Soprattutto in ambito internazionale (al quale ambisce il progetto
JavaPairing) la filosofia open source è molto apprezzata; le pubbliche
amministrazioni fanno importanti accordi con società di consulenza che
propongono prodotti open (non si paga il software ma la consulenza);
in Italia invece fanno i contratti con Microsoft ... la solita Italia!
Per anni ho scaricato software (Linux, OpenOffice, ...) senza dare
niente in cambio, come immagino molti di voi. Con JavaPairing
restituisco qualcosa (anche se di nicchia) alla comunità.
Non fatevi scoraggiare dalla complessità vera o presunta del codice!
Provate a dare un'occhiatina, possibilmente con un editor che
evidenzia la sintassi, e vi renderete conto che il flusso è lineare.
Sicuramente farò anche il manuale tecnico, così se dovessi smettere
sarà più facile ad un altro volenteroso subentrare nel progetto.
Eugenio

> Hai un link per le ultime regole pubblicate ?
nella cartella 'swiss' della distribuzione di JavaPairing trovi
'Handbook 2010' con le regole attuali, anche se non ho ancora il
verbale della riunione della Swiss Pairing Commettee di settembre che
potrebbe aver introdotto qualche variazione.

 in Italia invece fanno i contratti con Microsoft ... la solita Italia!
mi correggo qualcosa si muove ...
http://www.nichivendola.it/sito/mcc/informazione/software-libero.html

 Hai un link per le ultime regole pubblicate ?
Da stasera, anche in italiano:
http://www.arbitriscacchi.com/index.shtml
Ciao
Franco De Sio