Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Aquarium / wishes at Aquarium 2019
- - By pawnslinger (***) [us] Date 2017-12-05 18:18
Well, now that Aq 2018 has appeared on the scene... I thought it time to have a new thread... to express wishes for 2019.

My first wish is that the devs go read the thread about wishes for 2018 and start work on that list!
Parent - By retep1 (***) [de] Date 2017-12-07 11:35
Parent - - By pawnslinger (***) [us] Date 2017-12-10 07:21
I wonder if they, the devs, have ever thought of streamlining the event queue!?  Thousands of events get evaluated without any real need, due to the minimax function.  When running analysis from the Sandbox into the IDeA queue, the engine sends moves as a string of moves, one following the other in long sequences.  And IDeA dutifully evaluates all, then minimaxes the tree, which overwrites most of the evaluations.  Of course, the IA column is untouched.  But honestly I can say that the IA column is useless (to me).  I know some folks find it helpful, but I do not.  Much time could be saved if IDeA simply calculated the eval for the last move in the sequence -- the others being overwritten are not necessary to calculate.
Parent - - By dickie (*) [gb] Date 2017-12-10 11:39
A nice idea but sadly it will not work because it assumes all the moves in the line are necessarily the best continuation of the previous move, and even in a short line that can be untrue. An engine's pv at ply 2 can change from it's pv at ply 1 and is increasingly likely to do so as you move down the line. That is why all the nodes have to be evaluated because a better alternative move within the line will overrule the leaf and send a more correct score towards the root.
Parent - - By pawnslinger (***) [us] Date 2017-12-10 15:40 Edited 2017-12-10 15:43
Your point is well taken, but does not really affect my suggestion.  Perhaps I was not clear.  My suggestion would _only_ apply to moves entered into the queue from the Sandbox engine.  So continuations and alternatives generated in the regular IDeA prolongation process (as you describe) would remain as it is now.

In other words, my suggestion would only apply to sequences that could be affected by minimax.  As it is now, if a sequence of moves is generated in the Sandbox that contains 30 sequential ply (some possibly not the best moves), then due to the nature of minimax, only the final move in sequence needs to be evaluated.  Because minimax would automatically back fill the evaluation for the others.  This would all be done during the evaluation phase in IDeA (not the normal minimax).  The evaluation phase should be smart enough to "see" the sequence and hold the evaluation for all moves until the actual evaluation of the final leaf node is done, then back fill all needed evaluations immediately, then (and only then) updating all fields in the IDeA tree (as needed), both the IA and regular eval columns can be filled at that time. 

If done in this manner, 29 evaluations could be skipped and reduced to only 1.  Heck, a potential 30 to 1 reduction is worth a little effort.  This very process would make the use of the Sandbox an extremely valuable adjunct to the normal IDeA prolongation and alternative generation... which would remain unchanged (as pointed out above).... for the reasons you explained.
Parent - - By dickie (*) [gb] Date 2017-12-10 17:45
I am afraid you have misunderstood the point. Take the extreme situation where the first 29 ply are very good moves, but the 30th ply is dreadful. What you have succeeded in doing is back-filling the previous 29 ply with the dreadful evaluation you will get from the very bad move at ply 30, and turned IDeA away from what might have been a very good line. If the 29th ply had been evaluated it would have given a good result based on a different (alternative) move to your 30th ply and consequently displaced the evaluation at your 30th ply in the next minimax, and back-filled the previous 28 ply with a more sensible score. If you like the 29th ply has become a quasi leaf node because its best move is pointing away from your ply 30 but as yet has no children in its new direction.

In practice the pv lines produced by IA can be pretty suspect beyond the first few moves. Sometimes even the second ply is not optimal. It would be very nice not to have to do it, but if you want an accurate score at the root there is no choice other than to analyse all 30 ply because a mis-direction can occur at any, and many, ply in the IA line. Would it not make more sense to send much abbreviated IA lines to IDeA, thus avoiding wasting time in creating and pursuing long potentially sub-optimal lines in the tree?
Parent - By pawnslinger (***) [us] Date 2017-12-10 19:18 Edited 2017-12-12 15:00
Yes, you are absolutely right.  But you do understand this is exactly what minimax does. 

The only difference my suggestion would make is that it would eliminate the redundant evaluations (that minimax throws away immediately anyhow).

