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

0.30000000000000004

0.30000000000000004.com

Post reply on HN
Print view View original

111–120 of 140 posts

Re: 0.30000000000000004

#111

Post by thaumasiotes »

kirab wrote: post #71
chiph wrote: post #70

Earlier quoted context omitted.

I'm having trouble visualizing this. The closest I could get is a single unique part for an A380 super-jumbo (typical selling price: $435 million USD)

Imagine a contract which says the contract partner receives e.g. 0.001% of the total revenue for the fiscal year (which could be 10bn Euros) Or you do have a gram price and are selling literally thousands of tons to a big business

> Imagine a contract which says the contract partner receives e.g. 0.001% of the total revenue for the fiscal year (which could be 10bn Euros)

I'm imagining it, and I don't see why storage or computation time would be major obstacles to a calculation you run once a year. Use whatever big integers you want?

Suppose we dedicated one $100 hard drive (per year!) to storing all the relevant data. I feel like there would be plenty of space left over, and the budget would cover it.

Re: 0.30000000000000004

#112

Post by lispm »

gsg wrote: post #104

The Common Lisp answer is 0.3 and not 0.30000000000000004 because those are single float literals: for double float literals, we have (+ 0.1d0 0.2d0) => 0.30000000000000004d0. I would imagine this is the case for several of the other examples, too.

You can tell Common Lisp to read double-floats by default.

    CL-USER 113 > (+ 0.1 0.2)
    0.3

    CL-USER 114 > *read-default-float-format*
    SINGLE-FLOAT

    CL-USER 115 > (setf *read-default-float-format* 'double-float)
    DOUBLE-FLOAT

    CL-USER 116 > (+ 0.1 0.2)
    0.30000000000000005
Thus if one wants to make sure which float format Lisp should be reading,

a) specify the default format, as above

b) or use s, f, d, and l to specify the format (short float, single float, double-float, long-float). Example 1.0s0, 1.0f0, 1.0d0, 1.0l0

Re: 0.30000000000000004

#113

Post by PeterStuer »

Side anecdote: Many, many years ago, I wrote a lease payment plan calculator for a big bank-linked leasing company when they moved from AS/400 to .Net. I made sure all rounding was policy driven, not only in precision, but also in where roundings would occur during the calculations. 1 cent differences do matter in such environments. Somehow it passed all the extensive regression tests that compared to their mainframe code out of the box with the config based on nothing more than my guesses. AFAIK the code is still in production to this date.

Re: 0.30000000000000004

#114

Post by [deleted] »

3JPLW wrote: post #95
kirab wrote: post #75

Earlier quoted context omitted.

But in decimal floating point this is also solved: 1/7 + 2/7 = 3/7 Please research decimal floating point first..

That particular example happens to work, but 1/7 + 1/7 != 2/7. DecFP is not magic. You still need to know that you're dealing with limited precision numbers under the hood.

[deleted]

Re: 0.30000000000000004

#115

Post by kirab »

3JPLW wrote: post #95
kirab wrote: post #75

Earlier quoted context omitted.

But in decimal floating point this is also solved: 1/7 + 2/7 = 3/7 Please research decimal floating point first..

That particular example happens to work, but 1/7 + 1/7 != 2/7. DecFP is not magic. You still need to know that you're dealing with limited precision numbers under the hood.

You are right, that example doesn't work. I thought the rounding and normalization described in the standard may fix all these cases by itself but there I was wrong.

But at least all problems that could happen on a financial application are solved with decimal floating points (where you will only want to use rationals in finite decimal form like 0.01)

And even your example can be made working pretty easily:

  #include 

  int main(int /*argc*/, char **/*argv*/)
  {
    using namespace std;

    using namespace decimal;
    decimal128 d1 = 1;
    decimal128 d2 = 2;
    decimal128 d7 = 7;
    uint64_t conversionFactor = 10000000000000000000ull;
    cout
That was done using the gcc included decimal types. And if you look e.g. into the intel dfp library readme, you see lots of functions which will allow you to do the comparison you wanted to do: https://software.intel.com/sites/default/files/article/14463...

Re: 0.30000000000000004

#116

Post by murkle »

willlll wrote: post #80
TazeTSchnitzel wrote: post #62

Earlier quoted context omitted.

The state-of-the-art is the Errol algorithm of Adrysco, Jhala and Lerner (2016), which is proven to be always correct: https://cseweb.ucsd.edu/~lerner/papers/fp-printing-popl16.pd...

https://github.com/marcandrysco/Errol > Our original evaluation of Errol against the prior work of Grisu3 was erroneous. The evaluation indicates a 2x speed improvement over Grisu3. However, corrected performance measurements show a 2x speed loss to Grisu3.

Chromium uses Grisu3 (C++) https://chromium.googlesource.com/v8/v8/+/f837290e142d49c9e1...

as does Rhino (Java) https://github.com/mozilla/rhino/blob/master/src/org/mozilla...

Re: 0.30000000000000004

#117

Post by kirab »

thaumasiotes wrote: post #111
kirab wrote: post #71

Earlier quoted context omitted.

Imagine a contract which says the contract partner receives e.g. 0.001% of the total revenue for the fiscal year (which could be 10bn Euros) Or you do have a gram price and are selling literally thousands of tons to a big business

> Imagine a contract which says the contract partner receives e.g. 0.001% of the total revenue for the fiscal year (which could be 10bn Euros) I'm imagining it, and I don't see why storage or computation time would be major obstacles to a calculation you run once a year. Use whatever big integers you want? Suppose we dedicated one $100 hard drive (per year!) to storing all the relevant data. I feel like there would b…

But which advantage would this have over using IEEE 754-2008 decimal floating point numbers?

Re: 0.30000000000000004

#118

Post by xg15 »

The fun thing is that in the case of an "accurate" result (0.3), you can't be sure whether the language arrived there by somehow doing accurate floating point math - or by following the PHP way of first rounding in base 2, then rounding again in base 10, thus making the result even more inaccurate.

Re: 0.30000000000000004

#119

Post by jhanschoo »

dnautics wrote: post #106
zeotroph wrote: post #58

Whenver IEEE 754 and its quirks are discussed a potential alternative (but so far without hardware support) called Unum - Universal Numbers - should not go unmentioned: https://en.wikipedia.org/wiki/Unum_(number_format) Previous discussions (>2y old): https://news.ycombinator.com/item?id=9943589 and https://news.ycombinator.com/item?id=10245737 A slideset: https://www.slideshare.net/insideHPC/unum-computing-an-energ.…

Just a heads up - we're moving on from the unums standard. https://youtu.be/aP0Y1uAA-2Y

A note on the posit (aka sigmoid) standard that Gustafson discusses in the video:

1. Main feasibility benefit: behaves like IEEE 754 numbers in terms of accuracy.

2. Main performance benefit: able to match IEEE 754 precision & accuracy in fewer bits (~1/2) than IEEE 754.

3. When the standard is finalized, will specify behavior that in IEEE 754 allows for a degree of interpretation, meaning that behavior may not be reproducible across runs and machines.

4. IEEE 754 error-handling, that requires extra silicone or cycles, is not implemented. Overflow/underflow not considered errors leading to Inf or NaN, but rounded to nearest representation, hence has uniform treatment (rounding) across numbers with no exact representation. Illegal operations to be handled as general error à la integers rather than giving rise to NaN.

4a. Performance benefit: 4. should mean that less silicone or cycles required to perform arithmetic compared to IEEE 754, so Gustafson believes, though his team has only just finished with an ALU/FPU circuit schematic for posits.

4b. Programming using posits should feel more like programming using integers, versus handling NaN, Inf.

Post reply on HN