Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

9999999999999999.0 – 9999999999999998.0

geocar.sdf1.org

Post reply on HN
Print view View original

251–260 of 274 posts

Re: 9999999999999999.0 – 9999999999999998.0

#251

Post by ayidnelm »

lenticular wrote: post #52
twtw wrote: post #39

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…

Yeah, the limitations of FP are well-known to anyone who does much numerical work. Floating point numbers are the optimal minimum message length method of representing reals with an improper Jeffery's prior distribution. A Jeffery's prior is a prior that is invariant under reparameterization, which is a mandatory property for approximating the reals. In this case, it is where Prob(log(|x|)) is proportional to a const…

> Floating point numbers are the optimal minimum message length method of representing reals with an improper Jeffery's prior distribution.

Do you have a link to a proof or discussion of this? I haven't heard this before and I would love to have this statement unpacked a little more.

Re: 9999999999999999.0 – 9999999999999998.0

#252

Post by vanderZwan »

tntn wrote: post #243
vanderZwan wrote: post #238

Earlier quoted context omitted.

> Doing that makes improving precision a lot easier but at the cost of computation time. Not quite. The difference in computation time is the current the lack of hardware support, not something inherent to the underlying encoding method. So in practice you are right, but in, for example, embedded contexts without floating point hardware, the performance advantages of IEEE floats should disappear (especially if using…

Even if hardware support existed, it seems like a variable length encoding has some inherent overhead relative to a fixed length encoding. If you have a "base length" of e.g. 32 bits and occasionally expand to 64, there's an inherent cost there in both computation and memory, presumably for greater precision. Perhaps that overhead could be minimal with hardware support, but it seems it must have some.

Those are type one unums, not posits. What you are saying about variable length encoding may be true, but it does not actually apply to the current comparison. Type 2 unums are also fixed length, but have other issues.

Re: 9999999999999999.0 – 9999999999999998.0

#254

Post by tntn »

vanderZwan wrote: post #252
tntn wrote: post #243

Earlier quoted context omitted.

Even if hardware support existed, it seems like a variable length encoding has some inherent overhead relative to a fixed length encoding. If you have a "base length" of e.g. 32 bits and occasionally expand to 64, there's an inherent cost there in both computation and memory, presumably for greater precision. Perhaps that overhead could be minimal with hardware support, but it seems it must have some.

Those are type one unums, not posits. What you are saying about variable length encoding may be true, but it does not actually apply to the current comparison. Type 2 unums are also fixed length, but have other issues.

'nestorD was discussing the effects and overheads of "dropping the fixed length constraint" in the comment you replied to.

Re: 9999999999999999.0 – 9999999999999998.0

#255

Post by stephencanon »

bjourne wrote: post #125
saagarjha wrote: post #96

Earlier quoted context omitted.

Rationals get unwieldy quickly, even with the simplest of arithmetic. A couple of additions is enough to get a large denominator.

That has not been my experience using a language with builtin support for rationals. The rational is simplified after each operation so it never grows unwieldy large. It is slower than floats, but imo vastly superior for most use cases.

Even simplifying after every operation, in the typical case exact rationals grow exponentially in the number of terms in the computation. This means that either: (a) you cannot use them for any non-trivial computation. (b) you have to round them, in which case they are strictly worse than floating-point numbers because they have redundant representations and a very non-uniform distribution.

Re: 9999999999999999.0 – 9999999999999998.0

#256

Post by zeroimpl »

thanatos_dem wrote: post #155

Interestingly, SQLite gets it wrong, returning 2.0, but MySQL, MariaDB, Postgres, and Cockroach all get it right at 1.0 I guess this comes down to most of them having implementations of arbitrary precision decimals.

In PostgreSQL, if you specify a decimal literal, it is assumed to be type NUMERIC (arbitrary precision) by default, as opposed to FLOAT or DOUBLE PRECISION.

If you stored your values in table rows as DOUBLE PRECISION, you would of course get the wrong answer.

Re: 9999999999999999.0 – 9999999999999998.0

#257

Post by int_19h »

smallnamespace wrote: post #205
int_19h wrote: post #143

Earlier quoted context omitted.

A lot of real-world data is already in base-10 for obvious reasons, and so an arrangement that lets you add, subtract and multiply those without worrying is worthwhile, even if it can't handle something more exotic.

Would you really call 'any rational with divisible factors other than 2 and 5' to be 'exotic'? Maybe we really should move back to base-60 like the Babylonians used, then you could at least divide by 3.

Because humans standardized on base-10, and computers are ultimately for humans to use?

Re: 9999999999999999.0 – 9999999999999998.0

#258

Post by int_19h »

dbaupp wrote: post #201
int_19h wrote: post #139

Earlier quoted context omitted.

The way to avoid this issue is to avoid floating-point numbers that have any implicit zeroes (due to exponent) after its significant digits. Basically restrict the range to only values where it's guaranteed that for any x1 and x2 from the range, (x1-x2) produces a non-zero dx such that x2+dx == x1. The only example off the top of my head that is floating point is C# "decimal", which actually originates from the Decim…

I believe IEEE754 floats have that subtraction/addition guarantee (as long as the hardware doesn't map subnormals to zero). The problem in this case is the input numbers are rounded when they are converted from text/decimal to a float, and so aren't exact.

> I believe IEEE754 floats have that subtraction/addition guarantee (as long as the hardware doesn't map subnormals to zero).

They don't - all 11 bits of the exponent (for float64) are in use, so you can have something like 1e300, and then you can't e.g. add 1 to it and get a different number.

   >>> x = 1e100
   >>> x
   1e+100

   >>> y = x + 1
   >>> y
   1e+100

   >>> x - y
   0.0

Re: 9999999999999999.0 – 9999999999999998.0

#259

Post by vanderZwan »

tntn wrote: post #254
vanderZwan wrote: post #252

Earlier quoted context omitted.

Those are type one unums, not posits. What you are saying about variable length encoding may be true, but it does not actually apply to the current comparison. Type 2 unums are also fixed length, but have other issues.

'nestorD was discussing the effects and overheads of "dropping the fixed length constraint" in the comment you replied to.

Oh darn, you're right. My bad!

In my defense, the comment he replied to got downvoted and I thought it was nestorD, so I was "primed" to misinterpret his comment as criticizing unums in general.

Re: 9999999999999999.0 – 9999999999999998.0

#260

Post by garmaine »

TFortunato wrote: post #121
garmaine wrote: post #117

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 ...

The x87 ISA does, yes, and they are supported for binary compatibility reasons. However the actual x87 registers are shadowed by the vector registers so you can only use one. Any modern vectorizing compiler uses the vector instructions for FPU arithmetic, even when scalar, with a max precision of 64-bit.
Post reply on HN