Everything seems to be working great! I am done complaining, for now .
I would like to see the two improvements that I requested:
1) an additional EPD option to finish the current ply when an end condition is hit.
2) to be able to ignore blank assessments like blank rate codes when backsolving. This last one would help me quite a bit.
Do any of you other readers see a benefit to these additions? To be fair, please make some noise either way as that would help Mike to decide on the perceived value.
I'm sorry, but I didn't check very carefully. You changed the limit to 2B nodes . That translates to just over 3 minutes. I always analyze significantly longer than that. Why do you insist on these arbitrary limits? Even if you are using a 32 bit compiler 2^30 or 10^9 should be simple while allowing everyone to set whatever value they choose from 1 to 1,000,000,000 million nodes. You could even go back to thousands of nodes if a user doesn't like a minimum of 1 million nodes if you would just provide a field width that shouldn't take more than a few seconds to implement. One alter table command, and a couple of field length changes and a recompile. It would even be easier if you were using a 64 bit compiler or if your compiler supports 64 bit integers, then you could allow 2^62 or 4*10^18 and no worries about a thousands or millions multiplier which is probably at least a minor annoyance. Actually if your compiler only supports 32 bit integers I can give you the simple code to implement a 64 bit data type and to convert back and forth from text if you would like. It has been a while but I think I can still write some c code. If not, I can certainly put it in words. Simple math using higher precision than the natively supported data types isn't very difficult to implement. What format do the engines use to return the number of nodes? It looks like they return a 64 bit field or a long, probably variable length, text field. Either is fairly simple to deal with. One very simple method if the only operation is a value test is to simply put the first 9 digits or 30 bits in one field and the next 9 digits or 30 bits in the second field. To test you compare the high order fields and if the returned high order field is lower then you branch low, if higher you branch high, if equal you perform the same test on the low order fields. If no actual math is needed this simple method works well. If the value is returned in a variable length ascii string you could use 4 or 5 32 bit fields to support 16 or 20 digits. Just load the fields as above with groups of 4 characters each. As the highest ascii value is 39 there would be no problem with accidental negative values. Then just perform the tests as stated above. The binary comparisons will work fine on the ascii values, you just have to test more fields.
The direct ascii method at the end may have one catch, you may need change the order of the bytes or even reverse all of the bits. If that is the case then using the first method and converting 9 text digits to binary for each field seems easier.
Everything seems to be working great! I am done complaining, for now .
I would like to see the two improvements that I requested:
1) an additional EPD option to finish the current ply when an end condition is hit.
2) to be able to ignore blank assessments like blank rate codes when backsolving. This last one would help me quite a bit.
You're very welcome.
I'm not sure what you mean by "when an end condition is hit." The end conditions are when the minimum time has elapsed, the minimum nodes have been analyzed or the minimum depth has been reached.
Backsolving does have a checkbox for ignoring blank assessments (Informant rate symbols).
------------------- Mike Leahy Head Geek at bookup.com
Bogg wrote:I'm sorry, but I didn't check very carefully. You changed the limit to 2B nodes . That translates to just over 3 minutes. I always analyze significantly longer than that. Why do you insist on these arbitrary limits?
These are not arbitrary limits. The program is able to run on 32bit Windows which allows for 2 billion, the maximum signed integer. On my machine I'd have to wait about 25 minutes to see an engine potentially get into the billions.
If your chess engine is delivering 10 million nodes a second, it does translate to just over 3 minutes. I'm not sure why you would want more than three minutes of analysis at that speed (nodes per second) but you are certainly entitled to that.
Have you considered analyzing the EPD file outside of Chess Openings Wizard? EPD analysis is handy inside of COW but the process does completely tie up the COW app and I'd assume you'd like to use the app to look at the data too.
I will look at handling >2B nodes with extended types.
------------------- Mike Leahy Head Geek at bookup.com
The reason for wanting to analyze for longer times is because I know it is necessary if you want an accurate answer. On my rig it has sometimes taken over an hour to get to analysis that seemed trustworthy. More normal is in the range of 5-10 minutes. As I stated somewhere earlier my normal reason to use the analyze epd feature would be to narrow my research but even for that I need answers that are trustworthy enough that I don't need to check them all by hand.
The only reason that I continue to complain about this is because it has annoyed me for decades and I think I demonstrated how simple the fix/improvement would be to accomplish. As the epd features have truthfully become of little value to me If you have limited time I would find the ignore numeric assessments during backsolving a much much more useful addition.
PS
You already replied to my email thanking you for the update.
I didn't notice the other message with the questions.
1) You understood what I meant by end conditions. Stopping immediately upon reaching one of those irrespective of their value doesn't give a useful answer as the current ply is truncated in the middle and the returned analysis, that's only purpose is to let you know that the engine is working (at least that is the only value I can see), is given. Waiting longer for a real answer may not be what some others want so I suggested having another option to allow the current ply to finish. I suppose maybe just returning the last completed ply's results would be another weaker option. But the results of the truncated searches are all over the place and IMO nearly useless.
2) The question regarding backsolving: I said numeric assessment because I meant numeric assessment. I have no use for Informant rate codes. They portray positions that are significantly different in assessment as being roughly equal and only of value for languageless material, IMO. As you have this feature for IRCs it seems that it would be fairly easy to add NAs.
Again, as stated in the other message, the second improvement is of much more use to me.
I know I am a pain. As a software engineer and later as a DBA I was a stickler and a perfectionist. As has been noted, no offense was taken, my coworkers didn't like being held to my standards but they always appreciated my help as did my clients. When I started using your software I was nearly 2000. Now, with some help from your software, I am more like 2300. I understand that my needs may not coincide with all the other users. That doesn't mean that I don't want changes that would help me on my journey of improvement. Improvement #2 would save me an immense amount of time by allowing me to ignore parts of a tree that I have chosen to not evaluate while being able to go back and easily find it later.
EPD ignoring positions set to zero seems problematic as that would require setting them to zero which would conflict with the ignore positions without numeric assessmernts. Allowing EPD to ignore branches would be nice but that can be handled by building you own epd file, albeit a pain. Perhaps a color flag could be placed on a move and the choice be given, like elsewhere, to skip branches that start with a particular color flag.
Thanks for adding the skipping blank/null numeric assessments when backsolving to the suggestion/request list but assigning it a low priority makes me sad. If anyone is interested in how I would use this feature I would be happy to leave another long winded post.
Bogg
P.S.
Am I more confused than usual? I thought spelling errors were detected here. My fingers are acting on their own today and I hope to have caught all my typos.
.
. That translates to just over 3 minutes. I always analyze significantly longer than that. Why do you insist on these arbitrary limits? Even if you are using a 32 bit compiler 2^30 or 10^9 should be simple while allowing everyone to set whatever value they choose from 1 to 1,000,000,000 million nodes. You could even go back to thousands of nodes if a user doesn't like a minimum of 1 million nodes if you would just provide a field width that shouldn't take more than a few seconds to implement. One alter table command, and a couple of field length changes and a recompile. It would even be easier if you were using a 64 bit compiler or if your compiler supports 64 bit integers, then you could allow 2^62 or 4*10^18 and no worries about a thousands or millions multiplier which is probably at least a minor annoyance. Actually if your compiler only supports 32 bit integers I can give you the simple code to implement a 64 bit data type and to convert back and forth from text if you would like. It has been a while but I think I can still write some c code. If not, I can certainly put it in words. Simple math using higher precision than the natively supported data types isn't very difficult to implement. What format do the engines use to return the number of nodes? It looks like they return a 64 bit field or a long, probably variable length, text field. Either is fairly simple to deal with. One very simple method if the only operation is a value test is to simply put the first 9 digits or 30 bits in one field and the next 9 digits or 30 bits in the second field. To test you compare the high order fields and if the returned high order field is lower then you branch low, if higher you branch high, if equal you perform the same test on the low order fields. If no actual math is needed this simple method works well. If the value is returned in a variable length ascii string you could use 4 or 5 32 bit fields to support 16 or 20 digits. Just load the fields as above with groups of 4 characters each. As the highest ascii value is 39 there would be no problem with accidental negative values. Then just perform the tests as stated above. The binary comparisons will work fine on the ascii values, you just have to test more fields.
Head Geek at bookup.com