9999999999999999.0 – 9999999999999998.0 • Hacker News Board

Re: 9999999999999999.0 – 9999999999999998.0

#191

Post by TFortunato » Sun, Jan 06, 2019, 5:43 AM UTC

leiroigh wrote: post #150

TFortunato wrote: post #121

Earlier quoted context omitted.

How do you mean? The x86-64 instruction set / abi specifies long doubles as 80-bits, and still supports them ...

And nobody uses this terrible mis-feature in practice, everything runs via 64 bit xmm registers. Rightly so, because programmers want their optimizing compiler to decide when to put a variable on the stack and when to elide a store/load cycle by keeping it in a register. With 80 bit precision, this makes a semantic difference and you end up in volatile hell.

Yeah I agree that everything typically runs in XMM registers and that's what people want. I'm not sure what about the availability of extended precision makes it s a misfeature? For some cases it IS what you want, and it's nice to be able to opt in to using it..

EDIT: If I had some application where I needed the extended range, like maybe I was going to run into the exact numbers above, I'd appreciate the ability to opt-in to this. Totally agree I wouldn't want the compiler to surprise me with it, but also not terrible, or useless.

Code w/ Assembly: https://godbolt.org/z/W3ZmqJ Output: https://onlinegdb.com/Sy_I3Q1ME

Re: 9999999999999999.0 – 9999999999999998.0

#192

Post by Ngunyan » Sun, Jan 06, 2019, 5:47 AM UTC

mark-r wrote: post #176

Is floating point math broken? https://stackoverflow.com/questions/588004/is-floating-point... No, it's just that a lot of people don't understand its limitations.

It is broken once outside of that limitation.

Re: 9999999999999999.0 – 9999999999999998.0

#193

Post by ken » Sun, Jan 06, 2019, 5:55 AM UTC

alanfranz wrote: post #11

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

> Is the article claiming that such languages don't respect IEEE-754, or that IEEE-754 is shit?

No, I don't think so. Where does that come from? The page doesn't mention FP standards at all.

> If you want arbitrary precision, use an arbitrary precision datatype.

That's the point. Half of them don't offer this feature. The other half make it very awkward, and not the default.

We went through this exercise years ago with integers. These days, there are basically two types of languages. Languages which aim for usability first (like Python and Ruby), which use bigints by default, and languages which aim for performance first (like C++ and Swift), which use fixints by default. It's even somewhat similar with strings: the Rubys and Pythons of the world use Unicode everywhere, even though it's slower. No static limits.

With real numbers, we're in a weird middle ground where every language still uses fixnums by default, even those which aim for usability over performance, and which don't have any other static limits encoded in the language. It's a strange inconsistency.

I predict that in 10 years, we'll look back on this inconsistency the same way we now look back on early versions of today's languages where bigints needed special syntax.

Re: 9999999999999999.0 – 9999999999999998.0

#194

Post by issam01 » Sun, Jan 06, 2019, 5:55 AM UTC

Pascal/Delphi gives the right answer:

writeln(FloatToStr(9999999999999999.0 - 9999999999999998.0));

1

Re: 9999999999999999.0 – 9999999999999998.0

#195

Post by nearbuy » Sun, Jan 06, 2019, 5:56 AM UTC

3pt14159 wrote: post #122

lenticular wrote: post #52

Earlier quoted context omitted.

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…

Outside of the academic world decimals are almost always a better solution if performance isn't critical. Most logic is multiplicative. For example, apply a 30% tax on a dollar quantity and display both subtotal and grand total. With floats, there are inequalities. With decimal there usually aren't unless you're dividing, but we already have to deal with divide errors in base ten, and it is much more likely to need t…

That doesn't seem dumb at all. Making BCD the default would mean floats use 17% more space for the same precision. That might seem like a small loss, but it's also for an incredibly small gain. Programmers would still have to be aware that testing two decimals for exact equality is dangerous. I don't see the problem with 0.1 + 0.2 = 0.300000000000001 if you aren't testing floats for direct equality.

Re: 9999999999999999.0 – 9999999999999998.0

#196

Post by TFortunato » Sun, Jan 06, 2019, 6:03 AM UTC

loeg wrote: post #151

TFortunato wrote: post #121

Earlier quoted context omitted.

How do you mean? The x86-64 instruction set / abi specifies long doubles as 80-bits, and still supports them ...

The x86-64 instruction set does not specify any particular ABI and definitely does not specify the precision of a C language type.

Fair point, I was a little fast and loose with my words there, which is definitely dangerous when it comes to things like C language / ABI standards! :-P

Re: 9999999999999999.0 – 9999999999999998.0

#197

Post by Retra » Sun, Jan 06, 2019, 6:05 AM UTC

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.

"Most" use cases? You mean the use cases that don't involve heavy math, like graphics, physics, and statistics?

Re: 9999999999999999.0 – 9999999999999998.0

#198

Post by rscho » Sun, Jan 06, 2019, 6:14 AM UTC

There is interesting ongoing research on representing exact reals: https://youtu.be/pMDoNfKXYZg

Re: 9999999999999999.0 – 9999999999999998.0

#199

Post by Retra » Sun, Jan 06, 2019, 6:18 AM UTC

crankylinuxuser wrote: post #82

So.. Can someone better versed in the ways of system level programming tell me why we still use IEEE 754 exponential notation? Iv'e seen article after article of how "horrible it is". So, are there default libs to use Binary Coded Decimal (BCD) or something like that?

You need a fixed data size for good performance. If you use fixed precision, you get absolute nonsense when doing very common calculations like `tan(x)`. IEEE 754 was masterfully engineered to produce the fastest, most correct results for the most common operations.

We use it because it's fantastic.

Re: 9999999999999999.0 – 9999999999999998.0

#200

Post by _kst_ » Sun, Jan 06, 2019, 6:31 AM UTC

Aardwolf wrote: post #80

> Several of the results surprised me. Did they surprise you? Well, the perl6 result surprised me, since that means it's using something more precise than double precision floating point :)

It surprised me too, since it's not what I got.

    $ perl6 --version
    This is Rakudo version 2018.03 built on MoarVM version 2018.03
    implementing Perl 6.c.
    $ perl6 -e 'print 9999999999999999.0-9999999999999998.0;print "\n";'
    2
    $

(Incidentally, I would have used "say" rather than "print" with an explicit newline.)