hash collisions

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

User avatar
Rebel
Posts: 6991
Joined: Thu Aug 18, 2011 12:04 pm

Re: hash collisions

Post by Rebel »

bob wrote: Sun Feb 23, 2020 10:56 pm
Rebel wrote: Sun Feb 23, 2020 10:22 pm
bob wrote: Sun Feb 23, 2020 7:47 pm How can this be? Ed writes bug-free code?
I hope not :D in fact I stopped working on playing strength in 2016 after the realization that during the years a bug slipped in that made the result of matches unreliable. For example, a cutechess match of 10,000 games could give 51.8% with a LOS of 100% while running it again it could produce a negative < 50% score. That's insanity.

I recently fixed the bug, now I only have to redo approximate 7-8 years of promising candidate engine changes :D

Happy now?
Why would you lie about that?
What ?!

Explain yourself.
90% of coding is debugging, the other 10% is writing bugs.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: hash collisions

Post by bob »

Rebel wrote: Sun Feb 23, 2020 9:48 pm
bob wrote: Sun Feb 23, 2020 7:42 pm Here's an interesting quote from Ed circa 2019 (last year): "90% of coding is debugging, the other 10% is writing bugs." Hardly sounds like writing bug-free code.
It's hard to imagine you miss the humor of my signature.
As far as writing bug-free code of any size, "you are a legend in your own mind." NOBODY else agrees with you. And haven't since the late 60's...
Plenty bug-free downloadable software on the internet IMO.
OK, let's try this ONE TIME. You pick some downloadable software package that has 10K lines of code or more. But you only get ONE try. I'll take a look and see what I can dig up in terms of bugs fixed in recent history and open bugs that have not been fixed. I think you are going to find this to be a difficult task. But feel free to prove me wrong. Internet software has MORE bugs than commercial software. Design, coding and testing are ad hoc. It is worked on part-time. No one gets paid so there is no real impetus to produce and then test code in a serious way. Even Linux sees a TON of bugs in every version. As does GCC. Mozilla. Open office. SQL. VI, etc.

Waiting for you to identify this marvel program.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: hash collisions

Post by bob »

Rebel wrote: Sun Feb 23, 2020 11:19 pm
bob wrote: Sun Feb 23, 2020 10:56 pm
Rebel wrote: Sun Feb 23, 2020 10:22 pm
bob wrote: Sun Feb 23, 2020 7:47 pm How can this be? Ed writes bug-free code?
I hope not :D in fact I stopped working on playing strength in 2016 after the realization that during the years a bug slipped in that made the result of matches unreliable. For example, a cutechess match of 10,000 games could give 51.8% with a LOS of 100% while running it again it could produce a negative < 50% score. That's insanity.

I recently fixed the bug, now I only have to redo approximate 7-8 years of promising candidate engine changes :D

Happy now?
Why would you lie about that?
What ?!

Explain yourself.
You said you had a bug in your program. That has to be a lie because you and Chris are claiming the two of you can produce bug-free code. Sarcasm, anyone?
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: hash collisions

Post by bob »

chrisw wrote: Sun Feb 23, 2020 9:52 pm
hgm wrote: Sun Feb 23, 2020 11:08 am You seem to miss the point. Resistance to fraud should be one of the key specifications of any system for dealing with money. It is a well-known fact that criminals do exist, no matter how much we might dislike that. Failing to care about fraud resistance is neglicence.

There are societies in which actions that encourage crime are a punishable offense themselves. I think one can be fined here for leaving one's car unlocked, because that encourages theft. (I am not sure if that still applies; I never had a car.) That doesn't make ransacking unlocked cars legal here.

And yeah, criminals can be clever. So we'd better make sure we are clever in protecting ourselves from them. Making it easy for them, just because they are not supposed to do what they do would be really stupid. So yes, the book publisher is at fault. You could argue that it is his own money he is putting up for grabs (like you would be putting your own unlocked car on offer...), so that it is OK for him to do this. But of course the money lost this way doesn't really come out of the pocket of the person that designed this system. It is the one that set this up that is guilty of criminal neglicience w.r.t. the publisher (be it his client or employer).
Well, you’re about as knowledgeable about economics and business as Bob. Namely a couple of laymen,
The punch card as he described it was an invoice/receipt, sent with the book by the book company. Invoices have positive numbers on them. Their opposite is an invoice with a negative number, otherwise known as a credit note.
Bob’s friend, who he described as a clever programmer, and performing something funny and boasting about it, forged a credit note by changing the sign. Is no different to reprinting an invoice with negative numbers and then presenting it for credit payment. Or forging a bank note, or a US treasury bill, all these things are legal Fiscal instruments, convertible to cash. Credit notes happen all the time and are not unreasonably assumed good, just as US treasuries are legal currency and assumed good at the point of presentation anywhere in the world. It isn’t the task of software or bought ledger clerks to reject invoices/credit notes, nor US dollars nor US treasuries. Fraud/forgeries, unless glaringly obvious, get discovered later when the double entry ledgers don’t match up at the end of the accounting period. Then a forensic search would reveal the fraud.
Bob describing the fraud as clever, and accusing the company of bugged software is just dumb. All it reveals, apart from the ethical fail, is Bob’s lack of knowledge of accounts. Which in turn suggests his story of writing bank software, all of it, can be brought into question. We’ll let you off, since you didn’t claim to write bank software.

Your argument about criminal negligence is framed by dislike of banks presumably? A parallel case would be of an old lady who left her purse on show, gets robbed by a criminal, who then spends her money and blames her for being stupid. Or criminally negligent as you would call it.
Funny how your argumentation positions are taken for entirely social reasons, when your claim is to just use straight logic. I don’t think so.
This is all bullshit. NOBODY will take an invoice and give you a refund WITHOUT verifying that the data is accurate in their database. This should have been caught on several levels. For example, how do you get a credit for something that was sent to you (and they know you received it because the card was in the package)? How do you allow a punched card to say someone owes/paid you a negative amount so that you have to refund it? Who in their right mind would design software so that you send THE billing document to and end user, and then obliviously use it when it comes back without any sort of validation? This was definitely a bug. Several bugs in fact. This was not a treasury bill. This was not a stock certificate. Wonder what would happen if you wrote a check for -200.00 and took it to a store and tried to use it to pay for groceries? Would the store accept it? Would the bank honor it? Nope, they at least do basic input validation today.

ALL of what you think you know about accounting is wrong. Sounds like a 1950's paper system. Not something computerized. I certainly would not accept input that could be bogus, then issue refunds based on that, and then catch it later in an electronic audit. THAT is yet another example of crappy/buggy code. Yet you say you don't write any. Above you gave a perfect description of a buggy system. again. You would actually write and deliver a piece of software that lets users write their own credit note, take money from you, then disappear? That would be a truly marvelous piece of computer programming. One that would make a freshman computer science major hang his head in shame and switch his major to basket weaving. You don't send someone an invoice, let them bring it back to you and pay them. An invoice is an invoice. Since YOU keep making up your own definitions, here is the widely accepted definition: "a list of goods sent or services provided, with a statement of the sum due for these; a bill." Anyone that lets the user convert that to anything else, or allows them to change any aspect of the invoice is a complete idiot that won't last long financially.

Your example about a little old lady's purse is nonsense. There is no input to verify. No output to verify. Can you come up with a less stupid example, as you look pretty sad with that one.

BTW MANY frauds are clever. And illegal. But STILL clever. The two words CAN apply to the same action. The guys that electronically clock a roulette wheel and win a lot of money doing so are clever. Tough to build a clocking device that goes undetected. It is also illegal in most US casinos (if not all, but I have not visited all so I don't know.) The cleverness of an idea has zero to do with its legality, and vice-versa.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: hash collisions

Post by bob »

chrisw wrote: Sun Feb 23, 2020 9:26 pm
bob wrote: Sun Feb 23, 2020 3:12 am
abulmo2 wrote: Sat Feb 22, 2020 11:08 pm
Rebel wrote: Sat Feb 22, 2020 9:56 pm 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.
Hilarious. Talk is all you do. Volume in inverse proportion to reality. Most if not all with one intention of bigging yourself and belittling everybody else.

MUCH harder to actually write that bug-free code. And convince anybody that is actually IS bug-free.
Well, Ed was convincing in the market place and in the demand for his chess engine code by electronics manufacturers, who by definition, are going to be very concerned that they are taking on bug-free code else they end up having to bin thousands of manufactured units. Me likewise, We get voted for by hard earned money, contracts for supply and capital wanting to invest, over a very extended period. You?
Let me think for a minute. I wrote/distributed over 100K lines of assembly language in a large operating system project. Nobody wanted bugs, it was a commercial product sold by Honeywell. I wrote a complete system, operating system up, for a digitally based remote cardiac monitoring system (first in the world). 1972. Nobody wanted bugs there for obvious reasons. I wrote a 150K line system for clinics to manage ALL of their internal data. Accounts receivable/payable, patient data, insurance filing, reporting to pay doctors based on their individual "production." Nobody wanted bugs. A 40K line virtual machine for the Xerox sigma 9 so that operating system development could be done while the system was in production running normal programs. Nobody wanted errors there. A RS232C multiplexor package that let a room full of terminals communicate over a small group of telecommunication lines, re-expanded on the other end into separate data streams connected to the computer. Nobody wanted errors there. CODEX was pretty clear, but THEY also recognized that errors were inevitable.

There are more if you want 'em. And that omits all the chess work, work done for the national labs, work done helping users at UAB use parallel threads to improve performance of large programs like CHARM (molecular modeling). Nobody wanted errors there while designing drugs.

Bet I have written FAR more code than you. Reliable, functional, and no doubt with bugs that testing did not show up. Based on your comments I doubt you wrote much of the code you sold, at all. Because if you had, you would know you had undetected bugs show up all the time. But in never-never-land, things are different?
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: hash collisions

Post by bob »

Another bug? perft says 156. :)
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: hash collisions