In other words, why calculate something that is immediately discarded??  A waste of time.

Of course, since my suggestion would only affect sequential sequences of moves... in the event queue... sent from the Sandbox... my suggestion would in no way affect evaluations done independently by IDeA.  And the Sandbox does not send positions to the queue (hence not sequential) if the position is already in the tree, OR if the position is already IN the queue.  So in that case, the sequence would not be sequential and my suggestion would not apply.

You can test my suggestion if you wish, take an empty IDeA project, one with a empty tree, turn off auto-prolongation (just for the testing) and run an engine in Sandbox linked to the tree.  Set the Sandbox so that no moves are sent for a couple of minutes (to let the engine settle down) and then have everything sent to the queue.  Then watch what happens when the queue finishes and does the minimax.  You will see what I mean... all calculations are over-written by the minimax and replaced with the evaluations from the leaf nodes.  So why bother with the intermediate calculations?  If they are simply to be thrown out?

Of course, the minimax is doing a great error if the leaf node has a bad or poor move.  But that is as it is now!

You argument is a good one, but what you are really saying is that we should not rely on the pv coming from the engine.  And I agree 100 percent.  This is why I have frequently advised people to go thru the tree and manually add alternatives at each node.  Because we cannot rely on the move selection shown in the pv.  It is merely the starting point.  But this does not in anyway refute my suggestion.
Parent - - By Uwak (***) [ph] Date 2018-01-01 13:38
My experience with IDeA is that in the long run, it is more effective to use longer settings than fast settings.
For years, I tried the recommended shorter settings of 10 secs or less and 1 ply. The IDeA tree gets filled up quickly and true it is sufficient to get most strong lines.
However, the trees soon become too large and the optimization takes longer and longer.
With longer settings 30 secs + 30 ply, trees are smaller and faster to optimize.
Parent - By Carl Bicknell (*****) [gb] Date 2018-01-01 15:11

> it is more effective to use longer settings than fast settings.

> With longer settings 30 secs + 30 ply,

Myself, I use 10 minutes + 40 ply. But you have to accumulate a lot of hardware and be very patient.
Parent - By SchackMatt (**) [se] Date 2018-01-01 21:49
Has also always been my strategy. In the opening I use 3 sec and 30pls (with Stockfish 3 sec and 35 pls). In middle game and endings I increase the number of pls. I think I get higher quality with much smaller trees. I do think I can intervene manually much better with a higher number of pls. Feeding a position with good moves is still very important.
Parent - - By Uwak (***) [ph] Date 2017-12-30 15:08
I suggest that in setting up a gauntlet tournament, the engine running the gauntlet should be allowed to choose the color to be played.
The current setup only allows White. Black is played only if you set the rounds to 2. You will have to wait until the engine is finished playing White.
This is useful if one is studying how a strong engine plays the black side of an opening position against several engines.
Parent - - By mist (**) [gb] Date 2018-01-03 19:32

>to express wishes for 2019.

Really?  It would be nice if someone could inform the paying public just what we got new in Aq18, other than a date change at the front.  Have anyone actually found anything really new yet? Things maybe a bit faster in IDeA but that is something
I do not use very much, so not too sure about even that as 'new' or 'better'.

In simple words Aq17 was the same as Aq18 but we just paid out for the 7 man T/B I think.:roll:
Parent - By retep1 (***) [de] Date 2018-01-11 16:12
Parent - By SchackMatt (**) [se] Date 2018-01-05 12:47
I have two rather simple wishes for 2018. At least when it comes to Aquarium.

1. Stop counting up analysed positions when entering a transposition. It is very confusing and time consuming to tidy up manually. Really not rocket sience.

2. A graphical interface for handling trees and sub-trees. Show the trees graphically, press left mouce button and e.g move a sub-tree into another tree, delete a sub-tree  ...
- - By Marek Soszynski (***) [gb] Date 2018-01-05 07:00
Make Aquarium usable under Linux/Wine - like it once was.
Parent - - By pawnslinger (***) [us] Date 2018-01-06 03:54
I 2nd this.  But I am not holding my breathe.
Parent - By mist (**) [gb] Date 2018-01-06 10:12

>Aquarium usable under Linux/Wine

