3 ms·

The answer is that the bugs the article claims are corners cases, most of which will not matter in most practical uses of floating point maths... and some of wh

The answer is that the bugs the article claims are corners cases, most of which will not matter in most practical uses of floating point maths... and some of which will is due to not emulating a weird IEEE floating point rule about rounding numbers of the form N.5 to the even number instead of up like everyone is taught in school. So "wrong" as used in the article simply means "not the same as the IEEE behavior", not "wrong" as in "wildly inaccurate". It matters if you want 100% exact emulation to get identical results. It doesn't if you don't and just want speed.

CydeWeys 6y ago
> some of which will is due to not emulating a weird IEEE floating point rule about rounding numbers of the form N.5 to the even number instead of up like everyone is taught in school. Round-to-even (also known as banker's rounding, because it's used in finance too) isn't weird at all. It minimizes rounding error, especially on repeated calculations. The rounding rule that everyone learns in elementary school is bad and results in systematically biased computations. We can and should do better than that flawed approach. This post explains it in more depth: https://mathematica.stackexchange.com/a/2120 https://mathematica.stackexchange.com/a/2120
phkahler 6y ago
>> The answer is that the bugs the article claims are corners cases, most of which will not matter in most practical uses of floating point maths... Most bugs are corner cases of one sort or another. At the application level you can decide how important the corners are. When you're creating a math library that many others are going to use, and there is a standard, I think the expectations should be higher.
brucedawson 6y ago
I recently saw a talk (internal only unfortunately) about how some "minor" changes in sin/cos/whatever functions in Chrome broke multiple web sites. It was things like mapping sites and the "minor" changes in the output of sin led to huge errors in the maps. Which is to say, that minor errors often don't matter, but if you are offering up a general purpose solution then those minor errors probably matter to _somebody_.
- perl4ever 6y ago
  It seems to me a bug is socially constructed based on whose assumption(s) are defined as valid. It emerges out of an implicit power struggle among the entities whose interaction reveals the "bug". To know whose bug it was in your example, you have to make a value judgment about whether the changes were minor and justified, not just a technical evaluation.
  - brucedawson 6y ago
    I'd say that for most bugs there is a fairly clear right/wrong rather than a social construction. This bug contains both, I think. The correct result for round(5.5) is arbitrary. The reason that 6.0 is the correct answer is "merely" because that is what the IEEE standard says. That standard could have been different (round-to-nearest odd), but there is value in not lightly ignoring an existing standard. Other cases are more clear cut. ceil(1e-10) should return 1. This seems non-controversial since ceil is defined as rounding up. Any number greater than zero and less than or equal to one should return one. And yet, some of the algorithms would return zero. That was probably the most serious of the errors. How serious the errors are depends on how the functions are used, but I think they were all promoted as general-purpose-replacements so they could have ended up being used anywhere.

CydeWeys 6y ago

> some of which will is due to not emulating a weird IEEE floating point rule about rounding numbers of the form N.5 to the even number instead of up like everyone is taught in school. Round-to-even (also known as banker's rounding, because it's used in finance too) isn't weird at all. It minimizes rounding error, especially on repeated calculations. The rounding rule that everyone learns in elementary school is bad and results in systematically biased computations. We can and should do better than that flawed approach. This post explains it in more depth: https://mathematica.stackexchange.com/a/2120 https://mathematica.stackexchange.com/a/2120

phkahler 6y ago

>> The answer is that the bugs the article claims are corners cases, most of which will not matter in most practical uses of floating point maths... Most bugs are corner cases of one sort or another. At the application level you can decide how important the corners are. When you're creating a math library that many others are going to use, and there is a standard, I think the expectations should be higher.

brucedawson 6y ago

I recently saw a talk (internal only unfortunately) about how some "minor" changes in sin/cos/whatever functions in Chrome broke multiple web sites. It was things like mapping sites and the "minor" changes in the output of sin led to huge errors in the maps. Which is to say, that minor errors often don't matter, but if you are offering up a general purpose solution then those minor errors probably matter to _somebody_.

perl4ever 6y ago
It seems to me a bug is socially constructed based on whose assumption(s) are defined as valid. It emerges out of an implicit power struggle among the entities whose interaction reveals the "bug". To know whose bug it was in your example, you have to make a value judgment about whether the changes were minor and justified, not just a technical evaluation.
- brucedawson 6y ago
  I'd say that for most bugs there is a fairly clear right/wrong rather than a social construction. This bug contains both, I think. The correct result for round(5.5) is arbitrary. The reason that 6.0 is the correct answer is "merely" because that is what the IEEE standard says. That standard could have been different (round-to-nearest odd), but there is value in not lightly ignoring an existing standard. Other cases are more clear cut. ceil(1e-10) should return 1. This seems non-controversial since ceil is defined as rounding up. Any number greater than zero and less than or equal to one should return one. And yet, some of the algorithms would return zero. That was probably the most serious of the errors. How serious the errors are depends on how the functions are used, but I think they were all promoted as general-purpose-replacements so they could have ended up being used anywhere.