hash collisions

[bob]

Sorry, but I have worked on a "bank program". It is nowhere NEAR as complex as a chess program. A million lines of code has nothing to do with algorithm complexity, just the amount of "work" that has to be done. Amazing how you are an expert on everything, and then wrong about everything as well.

[chrisw]

Sorry, but I have worked on a "bank program". It is nowhere NEAR as complex as a chess program.

You mean you were allocated a non-complex task? I guess, fortunately for the bank, someone in damage control saw you coming.

A million lines of code has nothing to do with algorithm complexity, just the amount of "work" that has to be done. Amazing how you are an expert on everything, and then wrong about everything as well.

We’re both idiots. It’s just that I know it and you don’t.
Also I bluff better, your insufferable overbearing rightness on everything is a dead giveaway.

[bob]

No. I wrote the ENTIRE thing. Also the ENTIRE code for a software package that was used by several clinics in Mississippi. Accounts receivable, accounts payable, patient accounts, recording office visits and what was done. Billing insurance (which is messy but not complex). A ton of built in reports, to trace each data entry station, display doctor production reports. And NONE of that was complex, just big.

Again, a swing and a miss.

You have to know that eventually you strike out.

[chrisw]

No. I wrote the ENTIRE thing. Also the ENTIRE code for a software package that was used by several clinics in Mississippi. Accounts receivable, accounts payable, patient accounts, recording office visits and what was done. Billing insurance (which is messy but not complex). A ton of built in reports, to trace each data entry station, display doctor production reports. And NONE of that was complex, just big.

Again, a swing and a miss.

You have to know that eventually you strike out.

Yeah, haha, a non-complex bank project. let’s get back to chess engines. Chess engines are not banks.
Chess engines are composed of a few simple, testable, self-contained modules that take input and give an output without stomping on other objects. Absolutely no reason why you, or anyone else, can’t reliably construct such modules, guaranteed, and link them together where they perform the same code over and over and over again. It’s neither rocket science nor banking.

I repeat, you are personally massively invested in bigging up the complexity of chess programming.

[Rebel]

As far as I am concerned the discussion is about the possibility of bug-free software. From recent previous posts:

Me:

2. Unless I misunderstand, you pretend it's impossible to write 100% bug free code. I think you are wrong.

You:

2) You are correct, except that (a) I don't pretend, I know ...

As such it doesn't make sense to list examples of inferior software, bugs are part of programming, to assume (or in your words to know) not all can't fixed is a lack of imagination or underestimation of the capabilities of others. As lone individuals writing chess engines we don't have the resources to do expensive, time consuming test methodologies, beta test procedures before we release. (Y)our experiences as lone individuals are not a good measuring rod.

[abulmo2]

As lone individuals writing chess engines we don't have the resources to do expensive, time consuming test methodologies, beta test procedures before we release.

In writing Amoeba, as a lone individual, I spent 99.9% of my time testing and 0.1% writing code. I have limited financial resources, but I have an invaluable resource: time.

[bob]

As far as I am concerned the discussion is about the possibility of bug-free software. From recent previous posts:

Me:

2. Unless I misunderstand, you pretend it's impossible to write 100% bug free code. I think you are wrong.

You:

2) You are correct, except that (a) I don't pretend, I know ...

As such it doesn't make sense to list examples of inferior software, bugs are part of programming, to assume (or in your words to know) not all can't fixed is a lack of imagination or underestimation of the capabilities of others. As lone individuals writing chess engines we don't have the resources to do expensive, time consuming test methodologies, beta test procedures before we release. (Y)our experiences as lone individuals are not a good measuring rod.

Not sure how to proceed. You said "banks don't tolerate errors" or something to that effect. So I gave some counter-examples where really BIG banks had been bitten by really serious bugs. Pick some application you like and I'll see what I can dredge up. You mentioned Fruit 2.1... Fabien, for some strange reason or another, released versions through 2.3.1. I don't have any of that source to read his comments.

Most software engineering books give a bunch of case studies in the last half. Examples where the specifications had ambiguities or omissions; Cases where the design didn't match the specs. Cases where the programming didn't match the design, cases where the testing was not done correctly, and finally cases where everything along the way was done "by the book" and yet the software STILL had problems, some serious, some not so serious.

I've already given quotes showing that the consensus is that you can't test away all bugs. You can eliminate a lot. But if you were to plot the number of bugs discovered on the y axis, time on the x axis, you would get a somewhat parabolic shape with the max at the beginning, and the fewest bugs detected at whatever the current date is. But it never reaches zero.

As far as # of testers... how would you rate IBM? MicroSoft? Apple? Google? Linux? GCC? All of those have LARGE testing staff. And yet bugs still are released, and some of them fixed as time moves on. So if IBM can't do it, who can? Who is this mythical all-knowing group that can test any piece of software and eliminate every last bug before the software is released? It would be earth-shattering news and would certainly make all of the SE texts since it would be a "first".

BUT, just to come back around full circle, "debugged chess program." NOW you say "As lone individuals writing chess engines we don't have the resources to do expensive, time consuming test methodologies, beta test procedures before we release. (Y)our experiences as lone individuals are not a good measuring rod." So which is it? Chess programs have bugs? Or they don't have bugs. Can't possibly be both. I claim they do. You just explained why they do. So why the argument???

[bob]

As lone individuals writing chess engines we don't have the resources to do expensive, time consuming test methodologies, beta test procedures before we release.

In writing Amoeba, as a lone individual, I spent 99.9% of my time testing and 0.1% writing code. I have limited financial resources, but I have an invaluable resource: time.

I also have a lot of time. But I also have access to huge computing resources. I have literally played many millions of games during testing, also. And in spite of all the effort, and all the games played, I STILL find the occasional bug. And will continue to do so based on experience. I'm sure Ed/Chris will just say I am a lousy programmer and they can do much better. I'd first like to see their program(s) that can beat mine; and then have time to carefully examine their programs for the presence of bugs. It's easy to talk a good game. MUCH harder to actually write that bug-free code. And convince anybody that is actually IS bug-free.

[Dann Corbit]

"Not sure how to proceed. You said "banks don't tolerate errors" or something to that effect. "

When I was in the military, I had a friend named Paul Abeyta. We were serving in Turkey, and had an APO address, so mail had serious.lag time. His bank statement came and it said that he had 333000 in the bank when it should have said 3000. So he wrote a letter to the bank explaining the problem. They said, all is fine, no mistake. So he wrote another letter. Now, they found that one day's.receipts from Exxon of Florida got deposited in his bank. The Exxon account was the compliment bitwise and somehow the bits got flipped. So they took out the money. Problem is, they took out ALL of the money, even Paul's. Now remember, this an overseas APO in 1980, so he has checks bouncing for six weeks before the matter is settled. Just goes to show, "No good deed will go unpunished."

Now, the standard for banks, plane guidance systems and medical equipment should be very high. But sloppy programming and undefined behavior can happen anywhere. I do think that we want people to exercise due diligence, especially with things like our lives and our money.

[Ovyron]

As far as # of testers... how would you rate IBM? MicroSoft? Apple? Google? Linux? GCC? All of those have LARGE testing staff. And yet bugs still are released

For Microsoft the story is very interesting, for Windows at some point they decided that bug testing wasn't worth the cost and basically laid off their entire testing team and instead relied on reports by their customers to fix bugs (the customers became beta testers that worked for free), which led to Windows 10 being the most buggy OS in the history of the company. This video elaborates on that.