Live data from Hacker News

0.30000000000000004

0.30000000000000004.com

71–80 of 140 posts

Re: 0.30000000000000004

#71
post #70
post #68

Earlier quoted context omitted.

I absolutely disagree with your disagreement. Please try writing an ERP system where you have a quantity of a billionth of an item price of a billion euros (or an item price of a billionth Euro and a quantity of billions) and tell me which integer type you deem sufficient for this. Additionally please research decimal floating points before disagreeing.

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

Re: 0.30000000000000004

#72
post #68

Earlier quoted context omitted.

I absolutely disagree. If you want to represent currency, for example, you should not use decimal floating point. You should integers, specifically you should use an integer number of tenths of cents, which is pretty widely agreed as the standard unit of currency in a computer (or tenths of yen, for example). You need to be extremely careful about overflow, but you need to be anyway, and should almost certainly just…

I absolutely disagree with your disagreement. Please try writing an ERP system where you have a quantity of a billionth of an item price of a billion euros (or an item price of a billionth Euro and a quantity of billions) and tell me which integer type you deem sufficient for this. Additionally please research decimal floating points before disagreeing.

[deleted]

Re: 0.30000000000000004

#73
post #56

For people using C or C++ I can recommend using decimal floating point (which may be added to C++20 in the standard). Contrary to the "default" floating point, which are base 2 and do not support precise presentations of certain numbers, you can use a decimal floating point system which uses base 10 and therefore allows exact and precise presentation and solves the problem mentioned on the page. Also important: since…

Then people will just make novelty websites to point out that 1/7 + 2/7 ≠ 3/7.

Re: 0.30000000000000004

#74
Base 2 floating point is perfectly OK. The problem is people using floating point not knowing that IEE754 floating point representation is binary, and not decimal, so most decimal constants will not have an exact match. Said that, many implementations do buggy binary decimal conversions, not because of the limit accuracy in the conversion, but because of "creative" rounding criteria.

Re: 0.30000000000000004

#75
post #73
post #56

For people using C or C++ I can recommend using decimal floating point (which may be added to C++20 in the standard). Contrary to the "default" floating point, which are base 2 and do not support precise presentations of certain numbers, you can use a decimal floating point system which uses base 10 and therefore allows exact and precise presentation and solves the problem mentioned on the page. Also important: since…

Then people will just make novelty websites to point out that 1/7 + 2/7 ≠ 3/7.

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

Please research decimal floating point first..

Re: 0.30000000000000004

#76

> Your language isn't broken, it's doing floating point math. Yes, your language is broken if you have no way out of floating point math. JavaScript, for example, is fundamentally broken.

There are a huge pile of libraries for doing bignum, rational, fixed point, decimal, complex, vector, polynomial, symbolic, etc. math in Javascript. If you want you can even write one for 7-adic arithmetic, Eisenstein integers, numbers expressed in the golden ratio base, or points on the surface of a torus. There’s no language that can build in all possible number systems, and it’s not really the place of a language…

Yes, every Turing complete language can build integers and other types of numbers atop floating point numbers if necessary. That doesn't make it any less broken.

Re: 0.30000000000000004

#77
post #71
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

This is clearly why you should price everything in picodollars :) https://www.tarsnap.com/

Re: 0.30000000000000004

#79
post #33

Earlier quoted context omitted.

>I thought people learned this sort of thing in grade school. Along with tact and general respect for others?

This is a discussion of the vagaries of floating point math, on a forum for programmers. I would expect that most folks learned something about how to carry out decimal long division in ~3th–6th grade sometime. If we can’t assume any kind of common base-line level of background experience but need to re-hash all of school mathematics in every conversation, then it’s hard to have a technical discussion. There’s absolu…

>If we can’t assume any kind of common base-line level of background experience but need to re-hash all of school mathematics in every conversation, then it’s hard to have a technical discussion.

We can have any kind of discussion we want, but whatever the participant's level of understanding, talking down to them is unacceptable. You don't need to dumb things down here, but when someone doesn't understand what you meant, you can ignore it or help out, just don't be condescending.

Re: 0.30000000000000004

#80
post #24

Once I wrote a library for double-to-string conversion and vice versa, which handles such roundings nicely: https://github.com/mkupchik/dconvstr Key idea is not just to map binary floating point value X to a decimal floating point value Y, but instead (in extended precision, with 64-bit mantissa) compute an interval of decimal floating point values [Y1, Y2] which maps back to X (in standard precision, with 53-bit man…

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.

Post reply on HN