hash collisions

[bob]

I don't think you can answer that. I have seen simple 50K line programs and incredibly complex 5K line programs. The complexity of a chess program is not JUST in the lines of code.

It is also hard to compare something like Stockfish to Crafty. Crafty has its own book code, including code to create the book, book learning, pretty complex SMP search, code really optimized for speed rather than clarity/simplicity. code to support most everything, not relying on the GUI to take care of most of the dirty work. And of course, C++ templates adds to this for C++ programs.

And I still do not believe there is a 100% bug-free chess program. If someone claims such, HOW was the claim verified? Certainly not with automated tools. Certainly not by the author reading the code (reading what he meant, not what he wrote). Certainly not with sufficient test cases to cover everything, including all the potential parallel race conditions. In the case of Crafty, I have run tens of thousands of test positions. Played hundreds of millions of actual games. And STILL find an occasional unintentional behavior that might cause a crash, or just a one line item that catches my eye as not quite right.

For testing, assume Crafty (using your 22K lines of actual code which sounds about right since I make extensive use of comments). Assume one of every 10 lines of code is a branch. So 2200 lines. To completely test every possible path through the program requires 2^2200 test cases. Just a tad on the big side. And that ignores testing each and every condition within a branch, just determining "test is true or false." An absolutely impossible problem. Let's reduce it to one of every 100 lines of code (Crafty is much higher by the way (it has 4400 if statements and that ignores conditional assignments ("?"). 2^220 is STILL an impossible number of test cases. So bug-free can't be proven by testing. What about software verification? JUST as hard if not harder.

So, in the absence of a real "proof" nothing about correctness can be claimed. A program might be believed to be bug free, but that is it. Software engineering is a well-known discipline. The best it claims is to MINIMIZE or REDUCE the number of bugs present in a program. Nobody in the SE field claims to be able to produce a program of any size that is bug-free. We can verify small programs with tools, but emphasis on "small". And it has really been this way for 50 years now. Better design methodologies reduce bugs. Emphasis on reduce which is != to eliminate.

[bob]

Stuff should just work. Period.

Try flying in your car by driving it off a cliff. Should just work. Period.

Don't forget to come back here to tell us how it went!

Or run into a patch of ice. Or run out of gas. Or have a blow out. Or have a mechanical failure when something wears out. There are way too many edge conditions to test them all. Not to mention space aliens that could come down and reverse the flow of electricity so that electrons go from positive pole to negative. Can't count how many transistors and diodes would fail. You COULD fix this with a bridge rectifier on every single circuit. Should you? And that is just a few of the potential problems the auto software / hardware would have to deal with.

The idea of "bug free" is simply nonsensical for anything more complex than a screwdriver or something similar, and I have broken my share of those over the years, one of the simplest "machines" known.

For something like EPD parsing, one can write correct code. There are not that many conditional tests to deal with. And the EPD specification is clear. But that is _simple_ code. About 150 executable lines in crafty, maybe 100-125 depending on how you count. But in a SMP program, you would have to take the (say) 5000 lines of code, which would turn into (say) 50,000 lines of asm, and then execute 2 parallel threads with every possible timing possible. That is an impossible number to even conceive. IE each line of ASM in one thread could be executed in parallel with, or in between every asm instruction in the other thread. And that is just a warm-up. Ditto for every two instructions, then every three, ... And then every possible combination of instructions executed between any two (or more) instructions in the other thread. This will NEVER be proven correct.

One example to end. A couple of weeks ago, I was playing games Crafty VS Crafty. I was watching their output reasonably carefully, and saw nothing wrong. As I came back, I noticed an oddity where a move failed low at the root, but the first PV after that was not the same move (which it should be in Crafty). I looked for a good while to find a very subtle race condition. I wrote some code to run back through several thousand games I had saved. Found this happening TWICE. In both of those cases it had no effect on the game. But what if that fail low move was STILL the best move? If this was the final iteration, it would not have been played. So out of several thousand games, two were suspect, and neither affected the game in the least. How many games before this issue DID cause a problem? Unknown. Probability of seeing it before it actually happened? Infinitesimally small. And how to look for such a case with an automated tool, having no idea what kind of error indication you would get until it actually happened and was spotted. No amount of testing showed this. In over 100K test positions, not one time did this cause Crafty to play the wrong move.

As you know, this is a debate not worth having. What we wish and reality rarely match exactly.

