Splitting Numeric to separate Sum from Product

Hi Tom,

Thanks for your thoughtful reply and description of your use case. I'm
sorry if I came off as hostile but I couldn't tell if you actually
needed the current Numeric behavior or were just playing devil's
advocate.

First of all, is your library online? I have been working on my own
classes for complex and rational numbers and would love to see what
you've come up with. And please feel free to give me feedback on my own
Numeric project.

It does sound like our cases are different. In one of my cases, I am
dealing with large (e.g. 100M cells) grid of numbers (could be 64-bit
floating point, 32-bit integer, whatever) which represents some kind of
geographical data (e.g. elevation data, soil type, etc). I want to be
able to write operations which work no matter what the underlying data
type is, without having to convert the underlying data type, or
duplicate code.

Operations on this data might include division, for instance when
converting units, rescaling or normalizing data. In these cases,
maintaining exact precision is usually less important since the data is
usually already aggregated/sampled. Instead we are very focused on
performance, since we need to be able to do this processing at
"web-appropriate speeds".

Floor division and true division definitely are different operations,
but I think even the fact that we use the same operator symbol for both
shows that we consider them somewhat analogous. While abstracting
across integral/fractional types may be inappropriate in some contexts,
do you think it's *always* inappropriate and should be forbidden?

I strongly believe there needs to be some way to do this in Scala (as
there is in most dynamically typed languages, e.g. Clojure, Python,
Ruby, etc). Java completely lacks this ability and I think it is a
feather in Scala's cap that it is possible.

I wonder if there isn't a way to achieve the kind of "numeric precision
tracking" which you're doing in a better way, rather than using the
(current) properties of Fractional and Numeric? This could involve
creating additional type classes which group the types according
to which operations they can use while maintaining precision.

I suggest this because everyone has different ideas of how much
precision they need. In my case, I'm willing to be limited to the
precision of the underlying data type. In finance, I think most people
don't need to use Rational (because they don't need infinite precision
on fractions like 1/3, but only as much as they need) and are willing
to consider division on BigDecimal "precise enough". In your case, you
don't want to lose *any* precision. I don't think we can settle this
issue just one way, because everyone has their own requirements.