It has only been the last copy of years it has been (more or less) usable under Windows !:roll:
Parent - By mroh (**) [de] Date 2018-01-07 16:39
Please check your private Messages ^^
Parent - - By Ghengis-Kann (***) [us] Date 2018-01-12 00:08 Edited 2018-01-12 00:14
In response to the dialogue above regarding leaf nodes and minimax, it is true that the interior nodes are thrown out, but how could you figure out what the leaf nodes are without first evaluating the prior moves? I suppose you could do a brute force calculation of all possible positions that are a certain number of ply in the future and evaluate all of them as leaf nodes then back propagate the results without calculating the interior nodes, but I doubt it would be more time efficient than what is currently done.
On the plus side, that method would enable a rigorous mathematical solution to the problem of chess if it were extended a sufficient number of ply.

The second best way to catch erroneous evaluations at the end or middle of an IA line is to send every move of the line into the IDEA queue for re-evaluation.
This also creates a permanent record of the intermediate moves that can be examined or expanded upon.
The first best way is to become a Grandmaster so you can catch the bad evaluations yourself.
Parent - - By pawnslinger (***) [us] Date 2018-01-12 08:39
Hi Ghenghis:

The suggestion only applies to sequences of moves sent from the Sandbox to the IDeA queue.  In such a sequence, the last move sent is always the "leaf" node.  Whether or not any of the moves is actually a leaf node in the tree.  For example, let's take the starting position of Chess and have the engine send the following sequence of moves:

e4 e5 Nf3 Nc6 Bb5 a6

We all know this sequence, very common.  I propose that if such a sequence is sent from Sandbox and added to the queue, then the IDeA analysis need not waste time analyzing any move except for the last one, a6.  At that point, the IDeA tree could even save further time by assigning the evaluation of a6 to all previous moves in the sequence and then processing as is done now.  Of course, ANY move in this sequence can be ignored if already in the tree.  And any move prior to such a move can also be ignored -- as they would all be in the tree already (i.e. a future position must have the moves leading up to it)... otherwise the tree would not have internal consistency.

Now I know that this was a trivial example.  But it is provided just as a thought experiment.  In the real world, I deal with exceptionally long sequences like this that are sent by the 100's, if not 1000's, into the IDeA queue.  And IDeA dutifully evaluates them all, unless they are in the tree already... in which case IDeA never puts them into the queue.

In the above example, if we assume that e4 and e5 are already in the tree and only the next 4 moves are new, then we would just drop those existing moves from our analyssis, as IDeA does not actually enter them into the queue now.  IDeA only enters new moves into the queue.
Parent - - By Ghengis-Kann (***) [us] Date 2018-01-12 16:34
That would be a mistake if you are preparing against me, because after 1. e4 I play c5.

I seem to recall that someone has written a script that does what you are asking by taking a tree and re-evaluating only the leaf nodes.
Search around a bit on the forum and see if you can find it, since that is exactly what you are asking for.
Parent - - By pawnslinger (***) [us] Date 2018-01-12 16:52
Me too.  That is I play c5 also.  And of course that is totally beside the point.  Right?

A script to re-evaluate leaf nodes does not do what I would like.  I am sure it is a great script, but my suggestion is 100 percent concerning NEW events added to the IDeA queue from the Sandbox engine, as such, by definition they do not currently exist in the tree.  IDeA does not place any event in the queue from the Sandbox, if the position is already in the tree.
Parent - - By Ghengis-Kann (***) [us] Date 2018-01-16 01:06
I'm at a bit of a loss here to understand exactly what you are asking for.
Parent - - By pawnslinger (***) [us] Date 2018-01-16 08:01 Edited 2018-01-16 08:03
I guess that makes 2 of us... I am at a loss as to how to better explain it.  Suffice it to say, I use the Sandbox A LOT to send sequences of moves into the IDeA queue... and I think many of those moves do not really need evaluation at all.  As it is now, some of the moves ARE automatically eliminated, because they a duplicates of moves already in the tree... hence no need to evaluate (or even add them to the tree).  In the example I gave the sequence of moves was trivial, hence there is no great waste of time if they are all evaluated.  But often the sequence can be quite long, for example if I am at a leaf node in my tree and run the Sandbox for 5 minutes before sending anything to the IDeA queue, then at 5:01 there will likely be a sequence of about 30 moves sent to the IDeA queue.  Moves that are in perfect sequence, each move will represent a leaf node at the time it is evaluated and all a complete and utter waste of time.  What should the IDeA queue do with such a sequence?  I suggest that it do only 1 evaluation, the evaluation for the final move in the sequence and back-fill (not minimax) the evaluations for the preceding moves in the sequence.  Then add them en-mass to the tree.  In this case, reducing the evaluation from 30 moves to 1.  The end result would be the same as is now done, but much much quicker.
Parent - - By dickie (*) [bm] Date 2018-01-16 13:44
If only "the end result would be the same as is now done" were true, but sadly it is not. When you evaluate the moves individually the computer will likely find better lines within a few moves from the start of the pv, so that the remaining moves in the pv become redundant and wiil not influence the eval at the root. it is quite inefficient to send engine pv's of 30 moves to the IDeA queue. Stick to 2 or 3 moves and you will build a better quality tree more quickly!
Parent - By pawnslinger (***) [us] Date 2018-01-16 16:03
Yes, that would still happen.  My suggestion in no way would change this.  This behaviour happens on the next "alternative" generation pass, AFTER a minimax has been done first.