[lucasart]

Chess programs are pretty large.

Chess programs are trivial. Their beauty lies is in the algorithms they use.

I've just looked and Crafty is 24.7k sloc (including 3rd party tablebase code of course), StockFish is 6.2k, Demolito is only 2.2k...
Cheng is 14.6k because I did a bad job, I admit. Still very small programs.

Demolito could easily fit in 2k lines, if I removed all the "useless" code that serves only for developpement. But this code is useful for me, so I'd rather keep it

But to make a fair comparisin, one would have to add syzygy to Demolito first.

[chrisw]

Stuff should just work. Period.

Try flying in your car by driving it off a cliff. Should just work. Period.

Don't forget to come back here to tell us how it went!

You admitted to it. Now everybody knows. Your engine(s) visit and evaluate impossible parts of the tree, ...

once in a billion nodes...

degrading performance in unknown ways, ...

correction: speeding up the search in a calculated way

you know it, you could very easily fix it, ...

correction: spoil it

but you don't care.

correction: but I care a great deal to keep it optimal.

Enough. You know my opinion.

All you made clear is that you live in a fantasy world, where everything is the reverse from reality. You did not manage to get a single point right.

It’s always revealing, that which people snip. That and lengths they’ll go to twist or snip or name call and remain standing.

100% bug free chess program is entirely possible, but not for programmers with bad attitude.
Write defensively, test, test and test again, include extensive internal validation, submit to quality control, and you’ll get there, if you want. If you’re not that bothered, then you won’t. I also used to believe just like you guys, there is no such thing as 100% no bugs, but then I met Japanese quality control. 100% no bugs is demanded, expected and nothing less accepted. Thus it gets delivered.

[hgm]

You don't like it when your stupidity receives extra attention?

[Ovyron]

100% bug free chess program is entirely possible

Did you really put Stockfish as an example? It has several bugs, all you need to do is check the commit list on github, and you'll see bugs are found and fixed all the time. How is this possible if it doesn't have bugs?

In the following months the list will contain commits of bugs found, and fixed, and those bugs are there *now*, still to be discovered and fixed, which proves it has many bugs, and it even probably has bugs that will take years to discover and fix.

[hgm]

Well, 'possible' here should be read as "existing in his imaginary world", where he would get a great kick out of firing the developers from Stockfish for being 'unemployable incompetents'.

BTW, I believe micro-Max to be entirely bug-free. With merely 100 lines of code I think it should be feasible to ascertain that. Not by testing, but by code inspection. Of course it has a few undesirable properties that came as a side effect of its design goal, such as that it sometimes loses on time, mainly in positions that would have been lost anyway. But these are not bugs, but an intentional feature.

[chrisw]

100% bug free chess program is entirely possible

Did you really put Stockfish as an example? It has several bugs, all you need to do is check the commit list on github, and you'll see bugs are found and fixed all the time. How is this possible if it doesn't have bugs?

In the following months the list will contain commits of bugs found, and fixed, and those bugs are there *now*, still to be discovered and fixed, which proves it has many bugs, and it even probably has bugs that will take years to discover and fix.

Mostly clean-ups and modifications. Any project in continual development will have bugs. Question is whether an official release has bugs. Last one with a full year of usage was Stockfish 10, you have a list of actual real bugs and how they were dealt with?

[chrisw]

You don't like it when your stupidity receives extra attention?

Hahahaha! 100% no bugs for chess engines is entirely possible, the mechanics of moving the six pieces in defined ways over 64 squares and performing recursive search are quite trivial. Programmers who won’t work to 100% bug free methods are a liability and unemployable. Yes, that’s my opinion and it’s pretty much all I wrote on the topic. Somehow this has tripped your ego and you resort to silly put downs, well okay, I’m well used to dealing with that too.

[hgm]

Have you been smoking something bad? You seem no longer be able to distinguish me from Bob. It was not me who argued about the 100% bug-free. I even pointed out that my engine is.

If you didn't already have the reputation of being totally detached from reality, your performance in this thread would have convinced any reader of it in one big swoop. You don't seem to be able to grasp what people write, and who writes what. When I say I consider it important for efficiency to search impossible line, and explain preciely why I consider that better, you interpret it as that I don't care to 'fix' it...

Are you too stupid or doped to understand plain English, are you a compulsive liar who obsessively twists other peoples words, or what?