Do any of the languages mentioned give a compiler warning? To help educate?
9999999999999999.0 – 9999999999999998.0
61–70 of 274 posts
Re: 9999999999999999.0 – 9999999999999998.0
#62https://play.golang.org/p/_EkSHUIrg1y
But, https://play.golang.org/p/naE55o3_xFP
I guess the first link is converting the float constants to ints at compile-time?
(edit: oh, it's actually mentioned in the article. I should read more carefully)
Re: 9999999999999999.0 – 9999999999999998.0
#63Earlier quoted context omitted.
There are several. If you subtract two numbers close to each other with fixed precision you don’t know what the revealed digits are. (1000 +/- .5) - (999 +/- .5) = 1 +/- 1. Thus 0, 1, and 2 are all within the correct range.
What does revile mean in this context?
Edit: revealed
Floating point numbers have X digits of accuracy based on the format. (Using base 10 for simplicity) Let’s say .100 to .999 times 10^x.
But what happens when you have .123x10^3 - .100x10^3. It’s .23? x 10^2 but what is that ? we might prefer to pick 0 but it really could be anything. We can’t even be sure about the 3. If the numbers where .1226 x 10^3 and .1004 x 10^3 that just got rounded the correct number would be .222 x 10^2
Re: 9999999999999999.0 – 9999999999999998.0
#64Earlier quoted context omitted.
What does revile mean in this context?
Edit: revealed Floating point numbers have X digits of accuracy based on the format. (Using base 10 for simplicity) Let’s say .100 to .999 times 10^x. But what happens when you have .123x10^3 - .100x10^3. It’s .23? x 10^2 but what is that ? we might prefer to pick 0 but it really could be anything. We can’t even be sure about the 3. If the numbers where .1226 x 10^3 and .1004 x 10^3 that just got rounded the correct…
Yeah, that's just a limitation of the format. Approximating an uncountably infinite quantity of numbers with only 64 bits is never going to be exact.
Y However, you aren't going to do any better without using vastly more expensive arbitrary precision.
Re: 9999999999999999.0 – 9999999999999998.0
#65What is the "right answer"? Is the article claiming that such languages don't respect IEEE-754, or that IEEE-754 is shit? If you want arbitrary precision, use an arbitrary precision datatype. If you use fixed precision, you'll need to know how those floats work. Pointless article, imho.
Note that the last example in the list, Soup, handles the expression "correctly", and also happens to be a programming language the author is working on.
Re: 9999999999999999.0 – 9999999999999998.0
#66Are there any mainstream languages that consider a decimal number to be a primitive type? I feel like floating point numbers are far less meaningful in every day programs. Even 2d graphics would be easier with decimal numbers. Unless you're using numbers that scale from very small to very large, like 3d games or scientific calculations, you don't actually want to use floating point.
There are plenty of languages without the concept of a primitive type...
Re: 9999999999999999.0 – 9999999999999998.0
#67I don't understand all the crap that IEEE 754 gets. I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don't understand the people who "understand" floating point and continue to criticize it for the 0.1 + 0.2 "problem." The fact is that IEEE 754 is an exceptionally good way to approximate the reals in computers with a minimum number…
> exceptionally good way to approximate
You answered your question. 99% of the time being exact is a requirement and calculation speed is utterly unimportant, thus using IEEE 754 results in programs that are fundamentally broken.
Re: 9999999999999999.0 – 9999999999999998.0
#68A useful website for these that I ran across recently: https://float.exposed/ For example, entering 9999999999999999.0 into "double" gives https://float.exposed/0x4341c37937e08000 and entering 9999999999999998.0 gives https://float.exposed/0x4341c37937e07fff My wishlist for such a page would contain two additional features: 1. Allow entering expressions like "a OP b == c", so that one can enter "0.1 + 0.2 == 0.3" or…
The IEEE 754 calculator at http://weitz.de/ieee/ does some of what you ask for. You can enter two numbers, see the details of their representation, and do plus, minus, times, or divide using them as operands and see the result.
Re: 9999999999999999.0 – 9999999999999998.0
#69I don't get it. Why is the author complaining? He requests 17 digits of accuracy which is not something you should be using floats for in any form. Just import/link a package which can do arbitrary precision arithmetic of your choice and pay the overhead price.
Re: 9999999999999999.0 – 9999999999999998.0
#70I don't understand all the crap that IEEE 754 gets. I appreciate that it may be surprising that 0.1 + 0.2 != 0.3 at first, or that many people are not educated about floating point, but I don't understand the people who "understand" floating point and continue to criticize it for the 0.1 + 0.2 "problem." The fact is that IEEE 754 is an exceptionally good way to approximate the reals in computers with a minimum number…
> exceptionally good way to approximate You answered your question. 99% of the time being exact is a requirement and calculation speed is utterly unimportant, thus using IEEE 754 results in programs that are fundamentally broken.
Is that really true? In my experience, 99.9% of the time I don't need an exact number; the vanishingly few times when I have such a need (almost entirely calculations involving currency), using a fixed point representation is simple enough.