Again, my suggestion would not hamper this important process.
Parent - By pawnslinger (***) [us] Date 2018-01-16 16:23
For the record, I think my trees are of a very high quality.  My suggestion would only speed their construction... whether you are adding 2 or 3 really good moves or 30 of lesser quality, my suggestion would help in either event.  Making the process more efficient, not changing the quality at all.  If you build good trees, my suggestion would simply allow you to build them quicker... not change the quality to the better or worse.
Parent - - By SchackMatt (**) [se] Date 2018-01-16 14:51 Edited 2018-01-16 17:46
I must say I 2nd Dickie's view on it.
Very seldom am I interested in only the leaf node in a sub-tree. I want to see if there are better lines a long the way as well. Usually there are better lines (or worse).
If only the leaf node will be evaluated I have to manually backtrack the analysis.

Now I am not using the sandbox but only the analysis in "Database" which sends positions to the IDea queue. Hence the Sandbox may do things I am not aware of.

Edit:I wouldn't mind though a function to switch off the analysis of intermediate positions as long as default is as is currently.
Parent - - By pawnslinger (***) [us] Date 2018-01-16 16:09
As I pointed out in my reply to Dickie, you are correct.  And my suggestion would not alter this alternative search in any manner.  You and Dickie do not understand what I am suggesting and I am afraid that I cannot explain it any better.

The search for alternative continuations would continue under my suggestion.  In fact, more resources, percentage wise, would be given to the alternative search, as the linear sequence evaluation is streamlined.  Thus affording more time to look at the alternatives.
Parent - - By Ghengis-Kann (***) [us] Date 2018-01-16 20:19
I think I can now understand what you want and it is already there.

It's called the Infinite Analysis Tree.
The leaf node values computed by IA are back propagated in that tree without IDEA spending any time on the intermediate moves.

Add that to your tree configuration and you will have exactly what you are asking for as a second tree that parallels the IDEA tree.
You can always manually add positions from the IA tree to the IDEA tree by stepping through the moves in the notation window and then clicking the "Analyze All" button.
Parent - - By pawnslinger (***) [us] Date 2018-01-17 04:09
I do not know what you are suggesting.  I delete the infinite analysis tree routinely.  So I am not sure what you are suggesting, but it is not what I am suggesting.

All I am suggesting is that the IDeA event queue can be evaluated in a more efficient manner.  The end result of my suggestion would be exactly what I have now, just a more efficient use of engine resources in the IDeA queue.  Simply put, there are evaluations done in the IDeA queue that don't need to be done.  Period.

They don't need to be done because the results of these intermediate evaluations are immediately thrown out by minimax.

Now, there is one downside that I can see to my suggestion.  If implemented, the infinite analysis tree would have incorrect evaluations in it.  For me, this is no problem.  Because I delete that tree daily.  And I have multiple installs of Aquarium, and the infinite analysis trees don't sync across them (as far as I know).  So even if I didn't delete them I would end up with at least 4 different IA trees that are not in agreement with each other.  Not very useful.  IMHO.
Parent - By SchackMatt (**) [se] Date 2018-01-17 07:54
That was really a downside.
I totally rely on the Infinie analysis and don't run IDea besides the tasks Infinite analysis sends to its queue and occasionally to find candidates on next level.
Up Topic Rybka Support & Discussion / Aquarium / wishes at Aquarium 2019

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill