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

101–110 of 140 posts

Re: 0.30000000000000004

#101

Post by spc476 »

VLM wrote: post #50
msie wrote: post #20

It's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base. In a way, not so simple (obvious to you? not to me)

Modern, lets say, post turn of the century popular languages all support some kind of rational data type allowing native fraction arithmetic. https://en.wikipedia.org/wiki/Rational_data_type Anyway... It turns out that humans like numbers that are evenly spaced like 1/10, 2/10 (1/5), 3/10, 4/10. That all seems pretty evenly spaced to us, but its actually totally arbitrary that we have 10 handy (ugh the puns) appendag…

Thirty years ago the BASIC languages of the 8-bit computers used non-IEEE 754 floating point math (most typical I've found is 5-byte version---one byte for sign, one for exponent, three for mantissa).

Re: 0.30000000000000004

#102

Post by spc476 »

bsder wrote: post #84
hsivonen wrote: post #14

Earlier quoted context omitted.

Unsurprising considering the IBM affiliation of Rexx and decimal arithmetic being IBM’s pet issue.

The fact that we do binary floating point by default is an artifact of RAM being expensive way back in the day while arithmetic coprocessors became cheap. Single-precision is 4 bytes and can represent practically every quantity you care about precisely enough. While IBM has been harping about this for ages, BCD (binary coded decimal) was sufficiently important that it had special instructions on even the earliest mic…

And the 8086 (on up), the 68000 family, and the VAX also had BCD instructions. When I wrote my own 6809 emulator [1] the DAA instruction was the hardest one to get right [2]

[1] https://github.com/spc476/mc6809

[2] Specifically the condition code results.

Re: 0.30000000000000004

#103

Post by jacobolus »

jacobolus wrote: post #35
bcook wrote: 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…

Apparently the explanation in the linked article originally came from a Hacker News comment a year and a half ago, https://news.ycombinator.com/item?id=10560130

Re: 0.30000000000000004

#104

Post by gsg »

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.

Re: 0.30000000000000004

#105

Post by simonbyrne »

TazeTSchnitzel wrote: post #85
willlll wrote: post #80

Earlier quoted context omitted.

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.

Yeah, it's unfortunately not the fastest algorithm known, despite what was originally thought, but it is still the fastest accurate one.

Grisu isn't accurate?

Re: 0.30000000000000004

#106

Post by dnautics »

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

Re: 0.30000000000000004

#109

Post by Johnny_Brahms »

dragonwriter wrote: post #96
kr7 wrote: post #73

Earlier quoted context omitted.

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

This is solved by the Scheme numerical tower, which prefers exact representation​s (including exact rationals) unless inexact representation is explicitly requested or forced by an operation that doesn't support exact results.

The problem is remembering to only input rationals :) So instead of doing (iota 100 0.1 0.1), you do (iota 100 (/ 1 10) (/ 1 10)). That does not work in chicken for some reason.

I don't know if precomputation is ever guaranteed for those things, but otherwise it would be neat to be able to input rationals directly into the source.

Edit: So, this is scheme standard discovery week: apparently inputing 1/10 works just fine. I can't believe I missed this.

Re: 0.30000000000000004

#110

Post by sametmax »

jacobolus wrote: post #31
mkup wrote: 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…

Python does this, for example (but likely in a more efficient way): http://bugs.python.org/issue1580 See also http://www.netlib.org/fp/ http://web.archive.org/web/20060908072403/http://ftp.ccs.neu... So for instance 0.29999999999999993 + 0.00000000000000003 -> 0.3, but 0.30000000000000002 -> 0.30000000000000004 Note that this will still not solve the 0.1 + 0.2 problem from the OP, since the nearest float to 0.3 is no…

But Python also warns about it in the documentation, and provide the factions (https://docs.python.org/3.1/library/fractions.html) module and the decimal module thttps://docs.python.org/3.1/library/decimal.html) in the stdlib to avoid the problem.
Post reply on HN