Splitting Numeric to separate Sum from Product

On Tue, Sep 13, 2011 at 10:47 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

though care would have to be taken in cases where an operation on xRational would cause the numerator or denominator to overflow.

Question being: Care by who?

Continue with the C/Java tradition of letting the application programmer deal with overflow issues (silent issues no-less) or adopt the convention from Lisp/Clojure and probably other dynamic languages to have the runtime deal with overflows by silently convert to bigger types?

BR,
John

Hi,

> When I made my Rational type I chose BigInt simply because, if you are
> going out of the way to use Rational instead of Double, you probably
> care enough about precision (over speed) to want BigInt. Also, I felt
> that Rationals should be able to be constructed from any Double (or
> BigDecimal) without loss of precision.
>
> I think a Rational[T] type may not be the best choice; if the choice
> to use Long was REALLY wanted, I'd think it make more sense to have 2
> classes: Rational (Long) and BigRational (BigInt).
>
Rational feels more like something comparable to Complex and I think
both should have a type parameter, because there are valid use-cases for
different numeric types. And afaiu it doesn't cost us too much to have
it generic, because if people are willing to go through the whole
trouble with Numeric[T], why stop it when doing Rational?

Hi,

> If we were to make 3 / 4 ->
> Rational then I'm not sure that's such a great assumption anymore. I
> think it's hard to appreciate the performance impact this would have
> without doing a lot of profiling of existing Scala codebases first.
I don't think this is practical considering atrocities like the implicit
conversions from integer types to floating point numbers still exist,
thanks to "Java compatibility".

Actually ... If we would have chosen a sane symbol for String
concatenation instead of "+" and didn't add our own stuff with "a" * 3
== "aaa", having implicit conversions from String to BigDecimal would
have been a great idea, e. g. "1.0" + "2.0" * "3.5" for BigDecimal math
instead of BigDecimal("1.0") + BigDecimal("2.0") * BigDecimal("3.5".

Thanks and bye,

Simon

Hi,
>
> Continue with the C/Java tradition of letting the application
> programmer deal with overflow issues (silent issues no-less) or adopt
> the convention from Lisp/Clojure and probably other dynamic languages
> to have the runtime deal with overflows by silently convert to bigger
> types?
some time ago I wrote some math utility class which provided things like
+!, -!, *!, /! for overflow-safe math (e. g. throws an exception if an
overflow occurs) ... not sure if this would make sense. Imho this
probably needs some support with intrinsics to be fast.

Thaks and bye,

Simon