Nome utente : Password :
Registrazione di un nuovo utente
Moderatore: Hrqls , coan.net , rod03801 
 BrainKing.com

Board for everybody who is interested in BrainKing itself, its structure, features and future.

If you experience connection or speed problems with BrainKing, please visit Host Tracker and check "BrainKing.com" accessibility from various sites around the world. It may answer whether an issue is caused by BrainKing itself or your local network (or ISP provider).

World Of Chess And Variants (videos from BrainKing): YouTube
Chess blog: LookIntoChess.com


Messaggi per pagina:
Lista delle discussioni
Non ti è possibile inserire messaggi in questo forum. Il livello minimo di sottoscrizione per linvio dei messaggi è {0}.
Modalità: Chiunque può inviare messaggi
Cerca nei messaggi:  

15. Agosto 2014, 10:58:03
rabbitoid 
All rubbish. There's no need for a time-check. Here's a 2-cent algorithm:
- when any game ends, check if it is in a tournament. If not, we're done.
- if yes, check it's section for winner
- if there is a clear-cut winner for this section, check if all sections are done.

How to "check this section for winner":
- Find the highest score
- for all the other players in the section:
- - assume that all the unfinished games for the player will be wins.
- - if the new assumed score is higher than the "highest score" the section is not over.
- if for all the other players in the section the test is good, the section is over.

This algorithm costs almost nothing in performance. 3 "for" loops and a couple of ifs.
Why won't it work? because there's no one to implement it.

15. Agosto 2014, 11:07:14
ThunderGr 
Argomento: Re:
Modificato da ThunderGr (15. Agosto 2014, 11:14:50)
rabbitoid: Interesting. Do you have any idea how this would interact with the current tasks when a game is over? Do you know how is the tournament system currently implemented? Do you know what methods and algorithms are currently used to check tournaments for completion? Do you know how this algorithm of yours would interact with that?
What about the rest of the games currently in progress within the session? Where in your algorithm is that being taken in account?
The fact that you are not supposed to end the session but allow the rest of the games continue seem to escape you. The games are played for the enjoyment of the game(mostly) and rating determination as well as tournament position add to the enjoyment.

Unless you know all those things I have mentioned, then your statement about easiness and simplicity are void.

And, by the way, 'for' loops tend to be costly, depending on the processing in the for loop and 'if' branches can also be costly, depending on the occasion, so your determination of simplicity and processing time based on the number of 'fors' and 'ifs' is rather arbitrary, as well.

15. Agosto 2014, 11:44:39
rabbitoid 
Argomento: Re:
ThunderGr: No idea what other tasks are done on "game end". Same goes for the other "do you know" questions. I don't say that this is implementable code. This is a description, pseudo-code.
To implement correctly one certainly has to consider side effects.

When I say section (not session) over, I mean the section as a whole in the tournament. NOT individual games within the section. Those should continue. All we want is for the tournament to progress.

"For" loops can be costly, but those I described shouldn't be. they are on the number of players in a section and one on the number of sections in a round.

15. Agosto 2014, 11:59:35
ThunderGr 
Argomento: Re:
Modificato da ThunderGr (15. Agosto 2014, 12:17:25)
rabbitoid: The basic problems with implementing features that the current implementation had not accounted for on creation, is the interaction with the existing system.
I felt the need to point out the holes in your algorithm, because you stated how "simple" it is and how "rubbish" is what others had said.

It is my estimation that the feature discussed here is implementable, but it is also my impression that the current system would need at least a partial reconstruction to do so, as the creator of the system had focused on other very important issues during the implementation(like versatility without compromising speed) and I have to say this site has the most flexible tournament system I have seen anywhere. Allowing unlimited players, variable-length sections, unlimited tournaments, a host of different time controls, different tournament types and so many things taken for granted by the people here really needed some very involved programming, considering all the issues you need to deal with in order to make it happen.

This does not mean that the integration of such a feature could not be done without reconstruction(as I can only guess as to current implementation), but extensive testing and very careful programming will be needed which I do not think is even near "very easy", even though the algorithm itself seems to be easy.

If you have not predicted that the need for games in a session to continue after a session is over may arise, you may need to expand the existing structure to allow that. Depending on where the structure is kept this can mean the need to rebuild the games database(again, wild speculation, and what I imagine to be worst case scenario).

So, contributing to the solution of problems and posting ideas is great, but I think it would be prudent to avoid classifications as to the difficulty of implementation for things we know very little(if anything) about.

15. Agosto 2014, 12:42:36
rabbitoid 
Argomento: Re:
ThunderGr: Interesting discussion, but since the main ingredient (Fencer) is missing, pointless to continue.

Data e ora
Amici in linea
Forum preferiti
Gruppi
Consiglio del giorno
Copyright © 2002 - 2024 Filip Rachunek, all rights reserved.
Torna all'inizio