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

231–240 of 274 posts

Re: 9999999999999999.0 – 9999999999999998.0

#231

Post by lizmat »

_kst_ wrote: post #200
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.)

Indeed, there was a bug with determining when to switch to floats, that was fixed by Zoffix in August:

    https://github.com/rakudo/rakudo/commit/fec1bd74f97e257d4c88673cd62fdcae39f587a3

Re: 9999999999999999.0 – 9999999999999998.0

#232

Post by josefx »

dannypgh wrote: post #127
tom_ wrote: post #116

Earlier quoted context omitted.

An alternative calculation: https://news.ycombinator.com/item?id=18109432 "You can rent a Skylake chip on Google Cloud that'll perform 1.6 trillion 64 bit operations per second for $0.96/hr preemptively. That's enough to run one instruction over a 64 bit address space exhaustively over 120 days, or for ~$2800" It might not make economic sence to actually make this happen for any realistic test, but it's interesting t…

At some point, your test switches from testing the code, to testing the machine the code runs on. That likely happens before 120 days.

Given issues like the intel fdiv bug that may make sense to test if you really want to avoid running into hardware specific bugs.

Re: 9999999999999999.0 – 9999999999999998.0

#233

Post by dotancohen »

jacobolus wrote: post #202
3pt14159 wrote: post #122

Earlier quoted context omitted.

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…

> Outside of the academic world decimals are almost always a better solution Is “academic world” now a shorthand for “all numerical computing”? Decimals basically never make sense, except possibly in some calculations related to money. Those make up a minuscule part of modern computer use. Maybe decimals are also better for homework assignments for schoolchildren? The type of applications where decimals are useful ar…

Even with money I use integers. Instead of dollars (or local currency), I store values internally as pennies (or local equivalent 1/100 of main currency). Sometimes when working with interest I'll need to work with floats, and some databases I have values stored as DECIMAL(8,2) instead of INT, but for the most part I've saved quite a few headaches by keeping my values in INTs.

Re: 9999999999999999.0 – 9999999999999998.0

#234

Post by dotancohen »

bigiain wrote: post #182
jes5199 wrote: post #177

Earlier quoted context omitted.

Have you worked on finance software? I have - we always used ints for everything, so we could avoid rounding suprises

I did a web project in the gambling space ~10 years back - we were legally required to perform all calculations as integers in ten thousandths of a cent (or millionths of a dollar). We chose to _not_ do _any_ calculations client side in Javascript...

Which regulation is that? I've worked on financial applications, but not gambling, and I've not heard of this regulation. I should probably know about it!

Re: 9999999999999999.0 – 9999999999999998.0

#235

Post by DougBTX »

jes5199 wrote: post #177
ChrisLomont wrote: post #174

Earlier quoted context omitted.

You cannot do anything in finance with such reasoning. Take something simple, say a mortgage at 5% compounded 12 times a year. To compute payments using some fixed length representation or decimal is going to lead to more error than to use the usual floating point. This rabbit hole would continue for many applications. Floating point makes them all much easier to do well.

Have you worked on finance software? I have - we always used ints for everything, so we could avoid rounding suprises

I’ve not done any real finance programming, so is this a reasonable explanation?

Currency is stored as a count of cents (millicents if being fancy). Therefore the two main features of floats are not useful:

- Support for very small numbers is not needed. Floats dedicate approx half their range to numbers between -1 and +1, this is wasted when counting whole cents.

- Support for very large numbers at the expense of precision is actively bad, as the precision must always be down to individual cents.

So the useful range of floats is much reduced when using floats for counting, approx 54 bits out of a 64 bit float are used. Instead ints (“counting numbers”) are much better for counting cents than floats (which approximate the continuous real numbers in a finite number of bits).

Re: 9999999999999999.0 – 9999999999999998.0

#236

Post by otabdeveloper2 »

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…

> it is much more likely to need to represent 0.30 than 1/3

Citation needed, because this isn't really true.

Even if one concedes your (unspoken) idea that only financial transactions aren't "academic" (which also isn't true), in the real world financial transactions will typically include currency conversions, and those will have all sorts of weird non-decimal factors.

Re: 9999999999999999.0 – 9999999999999998.0

#237

Post by CamouflagedKiwi »

dotancohen wrote: post #233
jacobolus wrote: post #202

Earlier quoted context omitted.

> Outside of the academic world decimals are almost always a better solution Is “academic world” now a shorthand for “all numerical computing”? Decimals basically never make sense, except possibly in some calculations related to money. Those make up a minuscule part of modern computer use. Maybe decimals are also better for homework assignments for schoolchildren? The type of applications where decimals are useful ar…

Even with money I use integers. Instead of dollars (or local currency), I store values internally as pennies (or local equivalent 1/100 of main currency). Sometimes when working with interest I'll need to work with floats, and some databases I have values stored as DECIMAL(8,2) instead of INT, but for the most part I've saved quite a few headaches by keeping my values in INTs.

That seems okay until you need to track sub-penny accuracy somewhere, then you have a big problem.

Lots of applications don't need that, but a surprising amount do, so it's not a global solution.

Re: 9999999999999999.0 – 9999999999999998.0

#238

Post by vanderZwan »

nestorD wrote: post #217
vanderZwan wrote: post #208

Earlier quoted context omitted.

> Thus, we aren't going to ever do better than floats if we are programming on physical computers that exist in this universe. Maybe, but that doesn't mean the particular implementation of floats being used is the best one. See also: Unums and Posits https://posithub.org/

To my understanding, experiments with Unums showed shortcoming that Gustafson didn't anticipate and lead to Posits which drop the fixed length constraint. Doing that makes improving precision a lot easier but at the cost of computation time. Overall I am not convinced that the current implementation is optimal but it is a very good trade-off between speed and precision.

> 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 a 16 or 8 bit posit suffices).

Posits are simpler to implement than IEEE floats (less edge cases) and use more bits for actual numbers whereas IEEE floats waste about half on NaNs. The use of tapered precision is also nice.

Re: 9999999999999999.0 – 9999999999999998.0

#239

Post by CodeArtisan »

sampo wrote: post #103
svat wrote: post #71

Earlier quoted context omitted.

> considering the problem is to fit the reals into 64/32/16 bits and have fast math Floating-point numbers (and IEEE-754 in particular) are a good solution to this problem, but is it the right problem? I think the "minimum of surprises" part isn't true. Many programmers develop incorrect mental models when starting to program, and get no feedback to correct them until much later (when they get surprised). It is true…

There is a proposal about "unum" or "posit" number system. They give more precision for small numbers (small meaning smaller than about 10^70, for 64bit numbers), less precision for huge numbers, and an overall larger range, than the floating point system. https://en.wikipedia.org/wiki/Unum_(number_format) http://www.johngustafson.net/pdfs/BeatingFloatingPoint.pdf (They are definitely not any easier to understand tha…

there is also DEC64

http://dec64.com/

Re: 9999999999999999.0 – 9999999999999998.0

#240

Post by ajanuary »

dotancohen wrote: post #234
bigiain wrote: post #182

Earlier quoted context omitted.

I did a web project in the gambling space ~10 years back - we were legally required to perform all calculations as integers in ten thousandths of a cent (or millionths of a dollar). We chose to _not_ do _any_ calculations client side in Javascript...

Which regulation is that? I've worked on financial applications, but not gambling, and I've not heard of this regulation. I should probably know about it!

I worked for a gambling company in the UK for a bit. They did all their maths in pennies, not thousandths of a penny.
Post reply on HN