1) A return of Persistent Hash without the bugs so that one has perfect retrograde analysis and forward propagation of scores. (I would not have had to buy Shredder 12 to use in Aquarium if R4.05 had this).
As Vytron explained, "Shredder handles retrograde analysis and forward propagation of scores perfectly. What you see in Shredder is the expected behavior of Persistent Hash. Rybka 3 didn't behave like that due to bugs."
2) "Moz Deep Postion Analysis", a subset of IDeA for the large group of Aquarium users who cannot cope with the complexity of IDeA. Moz DPA would use simple IDeA settings to let IDeA run for a fixed time, e.g. 10 hours overnight, to produce the best analysis it could in a fixed time with simple branching options, as in Fritz' "Deep Postion Analysis."
As Vytron explained, "Shredder handles retrograde analysis and forward propagation of scores perfectly. What you see in Shredder is the expected behavior of Persistent Hash. Rybka 3 didn't behave like that due to bugs."
2) "Moz Deep Postion Analysis", a subset of IDeA for the large group of Aquarium users who cannot cope with the complexity of IDeA. Moz DPA would use simple IDeA settings to let IDeA run for a fixed time, e.g. 10 hours overnight, to produce the best analysis it could in a fixed time with simple branching options, as in Fritz' "Deep Postion Analysis."
![[mx]](/mwf/v12/flags/mx.png "Mexico")
The development of Aquarium is unrelated to the development of Rybka, the possible inclusion of Persistent Hash in Rybka 4.1 would be unrelated to Aquarium.
I'll do what I can to convince Vas, though I still don't know how to approach him, last time Vas was convinced that the state of Rybka Persistent Hash and its bugs was unacceptable, and without time to fixing them he better removed it, now I'm telling him that there are people that would accept Persistent Hash even if it was as bugged as it was in Rybka 3.
I'll do what I can to convince Vas, though I still don't know how to approach him, last time Vas was convinced that the state of Rybka Persistent Hash and its bugs was unacceptable, and without time to fixing them he better removed it, now I'm telling him that there are people that would accept Persistent Hash even if it was as bugged as it was in Rybka 3.
> I'll do what I can to convince Vas, though I still don't know how to approach him, last time Vas was convinced that the state of Rybka Persistent Hash and its bugs was unacceptable, and without time to fixing them he better removed it, now I'm telling him that there are people that would accept Persistent Hash even if it was as bugged as it was in Rybka 3.
I'm not a programmer but if I'm not mistaken, wasn't part of the Persistent Hash bug a result of Vas mistakenly crisscrossing the functions of Persistent Hash Write Depth with that of Persistent Hash Play Depth? And I think the Persistent Hash Size was some how affected too.
If crisscrossing of these Persistent Hash was the major reason for the Persistent Hash bugs observed in R3, can't Vas implement it correctly this time for R4.1? I mean the first time I, or we, would understand the mistake. But definitely not repeating the same mistake twice which means the correct implementation (as it should have been) might solve a huge part of the bugs, if not all.
> wasn't part of the Persistent Hash bug a result of Vas mistakenly crisscrossing the functions of Persistent Hash Write Depth with that of Persistent Hash Play Depth?
That was one of the bugs, yes, but just a single bug unrelated to the others.
> If crisscrossing of these Persistent Hash was the major reason for the Persistent Hash bugs observed in R3, can't Vas implement it correctly this time for R4.1?
This is not a thing about Vas being able to, but about he wanting to. My impression was that he wanted to have a fully working Persistent Hash or nothing. He chose nothing.
I'm proposing a compromise, having Persistent Hash whatever it takes, including having that crisscross bug, and all the others. Seems like a wonderful price to me, actually. I wouldn't want Vas to say something like "but I don't want users complaining that I could have fixed x bug" as a reason to have no PH on Rybka 4.1,
Vytron, there's no doubt we all want a working PH but
it's not a question of whether Vas can make a fully working PH but a question of doing everything correctly this time before releasing it. He just needs more time in this area to implement & test everything correctly. It's all about doing correct implementation this time around (a lesson from R3) and the PH bugs should disappear.
> This is not a thing about Vas being able to, but about he wanting to. My impression was that he wanted to have a fully working Persistent Hash or nothing
it's not a question of whether Vas can make a fully working PH but a question of doing everything correctly this time before releasing it. He just needs more time in this area to implement & test everything correctly. It's all about doing correct implementation this time around (a lesson from R3) and the PH bugs should disappear.
Vytron, I am 100% behind you in your view of PH: a buggy version is far better than none. I am playing in an ICCF Candidates section currently, so I cannot provide a concrete example of the great importance of PH, but I can describe it.
After many hours of inifinite analysis of White's 25th move, R4 still insists on 25 xxx, which leads to a steady but sure decline of White's big advantage (score) over the next 15 ply.
Shredder and I suggest an alternative 25th move for White: 25 yyy. Very extensive testing shows that 25 yyy is best. However, during infinite analysis, while arrowing back from the 28th move in the correct line, R4 rarely "learns" or "remembers" that 25 yyy is best but instead keeps choosing 25 xxx.
R4 is definitely stronger than Shredder 12. However, Shredder correctly implements "backward propagation" of the score.
After many hours of inifinite analysis of White's 25th move, R4 still insists on 25 xxx, which leads to a steady but sure decline of White's big advantage (score) over the next 15 ply.
Shredder and I suggest an alternative 25th move for White: 25 yyy. Very extensive testing shows that 25 yyy is best. However, during infinite analysis, while arrowing back from the 28th move in the correct line, R4 rarely "learns" or "remembers" that 25 yyy is best but instead keeps choosing 25 xxx.
R4 is definitely stronger than Shredder 12. However, Shredder correctly implements "backward propagation" of the score.
> However, Shredder correctly implements "backward propagation" of the score
This is my point exactly. It's all about correct implementation.
I strongly believe that if Vas invested more time into this PH for R4.1, compared to time invested in R3, most of the bugs associated with it should be gone. This is why I stated earlier that his mistake in PH implementation in R3 was understandable. Humans make mistakes. But the same mistake should not and cannot be created in another upcoming R version. The idea is to examine the mistakes from R3 and to avoid repeating this mistake altogether in R4.1 in order to make everything work correctly. And I believe he can do it correctly.
He can't expect to do the same thing/mistake he did for R3's PH and expect a different outcome for R4.1. Unless there are other reasons.
> But the same mistake should not and cannot be created in another upcoming R version.
Vas could say "I agree, and that's very easy, I can just keep PH out". That's not helping.
> Vas could say "I agree, and that's very easy, I can just keep PH out". That's not helping
This is also true too. I see your point though.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill