Why does trait Numeric[T] extend Ordering[T]?

Removing Ordering[A] as a dependency would also mean that Numeric[A] could be specialized. There really would be a benefit to it.

On Sun, Jul 18, 2010 at 12:55 PM, <polyomino@f2s.com> wrote:

Hi,

(I'm a newbie, so apologies for if I'm missing the point.)

In scala.math, I see that trait Numeric[T] extends Ordering[T]. Why is that?

In mathematics, the two concepts are unrelated. For example, the complex numbers
are numeric, but not ordered (and there are many other examples, such as p-adic
numbers, algebraic number fields, etc).

What are the implications if one wanted to define a class for complex numbers?

(Is scala-user the right list for questions of this type, or would scala be
better?)

Thanks, David

On Sun, Jul 18, 2010 at 11:55:10AM +0100, polyomino@f2s.com wrote:
> (I'm a newbie, so apologies for if I'm missing the point.)
>
> In scala.math, I see that trait Numeric[T] extends Ordering[T]. Why is
> that?

You are absolutely right, it shouldn't. Here is why it does: at the
time I was writing those classes it was inordinately tedious to have to
draw in multiple implicits any time you wanted to abstract across the
basic numeric types, this being before context bounds, prioritized
implicits, and other improvements of the last year. So I promoted
convenience for the shipping use case (which is: abstracting across six
primitive types, BigInt, BigDecimal) where they're all obviously
ordered.

When you start trying to push Numeric beyond the everyday types the
interface will have either too much or too little. Why should complex
numbers have to implement toFloat? Why isn't Numeric broken down into
abelian groups and rings and monoids and semigroups and whatever other
ways there are to further break it down? Those things are great and it
would be a lot of fun to write them, but I'm trying to cover a thousand
mile wide frontier over here.

Also (and this part is important because I am sure it will be coming up
more than once now that 2.8 is out) it's been like that for over a year
and we're only having this discussion now. Which doesn't mean you're
wrong to bring it up -- quite the opposite -- but I could have used a
lot more feedback over the last two years. I'd forgotten about this
one, and had anyone brought it up the last six months I expect I'd have
rearranged things. Now that 2.8 is out we'll have to live with all my
questionable decisions for the moment.

So I would say the realistic thing to do is treat Numeric as a model for
the "type class pattern" (it was the first one in trunk, or nearly so)
and a simple mechanism for abstracting across the type which is missing
from our inheritance hierarchy (i.e. AnyVal but not Boolean or Unit or
Char) but not as any kind of definitive interface for those entities one
might describe as numeric.

Maybe this is more a case of term overloading across different domains of intellectual discourse?

Perhaps coming up with an implementation of ZFC, outside the scala core, would be an interesting project?

Brian Maso

Sent via BlackBerry by AT&T

-----Original Message-----
From: Paul Phillips
Date: Sun, 18 Jul 2010 10:09:13
To:
Cc:
Subject: Re: [scala-user] Why does trait Numeric[T] extend Ordering[T]?

On Sun, Jul 18, 2010 at 11:55:10AM +0100, polyomino@f2s.com wrote:
> (I'm a newbie, so apologies for if I'm missing the point.)
>
> In scala.math, I see that trait Numeric[T] extends Ordering[T]. Why is
> that?

You are absolutely right, it shouldn't. Here is why it does: at the
time I was writing those classes it was inordinately tedious to have to
draw in multiple implicits any time you wanted to abstract across the
basic numeric types, this being before context bounds, prioritized
implicits, and other improvements of the last year. So I promoted
convenience for the shipping use case (which is: abstracting across six
primitive types, BigInt, BigDecimal) where they're all obviously
ordered.

When you start trying to push Numeric beyond the everyday types the
interface will have either too much or too little. Why should complex
numbers have to implement toFloat? Why isn't Numeric broken down into
abelian groups and rings and monoids and semigroups and whatever other
ways there are to further break it down? Those things are great and it
would be a lot of fun to write them, but I'm trying to cover a thousand
mile wide frontier over here.

Also (and this part is important because I am sure it will be coming up
more than once now that 2.8 is out) it's been like that for over a year
and we're only having this discussion now. Which doesn't mean you're
wrong to bring it up -- quite the opposite -- but I could have used a
lot more feedback over the last two years. I'd forgotten about this
one, and had anyone brought it up the last six months I expect I'd have
rearranged things. Now that 2.8 is out we'll have to live with all my
questionable decisions for the moment.

So I would say the realistic thing to do is treat Numeric as a model for
the "type class pattern" (it was the first one in trunk, or nearly so)
and a simple mechanism for abstracting across the type which is missing
from our inheritance hierarchy (i.e. AnyVal but not Boolean or Unit or
Char) but not as any kind of definitive interface for those entities one
might describe as numeric.