clocks during analysis.

Haha! Is this a joke or serious?

Also Arcticpenguin, what I meant was in fast games (whixh is most popular) your thinking time is often (but not always) a one digit number like 4 sec. I don't meant you should round anything.

It's not so much to whether there is a good way to store compressed data of it (there is and it's several miles better than all of what's been proposed) but how the storage goes to use. The feature is fancy but has little potential to be useful.

And if you can store it like (0.04) (0.10) (0.24) (0.65) you can translate it to (4) (6) (14) (41) and then translate it back again. I don't get your point with the rounding.

#22 Maybe I don't understand what you're saying or making a mistake, but it seems to me that if you store move times instead of fractions of the clock remaining then you have to round. If you round too much then over many moves you risk increasing the difference between the real clock and what is displayed. If you round to the tenths of seconds you will probably never notice but you need more than one digit per move. If you round to the second you probably accumulate a few seconds of inaccuracy if you try to reconstruct the clock by adding up move times. Over the course of the game it might make a timeout look like the player has a few seconds left.

#23 Point taken. Hope you don't mind my uninformed ramblings too much. I don't actually expect to solve anything, just have a bit of fun thinking/learning about it.

If you let a clock run and store the time for every move rounded to 1s. like (0.04) (0.10) (0.24) (0.65), then you can translate it to (4) (6) (14) (41) and then translate it back again to (0.04) (0.10) (0.24) (0.65). Since you can translate it back to what you had before no information can be lost.

And this first series (0.04) (0.10) (0.24) (0.65) are roundings from a running clock then no errors can accumulate over other errors.

Sorry I'm still missing something that is obvious to you. How do you translate 0.04 seconds to 4 etc.?

My thoughts were that say both players play a 60 second game using exactly 1.33 seconds per move. If you record that as 1.33 sec per move then no problem. If you record it as 1 sec per move then when the game times out on move 45 there will by 15 seconds left on the clock.

Your system is dealing with this but I don't quite understand how and maybe I would if you explained what would be recorded after each move in this hypothetical game.

If you make the roundings from a running clock, some instances will then register as 2 s in both the original series and the translated because you are rounding from a running clock that of course doesn't "do any mistakes"

(0.0133) (0.0266) (0.0399) running clock
(0.01) (0.03) (0.04) registering
1 2 1 translating to save space.

2nd line is reproducable from the translation