Darren Duncan wrote
On 2015-06-16 2:15 PM, The Sidhekin wrote:
On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler mich...@zedeler.dk
wrote:
...and unpredictable performance is a cost you're willing to pay?
I don't write performance-critical applications, but even if I did, why
would
I prefer getting the wrong answer faster?
I agree with Sidhekin and similar mentalities.
On the range between safety/correctness and speed, a good programming
language /
tool should always default to the most safe/correct option when the user
doesn't
specify where on the range they want, and leave it to the power users to
explicitly make the trade-off when they know what they're doing.
In this case, people who explicitly want floats because of performance rather
than exact rationals do indeed count as power users.
I'd still pull out the argument that you want the least surprising behavior. Of
course, I would prefer being able to add two rational numbers with very large
denominators and have the underlying machinery shorten the result for me, but
the performance hit is easy to great. Am I missing something here, or wouldn't
most people expect addition to be a constant time operation?
Imagine a really simple operation: a script that takes a spread sheet, parses
it and writes out the weighted average of some of the columns. Anyone would
expect that if 40,000 rows takes 1 second to process, then 80,000 takes 2. With
Perl 6 not do much. You'd have to switch to power user mode to get that kind
of predictability.
Normal people are more interested in not being surprised by the answers they
get
to what should be common-sense questions, such as when adding 10.3 to 14.2.
So far, almost every other language has behaved this way, and it has worked. I
can see that Rats do solve a problem, but if you'd claim that it is very severe
then I'd disagree. This is a minor nuisance that I'd only pay a small price to
fix.
I should also point out that finance / anything to do with money is an
extremely
common use case that cares very much about math being exact, its not just
esoteric science applications.
I doubt that Rats is a complete solution to the problems you have to solve when
it come to represent monetary values. My take is you'd need very specific
rounding algorithms when you convert to a fixed number of digits.
I believe my example with the spread sheet is much more mundane.
This all being said, I draw the line where implementing is much more
complicated
to serve esoteric cases. So for example while exact precision rationals
absolutely should be default / part of core, something like symbolic values
eg
exact representations of irrational numbers, are perfectly valid to, and
probably shouldn't, be part of core. Exact rationals are not particularly
complicated. Its perfectly reasonable to expect in the core that if someone
does math that is known to deal with irrationals in general, that loss of
precision then is acceptable.
Just to be sure that we are taking about the same thing:
An ideal Rat implementation should be able to always output the least possible
denominator, right?
And if I happen to add some rational numbers that involve, say, very very large
prime numbers (intentionally or not), it's clear that the result probably can't
be shortened much, but the run time of the underlying algorithm may explode.
..and that is acceptable behavior?
..or did I miss something?
M.
--
Michael Zedeler
70 25 19 99
mich...@zedeler.dk
dk.linkedin.com/in/mzedeler |twitter.com/mzedeler | github.com/mzedeler
