Not sure if I like or dislike Perl6 decision to use rationals by default; so 0.1 is saved as 1/10 and 0.2 as 2/10 and the calculation is precise. But also possibly slow.
0.30000000000000004
51–60 of 140 posts
Re: 0.30000000000000004
#52Whats going on in the second D example?
The "f" suffix means they are single-precision (32-bit) FP numbers.
Re: 0.30000000000000004
#53SBCL: * (+ (/ 1 10)(/ 2 10)) 3/10
It's great that your language of choice has fraction support - but real-world engineering problems rarely involve simple rational fractions exclusively. At some point you're going to run into roundoff error. Plus, fractional computing has severe problems with expanding denominators, which grow very quickly with non-trivial operands. Although computers are fast, the overhead of dealing with hundred-digit-long arbitrar…
It's a trade-off between speed and accuracy. Not all software deals with real-world engineering problems, and there are plenty of applications where you would prefer accuracy.
I'd rather make that trade-off myself than have the language decide for me. Most of the time I would start with correctness and if speed is needed and the profiler shows that the bottleneck lies in fractional arithmetic, I'll switch to floating point numbers.
A similar trade-off exists with bignums versus 32 or 64 bit integers. There again, I prefer a language that uses bignums by default. I'll convert the bottlenecks to use fixnums after I've verified that it is safe to do so.
Re: 0.30000000000000004
#54>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.
default doesn't mean only, from memory Rakudo smooshes Rats into floating point Nums when the denominator gets above 2 to the 64th or so.
FatRat are an infinite precision rat. FatRats, like RATs are Cool (which is a double entendre, because Cool means it knows how to be a string, which is apparently "Cool") The default recently has not been fatrat but one of the many benefits of a language under development for 20 years is that quite possibly that default was changed last weekend. Or maybe fatrat were default for a painful week back in '02. Probably not, but it could have happened.
Perl does the right thing but if you're really unhappy about not using floats you can force a .num conversion into floating point or you could express a number in scientific notation to force floats. Perl really wants to make a division problem into a Rat unless you work hard to stop it.
In general, for the past 30 years or so, if you're doing something weird, Perl will work and probably give faster and possibly more accurate results than most other tools, but the rest of the world will not be interested in debugging perl6 but will instead be asking "why you use perl6 instead of Gnu-R or mathematica or ?" or whatever is trendy momentarily today. Perl will never be trendy yet the whole world runs on it.
Re: 0.30000000000000004
#55C# is missing an example using decimal type:
Decimal uses 128 bits to hold it's data and seems to handle rounding differently to System.Double, e.g. 0.1 and 0.2 using decimals evaulates to 0.3:
> 0.1M + 0.2M 0.3
You can read more about decimal here: https://msdn.microsoft.com/en-us/library/364x0z75.aspx
Re: 0.30000000000000004
#56For 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 2008 this is standardized in IEEE 754-2008 which added support for decimals.
Explanation of decimal floating points: https://en.m.wikipedia.org/wiki/Decimal_floating_point
Libraries:
https://software.intel.com/en-us/articles/intel-decimal-floa...
http://www.bytereef.org/mpdecimal/
http://speleotrove.com/decimal/
C++ Standard Proposals:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n340...
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3871.ht...
Re: 0.30000000000000004
#57It'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…
> appendages
a.k.a. digits!
Re: 0.30000000000000004
#58Whenver 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...
Re: 0.30000000000000004
#59Earlier quoted context omitted.
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 https://en.m.wikipedia.org/wiki/IEEE_floating_point https://en.m.wikipedia.org/wiki/IEEE_754-1985
> See IEEE754
Only in the original 1985 version, however: IEEE 754-2008 actually specifies decimal floating point types; decimal arithmetic was already specified in IEEE 854-1987. Of course, the default representation is almost always one of the binary formats, but that is no longer the only option.