Post by bob »

Rebel wrote: Sun Feb 23, 2020 10:22 pm
bob wrote: Sun Feb 23, 2020 7:47 pm How can this be? Ed writes bug-free code?
I hope not :D in fact I stopped working on playing strength in 2016 after the realization that during the years a bug slipped in that made the result of matches unreliable. For example, a cutechess match of 10,000 games could give 51.8% with a LOS of 100% while running it again it could produce a negative < 50% score. That's insanity.

I recently fixed the bug, now I only have to redo approximate 7-8 years of promising candidate engine changes :D

Happy now?
Happy about what? It is an expected result. It happens all the time. Nobody thinks anyone is worse just because their code had/has a bug.

To me, your story is ho-hum. I've only seen that happen a few tens of thousands of times.
abulmo2
Posts: 433
Joined: Fri Dec 16, 2016 11:04 am
Location: France
Full name: Richard Delorme

Re: hash collisions

Post by abulmo2 »

Rebel wrote: Sun Feb 23, 2020 11:19 am
abulmo2 wrote: Sat Feb 22, 2020 11:08 pm
Rebel wrote: Sat Feb 22, 2020 9:56 pm 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.
Can you elaborate what the testing is about?
I am mostly testing for enhancements with SPRT; using my own tournament manager.
My development version is also quite different to the release version, as it contains many testing code: perft, epd test, etc.
I also use a language that is probably better at reducing bugs (the D language), as it uses a garbage collector and help to write things in less line of codes.
Is my program bug free? Unfortunately not. Probably half of the Elo of my program came from bugs removal and I guess there are still many of them to suppress.
Richard Delorme
User avatar
Rebel
Posts: 6991
Joined: Thu Aug 18, 2011 12:04 pm

Re: hash collisions

Post by Rebel »

bob wrote: Sun Feb 23, 2020 11:40 pm
Rebel wrote: Sun Feb 23, 2020 11:19 pm What ?!

Explain yourself.
You said you had a bug in your program. That has to be a lie because you and Chris are claiming the two of you can produce bug-free code. Sarcasm, anyone?
Wrong again.

Released software okay.

Wrong test methodology.

There you go again with your premature judgements.
90% of coding is debugging, the other 10% is writing bugs.
mar
Posts: 2555
Joined: Fri Nov 26, 2010 2:00 pm
Location: Czech Republic
Full name: Martin Sedlak

Re: hash collisions

Post by mar »

abulmo2 wrote: Mon Feb 24, 2020 1:12 am I also use a language that is probably better at reducing bugs (the D language), as it uses a garbage collector and help to write things in less line of codes.
I won't go into why I don't think garbage collection is the way to manage memory,
but I don't see how D is any safer than C or C++ or Pascal or any other unsafe language.
As long it allows unchecked references and pointers, it's no longer memory-safe the way Rust, Java or C# are
(I'm not talking about explict unsafe in Rust and C#).
C# has a very complicated way of making sure that references are handled safely and can't escape (extra limitations apply).
If you meant bounds checking on array access, then that's something that can be done easily (either using a wrapper around static arrays or ASAN where available)

EDIT: unless you meant something else than "safer" by "better at reducing bugs", of course
Martin Sedlak