The Floating-Point Guide (2010)
floating-point-gui.de
floating-point-gui.de
Even with a floating point processor you need to be careful when switching into and out of interrupts! The floating point core has it's own set of registers you need to keep track of. Doubles are even worse!
Basically it is almost always better to use integers when you can, and be aware of what types you are using (always important in C anyways).
Maybe there are better ways to do it, I could be wrong!
> Basically it is almost always better to use integers when you can
I'd say: understand the limitations of FP, but it's almost always better to use them unless you have some particular precision or performance requirement. Then again, my experience of FP is mostly in graphics, where IEEE 754 single precision is good enough for almost anything you'd want, and hardware FP is commonplace.
Called cos() when you meant cosf()? Done in software.
Multiplied by 2.25 when you meant 2.25f? Done in software.
-Wdouble-promotion will help you find those performance bugs.
$ python3 -c 'print(0.3 == 0.1 + 0.2)'
False
$ ruby -e 'puts 0.3 == 0.1 + 0.2'
false
$ perl6 -e 'say 0.3 == 0.1 + 0.2'
True fmt.Print(0.3 == 0.1 + 0.2)
// => true
Why does it have this result?
Yes. The behaviour is quite odd and unexpected. It seems they have different rules for when to apply the constant version of floating math than what constitutes actual compile time evaluation.
const a float64 = 0.1;
const b float64 = 0.2;
const x float64 = 0.1 + 0.2; // Const evaluation, "rational" math
const y float64 = a + b; // Const evaluation, IEEE-754 math
fmt.Println(x == y) // false ??!?
EDIT: Or how about this one:
const x float64 = 0;
fmt.Println(x + 0.1 + 0.2 == 0.1 + 0.2 + x ); // false!
fmt.Println(x + 0.1 + 0.2 == x + (0.1 + 0.2) ); // false!Go: Here's a trivial example.
https://docs.perl6.org/language/numerics#Rational
By irrational I am not joking, these sorts of number systems are complicated and glitchy, in this case with program-destroying magic like autoconversion to floating point when you hit a 2^64 denominator, and, don't click this URL, please, just read it:
https://docs.perl6.org/language/numerics#Zero-denominator_ra...
Could you expand on why it is a totally irrational idea? Seems pretty rational to me. But then I'm not really a mathematician.
> autoconversion to floating point when you hit a 2^64 denominator
Please note that this is after normalization. And it has come from practicality: having the denominator also be an BigInt, slows down the use of the Rational number significantly. However, if you do need that type of precision, then you can by using infectious FatRats: any expression with a FatRat, will result in a FatRat (unless explicitly coerced to something else, of course).
With regards to the Zero-denominator Rats: they are just special cases just as IEEE has special cases for -Inf, Inf and NaN. So what's the problem there?
Using imprecise but efficient-to-calculate-with-numbers for exact literals by default is probably the most pervasive premature optimization in all of computing.
This is exactly the same situation as with floating point numbers. In both cases you have a predetermined finite set of rational numbers, with exact rational arithmetic when you stay within those numbers, and deterministic rules when your operation exits this finite set.
> Using imprecise but efficient-to-calculate-with-numbers for exact literals by default is probably the most pervasive premature optimization in all of computing.
I do not see how this is a matter of precision nor efficiency. Floating point arithmetic was deemed more useful for general purpose for good reasons: the representable numbers are mostly scale-free, so that you do not care about the absolute size of your numbers (you can compute in armstrongs or in parsecs and obtain essentially the same results). With rational arithmetic using bounded integers, you cannot represent very large or very small numbers. On the other hand you can represent small fractions like 1/3, which is arguably useful in some cases, but not really a big deal in practice. There's no reason why rational arithmetic with bounded numerator and denominator could not be efficiently implemented in hardware as fast as floating point; I do not understand your point.
1. It does not use a predetermined finite set of rational numbers. It uses a bigint numerator and a 64-bit denominator.
2. Even the case of bounded numerator and bounded denominator would preserve more of the nice mathematical properties of rational arithmetic than IEEE 754 floating-point arithmetic does (e.g. the associativity of addition).
3. While the latter could be implemented in hardware, it is not implemented in hardware. The defaults for literals prefer the choice that is implemented in hardware, IEEE 754 floating-point. This is a premature optimization.
It does not preserve associativity of addition. If a = MAX_INT/1, b = 1/1, c = -1/1, then a + b is Infinity, and (a + b) + c is therefore also Infinity, while b + c is 0, so a + (b + c) is MAX_INT/1.
It does, if you use the mathematically natural addition operation (see my reply to enriquto). In the example above, the result is MAX_INT/1 in both cases.
Also, it's not clear to me that your proposed wraparound addition operator is actually fully associative in all possible cases of overflow.
Proof sketch: write out (an/ad + (bn/bd) + cn/cd)) and ((an/ad + bn/bd) + cn/cd) symbolically, and apply the fact that twos complement arithmetic is associative, commutative and distributive in all possible cases of overflow.
> An addition operator where adding two positive numbers results in a negative number can hardly be called "the mathematically natural" variant.
It's exactly how integer arithmetic works on every CPU designed after 1980, to general satisfaction. In any case, it's mathematically natural because it's exactly how you would construct the field of fractions of an integral domain.
I doubt that raku/perl6 uses these rules for rational arithmetic. It would be highly unintuitive to sum two rational numbers close to 0.5 and obtain a negative number. Do you have any reference for raku arithmetic rules? I cannot seem to find them.
Most other systems (including Scheme) that I've seen that use rational representation by default use arbitrary precision for both numerator and denominator, so don't have this concern.
This is rather ugly for it is not closed by inversion.
> 2. Even the case of bounded numerator and bounded denominator would preserve more of the nice mathematical properties of rational arithmetic than IEEE 754 floating-point arithmetic does (e.g. the associativity of addition).
I do not see how this can possibly be the case. How do you define rational arithmetic with bounded denominators so that addition is associative?
> 3. While the latter could be implemented in hardware, it is not implemented in hardware. The defaults for literals prefer the choice that is implemented in hardware, IEEE 754 floating-point. This is a premature optimization.
Alright, but this view is rather subjective, and only valid if you find rational arithmetic more natural than floating point (which many people do not). Regardless of efficiency, using rational arithmetic with bounded integers in numerical computing would be extremely unnatural to most analysts, they would always need to "normalize" the computations so that all the numbers do not become too small, and a lot of ugly tricks that are not needed in floating point.
Besides some trivial decimal arithmetic (that can be easily implemented in fixed point for the common use case of counting money), I do not really see the point of the rational representation with bounded ints. Of course, when the denominator is allowed to be a bigint, this is very useful in math, but you'll agree this is a completely different context.
There's only one mathematically natural choiceIn the case of bounded numerator and bounded denominator. You simply define (an/ad) + (bn/bd) = (bd × an + ad × bn) / (bd × ad) where the + on the right hand side is ordinary twos complement addition (and the equality test for an/ad and bn/bd is ad × bn == bd × an, which also naturally accounts for the zero-denominator-due-to-zero-divisors cases; alternatively, you can put everything in lowest terms, but there's no point).
> Regardless of efficiency, using rational arithmetic with bounded integers in numerical computing would be extremely unnatural to most analysts
Floating-point was invented by numerical analysts for numerical analysts. No wonder they find it most natural. The overwhelming majority software developers are not numerical analysts, and most programming languages do not target numerical analysts. Nobody says that numerical analysts should not use floats (except maybe the unum guy), we're arguing about defaults in languages that explicitly do not have numerical analysts among their core target audience.
> That's easy. In the case of bounded numerator and bounded denominator, you simply define (an/ad) + (bn/bd) = (bd x an + ad x bn) / (bd x ad)
This definition is not complete. What happens when "bd x ad" is larger than the maximum allowed denominator ?
> The overwhelming majority software developers are not numerical analysts,
the overwhelming majority of young people who learn to program today do machine learning, which is based on mungling huge arrays of floating point numbers. Tell them to use rationals if you dare!
All integer operations are twos complement operations, as I'm sure you guessed anyway.
> the overwhelming majority of young people who learn to program today do machine learning, which is based on mungling huge arrays of floating point numbers. Tell them to use rationals if you dare!
That's very far from factually true, but this kind of argument is not relevant to the Raku defaults in any case. A machine learning library can use whatever optimized number representation its creators wish to use. In fact, the default choice of most language implementors (double-precision floating point) is typically not the representation used in training or inference on deep learning models anyway. The 1080Ti is fast enough only with single-precision floats.
Sure, which is why Scheme is better than Raku here.
> this view is rather subjective, and only valid if you find rational arithmetic more natural than floating point
No, it is an objective fact that arbitrary decimal literals can be represented precisely, and precise operations performed with those representations, in a rational representation but not binary floating point, and that binary floating point trades that precise representation of expressed values and capability of precise operations with those values off for space and performance optimizations.
Neither Scheme nor Raku does this (Scheme uses unbound numerator and denominator in its default rational type, Raku has unbound numerator.)
> I do not see how this is a matter of precision
It's an issue of precision because exact rationals precisely represent the numbers expressed in decimal literals and provide exact (as opposed to approximate with floating point) arithmetic operations, though, to be fair, Raku’s choice of Rat instead of FatRat as the default has some warts in arithmetic.
I imagine whole classes of unexpected problems like timing side channel attacks, financial types expecting it to work better and missing easily overlooked corner cases...
How do I know this? I spent two years investigating exact versus inexact arithmetic in the context of computational science.
>It uses exact rational arithmetic for values that it can represent that way, preferring correctness to efficiency
Fwiw, floats do exactly this the only difference is that you've changed your base from 2 to 10 and introduced unnecessary computation for what is maybe a 10% increase in exactly computable values.
No, exact rationals aren't equivalent to decimal floating point, which while not as good as arbitrary precision rational or decimal representation is still better than binary floating point for decimal literals. In arbitrary precision decimal or rational representation, or even Raku's bounded denominator rationals, if p and q are decimal literals that can be exactly represented in the representation, then so are p + q and p - q. For the arbitrary precision versions, subject to available memory, so are p × q and p ÷ q. Fixed-size floating point (binary or decimal) provides none of those precision guarantees (whether for decimal or binary literals).
If you want a thorough understanding you will want to look at representation-error, rounding-error, error-propagation, why they exist and how they interact.
The interplay between those three forms of numerical error in floating point numbers will also allow you to more easily see the world of limitations of fp beyond 0.1 + 0.2 for yourself.
> It’s not stupid, just different.
Over the past 50 years, my computer has adapted to how humans normally operate in nearly every other way. Why do they continue to use this system which produces results different from what any normal person expects?
> Computers use binary numbers because they’re faster at dealing with those
Computers are faster at dealing with all-caps ASCII, too, but we've accepted here that micro-optimization is less important than doing what people want. Most of the languages I use have even moved past fixnums. Why have we not improved real arithmetic since 1985?
Lisps and Lisp-derived languages, like Scheme, have had a proper numerical tower, including rationals, for decades now. Using reals is optional, but using rationals and everything else imposes an efficiency cost, so people make their decision. Implementing rationals in hardware would not necessarily make them more efficient; that is, if you think having rational support in hardware would help, you have to make the case. It isn't an automatic win:
https://yosefk.com/blog/its-done-in-hardware-so-its-cheap.ht...
“Efficiency” is tough to believe given all the other inefficient yet nice features that have been universally adopted, like Unicode, variable length lists, bigints, etc. In many dynamic languages, every method call is a hash table lookup, yet we’re expected to believe they don’t use Decimals by default because it would be too slow? In C++ I’d buy that excuse.
If you look at any low level hardware it's behavior will be alien and unintuitive to most end-users, your computer has not adapted, only it's ability to support sophisticated high level software that abstracts these things away from end users has improved.
FPUs are no different, calculators round output to 10sf, and as a result most users think calculators are perfect, and that's usually fine... it's not fine when you do programming, because eventually you will need to understand the fundamental limitations of the hardware and more generally finite numerical computation regardless of implementation.
Because most people actually want either fixed-point or floating-point arithmetic. Especially if you only consider the population who is willing to spend money to get better hardware to support their use cases.
The "On Using Integers" page seems very narrowly applicable because it only discusses fixed-point in the context of currency; in a lot of other applications, notably DSP and other multimedia, fixed-point is the norm.
AFAIK in DSPs you use fixed point for a completely different reason, namely because it's simpler and thus more efficient to implement in silicon.
- its exposition is complicated (trying to prove everything in a general base makes it difficult to understand)
- it's woefully out of date (lack of guard digits haven't been an issue for at least 25 years, extended precision hasn't been an issue for the past 10 or so, and most languages now default to having fairly strict floating point semantics)
- it gets bogged down in irrelevant minutiae (rounding modes and exception flags, while available in modern hardware, aren't really supported by any modern languages/compilers)
- it doesn't really provide any practical advice (it barely mentions binary-decimal conversion, it jumps to doubling precision and Kahan summation without suggesting any intermediate steps such as sorted or pairwise summation).
But my biggest complaint is the frequency with which users are referred to it on StackOverflow as if (1) it is a good way to learn about floating point concepts, and (2) anyone using floating point numbers should be expected to understand it all.
But um, so a sophomoric summary without the "complications" of proving it is NOT better nor more accessible.
And I see none of your bullet points are improved upon in the linked paper.
The "absurd" result that [1+2 != 3] * (0.1) isn't even the problem with floating point. It's an even simpler misconception that "even" vs. "repeating" fractions are the same for base 10 vs. base 2 fractions.
So we can understand that 0.33+0.33+0.33 != 1 in decimal due to rounding. So when 0.1 (decimal) which is a truncated repeating "binary decimal" fraction isn't exact we loose our shit. But why is base 10 good and base 2 bad? Why not base 57? Clearly for any base, a truncated decimal-like fraction will be inexact for a lot of numbers. Rounding errors will add up, but this is really a binary vs. decimal issue.
More subtle are errors that grow simply because of issues specific to floating point. For example re-normalization when numbers of very different magnitudes are added or subtracted which eventually causes precision loss.
This is neither hard to understand, nor the only complication with floating point, nor is anything wrong, or bad, nor should anything be fixed in IEEE-754. This is just stuff that numeric programmers MUST understand, at least at the rudimentary level.
No, it is not hard to understand, but it is not obvious, and in fact counterintuitive to most people. Which is why there is a need for a website like this for people to refer to intead of the Goldberg paper which is great if you actually need to do error propagation analysis on your numeric algorithm but which does not give this basic explanation and is therefore not suitable to be cited to people who are suprised that 0.1 + 0.2 != 0.3
So please explain to me how referring to the Goldberg paper as "long article with lols of formulas" is anything but factually correct and a good reason to provide an alternative?
This article is "terrible" because it gives a single bad example and derides a very good reference implying it's too complicated. And steals it's title.
Every programmer that uses floating point should read Goldberg. That blog post is garbage. Post the real source, or an informative article, not junk.
So did I on a small website (yes, I'm the author). It's a website. Not an article. Not a blog. There is more than the title page, which seems to be the only thing you've looked at.
> This article is "terrible" because it gives a single bad example
Which example? What makes it bad?
> and derides a very good reference implying it's too complicated.
I absolutely do not "deride" the Goldberg paper, and it is too complicated for people without a CS background. That doesn't mean there's anything wrong with the paper, or with those people. There is something wrong with kneejerk-posting a link to the paper as an RTFM to basic questions about floating point behaviour. My intention was to provide a better resource for those cases.
> And steals it's title.
Don't be ridiculous. I use the format of the title, which lots of people do (it's basically become a meme now, not sure if Goldberg was the first to use it either), with a critical difference that you seem to have missed: Goldberg adresses his paper to "every Computer Scientist", I address my website to "every programmer". Different audiences.
> Every programmer that uses floating point should read Goldberg.
Maybe. But it is not a good introduction.
> That blog post is garbage. Post the real source, or an informative article, not junk.
You have still not been able to explain what is wrong with it. I am beginning to think you have serious problems with reading comprehension.
I was responding to you saying that a comment in a forum that I made was "doing the same thing" as your small website. But it's not equivalent. I didn't make a website, not a paper. I didn't post it as a reference for the community. I am making, what I hope you understand, is a good faith critique. When the critique written in 3 minutes has as much technical merit (says you) as the "paper", that is not good.
> "Which example?"
Your using an example 0.1 + 0.2 != 0.3. This is nothing to do with floating point. This is an issue of choice of fraction base and an issue of precision that could affect any non-analog computation.
> Don't be ridiculous
You understand exactly what I mean. You replaced "Computer Scientist" with "Programmer". Borderline infringement, borderline plagiarism.
> But it is not a good introduction
So did you give one? No. You summarized a very famous paper and tweaked it's title. You provide no real advise for what to do. You provide no practical examples of real world code for "those programmers" that just want to know what to do.
> Maybe. But it is not a good introduction...
Why is it not good? I like that it puts the simple parts first and the formal math later, so you don't get bogged down in it. You're as welcome to your opinion as I am mine.
> I absolutely do not "deride" the Goldberg paper.
Yes you did. Let's say I said "Your website is oversimplified and difficult to navigate. It is garbage." Did I deride yours? [yes. yes i did.]
> I am beginning to think you have serious problems with reading comprehension:
I have serious problems comprehending a disorganized web page with a web 1.0 navigation panel instead of a properly formatted paper.
> You have still not been able...
See above:
- Your example is borderline wrong. It's about a different subject.
- "Programmers" is not a good title when your audience is "Computer Scientists" and "Software Engineers".
- You changed the title in the HN post to obfuscate that you ripped off the original title.
- There is zero creative, or new information presented.
- The most valuable part is the "References" page. In which every single link contains more relevant and accessible information than your "site".
- You aren't even linking to a definitive reference. But instead to an appendix of a user manual Instead of, for example: http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf
I think it'd be great stuff if:
- you wrote a little blog
- that introduced the goldberg paper gently
- that augmented and highlighted the references. If they are a little complicated, then explain them. Don't imply "too complicated, you should skip".
- that was able to be printed in a coherent format. Not 8 or 10 different individual web 1.0 frames.
There's a reason academic papers are formatted the way they are. It's actually for precise communication. If you try to "simplify" and make things too much more "accessible" for regular "programmers", you may falsely believe you are helping.
But this is a bad idea. Complex subjects do require some amount of concentration and work to understand. Floating point subtleties are not the lack of a zippy "programmer"-friendly website/blog away from that. You've tried to dumb-down a very introductory paper. It's amateurish and doesn't help.
I appreciate the references. Wouldn't it have just been easier to add them to the Wikipedia article?
"terrible", "junk" and "garbage" is not a good faith critique.
> When the critique written in 3 minutes has as much technical merit (says you) as the "paper", that is not good.
Except It's not a "paper" either, it's a website, with multiple pages, with your "critique" being equivalent in content to maybe 1.5 of them.
> Your using an example 0.1 + 0.2 != 0.3. This is nothing to do with floating point. This is an issue of choice of fraction base and an issue of precision that could affect any non-analog computation.
I.e. it has everything to do with floating point. And it happens to be an example of exactly the kind of real, concrete problem that real people writing real programs encounter in the real world and then look for help with.
> You understand exactly what I mean. You replaced "Computer Scientist" with "Programmer". Borderline infringement, borderline plagiarism.
I understand that you have no fucking clue what the words "infringement" or "plagiarism" mean. There are now dozens of articles out there using that title format (and I would not be certain Goldberg was the first), just like there were dozens of articles using the "X considered harmful" format, and no sane person (and no lawyer either) would consider any of it "stealing", "infringement" or "plagiarism".
> You summarized a very famous paper and tweaked it's title. You provide no real advise for what to do. You provide no practical examples of real world code for "those programmers" that just want to know what to do.
What the flying FUCK? I very much do all of those things. How about you actually LOOK at the thing you criticize?
> Why is it not good? I like that it puts the simple parts first and the formal math later
It is still very much an academic paper and starts using formal math notation already when introducing floating point formats, and theorems two sections later, about 10% into the paper. The "simple parts" are already way too formal and too general for most of the people who get directed at it, and thus it fails to be helpful for them.
> Yes you did.
No, I did not. That is a lie.
> Let's say I said "Your website is oversimplified and difficult to navigate. It is garbage." Did I deride yours? [yes. yes i did.]
Yes, the word "garbage" is obviously derisive - and I used no such word to describe the paper. Unlike your example, I did not even criticize it explicitly. The worst thing I wrote was that it "didn’t seem to help with your problem" - notice the "seem"?
> I have serious problems comprehending a disorganized web page with a web 1.0 navigation panel instead of a properly formatted paper.
Well, that says more about you than about the website. Multiple other people have praised the website's clean design and usability.
> - Your example is borderline wrong. It's about a different subject.
Nonsense. It's an example of exactly the kind of problem people have and are looking for help with.
> - "Programmers" is not a good title when your audience is "Computer Scientists" and "Software Engineers".
My audience is programmers. People who don't think they're programmers can feel free to ignore it. Or is your problem that it's not ideal for "Computer Scientists" who also consider themselves programmers? So what?
> - You changed the title in the HN post to obfuscate that you ripped off the original title.
What a load of bullshit. The HN post of this comment thread was not made by me. The HN post I made in 2010 did in fact have the title format in question. And the idea that it was "obfuscated" is just plain idiotic any way you look at it.
> There is zero creative, or new information presented.
My main goal was not creativity or new information.
> The most valuable part is the "References" page. In which every single link contains more relevant and accessible information than your "site".
Says you. Pretty much everyone else seems to disagree.
> You aren't even linking to a definitive reference. But instead to an appendix of a user manual Instead of, for example: http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf
Now you're just making a fool of yourself. It's exactly the same content. Your link is a scanned paper article with bad OCR that happens to lie around on some scientist's (very much web 1.0, I might add) site and might disappear at any time.
> I think it'd be great stuff if: - you wrote a little blog - that introduced the goldberg paper gently - that augmented and highlighted the references. If they are a little complicated, then explain them.
No, that would not be great. That would be an idiotic waste of time. The solution for a reference that is already too long and complex for the target audience's question is not to add more stuff to it! We're not doing literature analysis here!
> Don't imply "too complicated, you should skip".
That is not what I am implying (otherwise why would I list the references at all?). It's "too complicated for you right now, here's the basics, now go back there if you want more details".
> that was able to be printed in a coherent format. Not 8 or 10 different individual web 1.0 frames.
Format is always a matter of taste, but many people seem to like it. And you keep using
> There's a reason academic papers are formatted the way they are.
Yeah, and the biggest reason is that they are designed to be published in printed journals.
> It's actually for precise communication.
If you're seriously claiming that there is a fundamental difference between one long article with separate sections, and a webpage with an navigation index and some separate pages, then I really can't help you (but you need help). And you keep using that expression "web 1.0". It doesn't mean what you think it means. "frames" as well. You might want to inform yourself.
> If you try to "simplify" and make things too much more "accessible" for regular "programmers", you may falsely believe you are helping.
Many, people have in fact stated that my website helped them. So it seems you are provably wrong.
Fair enough. But the you asked why I felt that way, and then I am trying to explain in good faith. There is no need to get cross.
You come across as a narcissist of the first order. Your website provides little value, possibly negative. It is a hard to follow and a dumbed-down version of famous paper. When I point it out you "prove me wrong" and claim I've not made my points.
You have still failed to provide any real criticism other than of what version of the Goldberg paper I used.
> What I learn is that you imagine that I don't understand (I do), don't know (I do)
You have proven pretty conclusively that no, you don't.
> You come across as a narcissist of the first order.
Because I defend something that I received praise for many times and am proud of against destructive and unreasonable criticism? No, a narcissist is what you are, with your constant, arrogant disparaging of everything that doesn't follow academic ceremony.
> Your website provides little value, possibly negative.
In your very subjective opinion that disagrees with pretty much everyone else.
> It is a hard to follow
Almost everyone else who has looked at it has in fact stated that it's very easy to understand. Looks like it's you who has a problem here.
> and a dumbed-down version of famous paper.
The website is not, nor does it claim to be a "version" of that paper.
> When I point it out you "prove me wrong" and claim I've not made my points.
Yes, that is what you have indeed consistently failed to do,
https://blog.reverberate.org/2014/09/what-every-computer-pro...
Then please read some articles along the lines of:
http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruc...
Then continue, please do, to minimize, deflect, play pedant, and outright ignore any criticism. No, you do not get to insist that the critique meet your haughty high minded standards of evidence and proof. I don't need to prove why I consider your work amateurish.
It has been an interesting expose into just why your website is what I consider amateurish junk. It is very unlikely that you're going to be able to learn very much of anything, which explains a lot about how it got that way.
I get it. You are a "programmer". You've earned that distinction by "programming" things, not by understanding them. And I find it especially awesome that in your hyper-competence, you deem it necessary to guide the entire community of people who don't understand things to a whole new way of not understanding floating point.
Well, no harm done. You're theory is that they couldn't understand it anyway. So if this website's audience is people like you, I suppose it's fine. Just please don't do any programming that involves numbers or correctness.
Floating point has those problems, but so do many other representations. It isn't just a floating point problem. This is exactly the kind of muddy thinking that is avoided by sticking to a more academic and formal exposition avoids.
According to your theory, there are schloads of "Programmers" out there that can't do computer science, or engineering that need a crutch. If that is true, then you're mis-training them to blame floating-point intricacies that they can't possibly understand when it might not even be that.
That is not "muddy thinking", that is "sticking to the matter at hand", the matter being rhe concrete problems very commonly encountered writing real programs using the built-in datatypes of most programming languages.
The only muddy thinking here is your insistence that "other representations" have any relevance here.
> If that is true, then you're mis-training them to blame floating-point intricacies that they can't possibly understand
How exactly am I "mis-training" people by explaining things so they can understand them?
You still have completely failed to point out a single thing that is actually factually wrong on my website. Your critique on the other hand, has been factually wrong in all the places where it's not superficial gatekeeping.
And if they were copying and summarizing most of the same content they would also be plagiarizing. If they are riffing on a title theme about a different subject, which they are, it would be fair use.
> My main goal was not creativity or new information.
So that again would be close to plagiarism.
And what I wrote is a summary of the underlying technical issues, not specifically the Goldberg paper.
So yes, you have no fucking clue what "plagiarism" means.
Which is formatted properly and has references cited correctly. It is organized and precise.
It would be better if you found the real PDF. What is NOT OK is to link to the back of a manual that is a reformatted version that is already not a primary reference.
When I said "JUNK" that is exactly the kind of sloppiness I'm talking about.
If you find an authoritative source available online, I would be more than happy to change the link, but since that doesn't seem to exist and hosting a copy myself would be a violation of copyright, I did the best I could do.
> What is NOT OK is to link to the back of a manual that is a reformatted version that is already not a primary reference.
What exactly about it is "NOT OK"? The content is the same, it is structured the same, it also contains the citations. The only thing that is different is the formatting.
> When I said "JUNK" that is exactly the kind of sloppiness I'm talking about.
Which only reflects badly on you, not me.
OK, I don't like your page and did openly disparage it but have said nothing unkind or impolite to you as a person.
You, however, refuse to acknowledge that you are insulting large classes of "programmers" by assuming they cannot understand a simple paper.
I would suggest that you yourself do not really understand it correctly and urge you to re-read it carefully and then read its references.
I would further encourage you to stop assuming that everything you do is great and anyone who thinks otherwise should be yelled and to told they obviously missed the point. It could be you who is missing the point as well.
This gets to the heart of why I felt it necessary to comment at all, and as you have gathered, am being derisive and negative toward your website with navigation panel.
Programmers is not a term I like. It implies that you trust someone to write a program. And the way you use the term, you do not need to be an engineer or a computer scientist. Therefore we need to "dumb down" some super-to-complicated content X.
For another example in the same genre: https://poignant.guide/
This kind of narcissistic behavior and writing is amateurish and insulting to those of us who actually do the fairly hard work of learning and working in a formal field.
Just about every security vulnerability and every broken memory hog of a java program is due people acting and thinking like programmers, not engineers. Computer Scientists are not the cause of rampant security vulnerabilities.
You are proud of having done "hard work of learning and working in a formal field", and are accustomend to the writing and publishing style of that field, and that has led you to strongly resent the implication that something which does not follow that style could possibly be better in any way or for any purpose than something that does.
And I believe that you are wrong, that the academic writing style is not the most appropriate for every situation or every audience, and that there is value in addressing different situations and audiences.
> Programmers is not a term I like. It implies that you trust someone to write a program.
It really only implies that someone is writing a program.
> And the way you use the term, you do not need to be an engineer or a computer scientist.
That is a simple fact. And another fact is that even most people who've had formal education in engineering or computer science typically lose fluency with the formal academic style and notation once they leave academics, because it is very rarely needed in their daily work.
> For another example in the same genre: https://poignant.guide/ > This kind of narcissistic behavior and writing is amateurish and insulting to those of us who actually do the fairly hard work of learning and working in a formal field.
And here you are engaging in nothing but arrogant, elitist gatekeeping. You don't have to like that writing style (I don't either), but taking it as a personal insult is silly, and the implication that there is only one appropriate style for any writing that concerns programming is needlessly close-minded.
> Just about every security vulnerability and every broken memory hog of a java program is due people acting and thinking like programmers, not engineers. Computer Scientists are not the cause of rampant security vulnerabilities.
I beg to differ. Being well versed in computer security and having formal computer science or engieering education are not all that strongly correlated. I would in fact bet money that more than 50% of the security vulnerabilities on https://cve.mitre.org/ were originally introduced by someone with formal computer science education.
In fact, computer scientists with no industry experience are often godawful at programming, including security and performance aspects, because they're used primarily to writing throwaway proof of concept code that doesn't need to be maintained.
I didn't say, by the way, credentialed engineer. I said "think like an engineer". I'd even accept Hacker.
Those who are just "programmers" are essentially data-entry clerks. And EVEN THEY can read Goldberg before doing floating point for at least they can get a hint of the difficulties.
"Java Programmers" writing blogs and websites for "Ruby Programmers" to give hints to "C# programmers" so they don't have to cut-paste from Stack Overflow is harmful. It's noise and addition random bad information that a good programmer, who should be engineering a solution, will have to cull out.
If the logical fallacy in this request is not glaringly obvious to you then you have less understanding of computer science than most "data-entry clerks".
Again with that very loose logic. I did not state your website helped no one. So the fact that it helped one or more people does not prove I was wrong.
I do believe it does far more harm than good. If your idea is that there as so many people writing code that can't possibly understand Goldberg AND also it "would be an idiotic waste of time" to summarize a real paper because it was "too long and complex" your target audience sounds like you are calling your target audience pretty unprofessional.
So I'll agree that if your target audience has an attention span of a gnat and can't understand basics about computer science, they might like your website with navigation panel. And they should NEVER EVER write numeric code.
How exactly does it do harm?
> If your idea is that there as so many people writing code that can't possibly understand Goldberg
No, my idea is that there are many people writing code who have concrete problems and questions to which the Goldberg paper is not a good answer because it is far from clear how it addresses those problems and questions, and would take a larger time investment to understand than seems warranted. Thus it is useful to have a less formal explanation that addresses them directly and refers to the paper as a more in-depth resource.
> AND also it "would be an idiotic waste of time" to summarize a real paper because it was "too long and complex"
No. What I called a waste of time was the suggestion of "introducing the goldberg paper gently - augmenting and highlighting the references", because then I would be writing about the paper instead of about the problems and questions of the audience.
> And they should NEVER EVER write numeric code.
We may have found a big misunderstanding. I completely agree that my website does not provide sufficient information for people writing iterative numeric algorithms (Though please note that the "error propagation" makes this very clear and explicitly directs people at the Goldberg paper). It is aimed at people who write some of the other 99% of code, which does very simple calculations (if any) but still has people put quantities (often representing money) into floating point typed variables and then be surprised at the behaviour.
I believe your hypothetical audience doesn't exist. Give them some credit. There's simply no reason a competent software engineer cannot understand Goldberg.
Totally. And my website aims to help people understand this aspect of their machine better, and it does this quite well (other people's observation, not just my assertion).
> I believe your hypothetical audience doesn't exist. Give them some credit. There's simply no reason a competent software engineer cannot understand Goldberg.
That they can understand it doesn't mean they have to invest the hours it would take to go through all of it with rusty formal math skills, when their immediate problem or question concerns ony a small (and not immediately discernible) part of it.