---- 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
