151–160 of 274 posts
Earlier quoted context omitted.
That hasn’t been the case for over a decade.
How do you mean? The x86-64 instruction set / abi specifies long doubles as 80-bits, and still supports them ...
Earlier quoted context omitted.
That hasn’t been the case for over a decade.
How do you mean? The x86-64 instruction set / abi specifies long doubles as 80-bits, and still supports them ...
A 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…
> 9999999999999999.0 into "double" gives https://float.exposed/0x4341c37937e08000 Nice that it reformats the input to "10000000000000000.0", gets the point across that a 64 bit double float just doesn't have enough bits to exactly represent 9999999999999999.0, but that it does happen to be able to represent 9999999999999998.0.
IEEE 754 64-bit floats have 53 significant bits ("mantissa").
Earlier quoted context omitted.
So duckduckgo uses the normal 64bit floating point, and the clever people at bing automatically switch to bignums when needed. But I have no idea what google does to get that 0?
I think Google is truncating the numbers. You get 0 even if you do: 9999999999999999 – 9999999999999990
9999999999999999 - 9999999999999971 == 0
9999999999999999 - 9999999999999970 == 30
9999999999999999 - 9999999999999969 == 32
9999999999999999 - 9999999999999966 == 34I guess this comes down to most of them having implementations of arbitrary precision decimals.
https://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)
I 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…
Presumably we could actually make decimal floating point computation the default and greatly reduce the amount of surprise. I don't think the performance difference would be an issue for most software.
Earlier quoted context omitted.
Julia has built in rationals (as do a few other languages). I'm not aware of any language (other than Wolfram) that defaults to storing something like 0.1 as 1/10 - i.e. uses the decimal constant notation for rationals, rather than having some secondary syntax or library.
Even in Wolfram, 0.1 is not the same as 1/10. In[1]:= Precision[0.1] Out[1]= MachinePrecision In[2]:= Precision[1/10] Out[2]= \[Infinity]
I don't currently have a license, so out of curiosity is 0.3 == 3/10 in wolfram?
Earlier quoted context omitted.
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.
You could see it as a "limitation of the format", or you could see it as exchanging one type of mathematical object for another. For example, CPU integers aren't like mathematical integers. CPU integers wrap around. So CPU integers aren't "really" the integers—CPU integers are actually the ring of integers modulo 2n , with their names changed! I'm not sure what the name of the ring(?) that contains all the IEEE754 fl…
Earlier quoted context omitted.
There's no reason for every step of a computation to be confined to the same very small message length. And the necessary error analysis should be built into the language, preferably in the same "advanced users only, here be dragons" package as the imprecise types themselves.
So interestingly, processor makers are on the same page with you re: computations, and lots of processors can internally do computations in "extended precision", e.g. 80-bit floats, only converting to/from 64-bit doubles at the start and end of the computation. https://en.m.wikipedia.org/wiki/Extended_precision