That "digits=18" in R example probably bothers me more than it should.
0.30000000000000004
21–30 of 140 posts
Re: 0.30000000000000004
#22It's stuff that should be a part of very beginning of any CS101. Float arithmetics != Decimal arithmetics
It is.
Re: 0.30000000000000004
#23Previous discussions: https://news.ycombinator.com/item?id=10558871 (1.5 years ago, 240 comments) https://news.ycombinator.com/item?id=1846926 (6.5 years ago, 128 comments)
I haven't seen it yet... what's with that final four (common to all languages)?
Floats can only represent fractions of powers of two. 0.3 is a fraction of powers of two and five.
See IEEE754
Re: 0.30000000000000004
#24Once 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 mantissa). Then choose such Y from [Y1, Y2] that Y has the shortest decimal representation.
Re: 0.30000000000000004
#25It'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)
It’s not obvious that 1/7 cannot be expressed in decimal, or 1/5 cannot be expressed in binary?
Re: 0.30000000000000004
#26Any time you're generating percentage data that should sum to 100, not appreciating floating point math will burn you. For those interested, the largest remainder method ( https://gist.github.com/hijonathan/e597addcc327c9bd017c ) is useful for dealing with this.
You should just round the percentages to the nearest value of the appropriate precision, and let them sum to slightly more or less than 100% if that’s how the numbers work out. If you want, add an asterisk and a “note, numbers do not sum to 100% because of rounding” at the bottom.
Re: 0.30000000000000004
#27>Perl 6, unlike Perl 5, uses rationals by default I'm not sure this is such a good idea. I love rational datatype, but it's too easy to shoot yourself in the foot with simple numerical procedures resulting in gigantic bignum denominators.
Rational numbers are horrible for most numerical computing. The denominators double in length with every multiplication, so computation speed gets slow exponentially.
Any time there’s any degree of uncertainty about a quantity (e.g. it comes from a physical measurement) there’s also no longer any advantage to using rational arithmetic. This turns out to encompass most practical situations.
Rational arithmetic also breaks down entirely in the face of square roots or trig functions, unless you go for a fully symbolic computation environment, which gets even much slower.
Rational arithmetic is mostly nice when the problems have been carefully chosen so the operations will stay rational and the answers will work out nicely, e.g. in high school homework.
Re: 0.30000000000000004
#28Re: 0.30000000000000004
#29Once 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…
You might be interested in interval arithmetics: https://en.wikipedia.org/wiki/Interval_arithmetic
Re: 0.30000000000000004
#30It'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)
If you can write n=p/q with p and q relatively prime using d digits after the decimal point in base 10, 10^d times n is an integer. We also have
10^d*n = 10^d*p/q