OpenChess

andreio wrote:It wasn't a typo. Is it reasonable to assume you'll win a lottery next week? No?! Then why is it reasonable to assume it is a typo when the odds are practically the same?

Because the type doesn't happen next week.
Is it reasonable for a lottery winner to assume he won the lottery, even though the probability of winning the lottery is 1 in a million? Yes, it is very reasonable.

If I show you a very rich person, what are the chances that he won the lottery? Clearly they are far higher than 1 in a million. You can't compare him with an arbitrary person. You have to compare him with the average "very rich" person. There are fewer of those, and many lottery winners are among them.

So you have to be very careful when doing statistics. In particular, you have to really understand what you are doing and what the numbers mean.

Looking for an explanation of the floating-point comparison, the best you can do is start with listing possible scenarios. Then for each of these scenarios, you calculate the probability of the floating-point comparison getting into the code. Only if that probability is astronomically small can you reject the scenario. It makes very little sense to compare the probabilities you get for different scenarios. Finding someone guilty is not about "what scenario has fewer somewhat less probable events that I happen to know of".

In the typo-scenario, the probability of it happening is small, but not ridiculously small. Typos happen quite often and this typo happens to be one that the compiler does not catch and does not result in misbehaving code. When writing thousands of lines of programming code, difficult to discover typos are bound to happen. That it happened in precisely this place has by itself of course a very small probability, but it is the reason that we are talking about. Had it happened somewhere else, we would not have been discussing this quirk, but another one.

syzygy wrote:

andreio wrote:It wasn't a typo. Is it reasonable to assume you'll win a lottery next week? No?! Then why is it reasonable to assume it is a typo when the odds are practically the same?

Because the type doesn't happen next week.
Is it reasonable for a lottery winner to assume he won the lottery, even though the probability of winning the lottery is 1 in a million? Yes, it is very reasonable.

If I show you a very rich person, what are the chances that he won the lottery? Clearly they are far higher than 1 in a million. You can't compare him with an arbitrary person. You have to compare him with the average "very rich" person. There are fewer of those, and many lottery winners are among them.

So you have to be very careful when doing statistics. In particular, you have to really understand what you are doing and what the numbers mean.

Looking for an explanation of the floating-point comparison, the best you can do is start with listing possible scenarios. Then for each of these scenarios, you calculate the probability of the floating-point comparison getting into the code. Only if that probability is astronomically small can you reject the scenario. It makes very little sense to compare the probabilities you get for different scenarios. Finding someone guilty is not about "what scenario has fewer somewhat less probable events that I happen to know of".

In the typo-scenario, the probability of it happening is small, but not ridiculously small. Typos happen quite often and this typo happens to be one that the compiler does not catch and does not result in misbehaving code. When writing thousands of lines of programming code, difficult to discover typos are bound to happen. That it happened in precisely this place has by itself of course a very small probability, but it is the reason that we are talking about. Had it happened somewhere else, we would not have been discussing this quirk, but another one.

I hate to burst your bubble, but MOST rich people are NOT "lottery winners." Most rich folks are too damned smart to waste money on odds that remote. The majority of lottery winners do not end up rich. They end up broke. Again. Because they didn't know how to manage their money in the first place.

syzygy wrote: Because the type doesn't happen next week.
Is it reasonable for a lottery winner to assume he won the lottery, even though the probability of winning the lottery is 1 in a million? Yes, it is very reasonable.

In that case I can get you in touch with a really nice Nigerian guy. Even though the winnings are mine, I'll be generous, I'll give you a half .

syzygy wrote: In the typo-scenario, the probability of it happening is small, but not ridiculously small. Typos happen quite often and this typo happens to be one that the compiler does not catch and does not result in misbehaving code. When writing thousands of lines of programming code, difficult to discover typos are bound to happen. That it happened in precisely this place has by itself of course a very small probability, but it is the reason that we are talking about. Had it happened somewhere else, we would not have been discussing this quirk, but another one.

I don't really care how it did get there or if it has any significance at all. I just don't like people pretending it is a reasonable explanation, it's not. Probability for this particular typo is very, very small. Ridiculously small.

It wasn't a typo. Is it reasonable to assume you'll win a lottery next week? No?! Then why is it reasonable to assume it is a typo when the odds are practically the same?

Seriously though. That was about failed logic.

Logic dictates:

If P then Q
P
-----------
Q

In plain English: If P happens we'll get Q. P happened. Then logically we get Q.

P: Chances are very small
Q: It's unreasonable to assume it will happen

Your chances to win a lottery are very small. P happened. Then logically we get Q: It's unreasonable to assume you will win.
Chances it was this particular type of typo are very small, thus logically it's unreasonable to assume this typo will happen. Saying it is reasonable is illogical. That is what the quote was all about.

And chances this particular type of typo occurred are very small. There are a whole series of extremely infrequent events that have to happen in order for it to be a typo.

First of all, Rajlich needed to use a keyboard with US layout. Odds may not be low, but it's not given. He lives in Europe nonetheless and vast majority of numpad layouts has comma there, not a dot as decimal point.

Then, since he is a professional and pros do not waste time, because time is money, there is no reason at all for him to use numpad to type 0 when all you have to do is to lift your finger. All the characters you need are there: "(", ")", "0". It's not a spreadsheet. Odds are very low.

Then he had to press two keys at the same time. Not only that, hard enough that both of them would have been recorded. Rare. Most of the time it's either a case of a missing character, permutation (for example, ht instead of th) or substitution (when you hit a nearby character instead). But it doesn't stop there. He also must not notice that he hit two keys. And also must not see the extra character on the screen, both dot and an extra white space it added. All of this given that he had more time to discover this than usual, because he had to move his hand back from the numpad.

He wasn't retyping the code, right? So, he had to evaluate the statement too, again without noticing anything weird. And let med tell you neither "> .0)" nor "> 0.)" [or if you desire "(.0 <" and "(0. <"] looks normal. It's not a common pattern, thus it stands out pretty easily when you type the code in. Again, he is a pro, odds are extremely low.

Maybe he thought it was funny when he saw it in the original.
Maybe he considered doing floating point timing (I have done that in chess programs before) and then changed it back.
Maybe he literally copied that line right out of Fruit and then right above it wrote:
/* I took this from Fruit 2.1 by Fabian Letouzey */
which would probably render that line as fair use.
Every one has shown how it is impossible to put 0.0 in the code where you mean 0. But Fabian did it, so how impossible can it be?

andreio wrote:Your chances to win a lottery are very small. P happened. Then logically we get Q: It's unreasonable to assume you will win.

Did you read what I wrote?

The chances that an arbitrary person's neighbour has won the lottery are very small. However, if I preselect my arbitrary person to be a neighbour of a lottery winner, then the chances that this arbitrary person's neighbour has won the lottery are 1.

People often are not aware of the influence of preselection when judging the probability of events. This includes judges, unfortunately.

What are the chances that an arbitrary person writes a chess engine achieving an ELO rating of 2800? Those are very very low.

Hey look, Vas wrote a chess engine that achieved 2800 ELO. What are the chances of that! He must be guilty of something!

First of all, Rajlich needed to use a keyboard with US layout. Odds may not be low, but it's not given. He lives in Europe nonetheless and vast majority of numpad layouts has comma there, not a dot as decimal point.

Keyboards with US international layout are rather common in Europe, though it depends on the country. I have never seen a numerical keypad with a comma, but maybe I wasn't looking. Btw, the dot is on the same key as the > on my keyboard.

Anyway, for me the most logical explanation is that Vas converted back and forther between float and int. Why not? Many engines use floats for timing. Did anyone notice that the reverse-engineered "go" parsing function has another 0.0 used to initialise a global variable (apparently timing related, but this is hard to check given that the symbol names were made up)? But it could have been a typo as well. It's just impossible to know.

And let med tell you neither "> .0)" nor "> 0.)" [or if you desire "(.0 <" and "(0. <"] looks normal.

But "med" does look normal to you? (And what about ">.0")

Look, the compiler does not catch this typo. How many programs you wrote that you compiled for the first time did not have typos? Whenever I add 20 lines of there will be a typo. The compiler catches almost all of them. But not this one.

hyatt wrote:I hate to burst your bubble, but MOST rich people are NOT "lottery winners." Most rich folks are too damned smart to waste money on odds that remote. The majority of lottery winners do not end up rich. They end up broke. Again. Because they didn't know how to manage their money in the first place.

How relevant.

andreio wrote:

It wasn't a typo. Is it reasonable to assume you'll win a lottery next week? No?! Then why is it reasonable to assume it is a typo when the odds are practically the same?

[snip]

First of all, Rajlich needed to use a keyboard with US layout. Odds may not be low, but it's not given. He lives in Europe nonetheless and vast majority of numpad layouts has comma there, not a dot as decimal point.

Then, since he is a professional and pros do not waste time, because time is money, there is no reason at all for him to use numpad to type 0 when all you have to do is to lift your finger. All the characters you need are there: "(", ")", "0". It's not a spreadsheet. Odds are very low.

Then he had to press two keys at the same time. Not only that, hard enough that both of them would have been recorded. Rare. Most of the time it's either a case of a missing character, permutation (for example, ht instead of th) or substitution (when you hit a nearby character instead). But it doesn't stop there. He also must not notice that he hit two keys. And also must not see the extra character on the screen, both dot and an extra white space it added. All of this given that he had more time to discover this than usual, because he had to move his hand back from the numpad.

He wasn't retyping the code, right? So, he had to evaluate the statement too, again without noticing anything weird. And let med tell you neither "> .0)" nor "> 0.)" [or if you desire "(.0 <" and "(0. <"] looks normal. It's not a common pattern, thus it stands out pretty easily when you type the code in. Again, he is a pro, odds are extremely low.

I wonder how close ">' and '.' are in a keyboard, not in the numerical pad.

Miguel

User923005 wrote:Maybe he thought it was funny when he saw it in the original.
Maybe he considered doing floating point timing (I have done that in chess programs before) and then changed it back.
Maybe he literally copied that line right out of Fruit and then right above it wrote:
/* I took this from Fruit 2.1 by Fabian Letouzey */
which would probably render that line as fair use.
Every one has shown how it is impossible to put 0.0 in the code where you mean 0. But Fabian did it, so how impossible can it be?

Who has shown this? I type a floating point zero as 0.0 every time. 0. seems unnatural to me. As does .0

I think that if one sees a floating point constant of zero, it was entered as 0.0 at least 99% of the time. Or if you are writing raw asm code, "fldz" would be what I would use.

mballicora wrote:

andreio wrote:

It wasn't a typo. Is it reasonable to assume you'll win a lottery next week? No?! Then why is it reasonable to assume it is a typo when the odds are practically the same?

[snip]

First of all, Rajlich needed to use a keyboard with US layout. Odds may not be low, but it's not given. He lives in Europe nonetheless and vast majority of numpad layouts has comma there, not a dot as decimal point.

Then, since he is a professional and pros do not waste time, because time is money, there is no reason at all for him to use numpad to type 0 when all you have to do is to lift your finger. All the characters you need are there: "(", ")", "0". It's not a spreadsheet. Odds are very low.

Then he had to press two keys at the same time. Not only that, hard enough that both of them would have been recorded. Rare. Most of the time it's either a case of a missing character, permutation (for example, ht instead of th) or substitution (when you hit a nearby character instead). But it doesn't stop there. He also must not notice that he hit two keys. And also must not see the extra character on the screen, both dot and an extra white space it added. All of this given that he had more time to discover this than usual, because he had to move his hand back from the numpad.

He wasn't retyping the code, right? So, he had to evaluate the statement too, again without noticing anything weird. And let med tell you neither "> .0)" nor "> 0.)" [or if you desire "(.0 <" and "(0. <"] looks normal. It's not a common pattern, thus it stands out pretty easily when you type the code in. Again, he is a pro, odds are extremely low.

I wonder how close ">' and '.' are in a keyboard, not in the numerical pad.

Miguel

How often do you type "shift+key" and then "key" accidentally? I can't recall it ever happening to me. Doesn't mean it hasn't, but it is not common. And heaven knows that in a C program, I type {} all the time, and have yet to see a {[ or }] with that accidental bracket inserted by accident... Ditto for () with never a (9 or )0 typed in by mistake. I'm not sure this line of reasoning is valid at all. It is WAY down on the "list of plausible explanations"...

mballicora wrote: I wonder how close ">' and '.' are in a keyboard, not in the numerical pad.

Well, Miguel, this will depend on the keyboard layout. It could be as many as 8 characters between. If we assume for a second that we are talking about US layout, then it's the same key. Which would mean that you would need to use the shift key. Obviously, you are not going to double tab the key without noticing, especially because you have to release the shift key in between. So, the only sensible option is that you release shift while holding the . key. Unfortunately, there's one little thing called "auto repeat delay" that virtually renders this as a non-option.

syzygy wrote: But "med" does look normal to you? (And what about ">.0")

As the matter of fact it does. It is an extremely frequent word that I see, hear and type in countless number of times on daily basis. Not an English one though. This also underlines my point about common patterns. I saw nothing wrong with it, because it's common to me. You, on the other hand, spotted it right away, likely because it is uncommon to you. There is nothing common about > .0, that's why it's hard to believe you would overlook it.