views:

104

answers:

2

I've created a class that can be parameterised by anything that can be converted to Numeric

class Complex[T <% Numeric[T]] (val real : T, val imag : T) {
   //... complex number methods ...
}

Then elsewhere in the code I try:

var myComplex = new Complex(0, 1)

This raises a compilation error because (surprisingly) there's no implicit conversion between Int and Numeric[Int] or even between Int and Integral[Int].

Am I missing something? Is there an implicit conversion somewhere I'm not seeing?

There's an implicit object called IntIsIntegral defined in Numeric.scala. I've tried using this to create my own implicit conversion method:

def implicit intToNumericInt(val i : Int)(implicit n : IntIsIntegral) = n.fromInt(i)

I'm surprised that this is required and, anyway, it seems to lead to an infinite recursion into the .fromInt method.

I'm sure that I'm missing something basic (as you can tell, I'm new to Scala) so would appreciate a point in the right direction.

As you can see from the example, I'm trying to get a Complex number implementation working which can accept and work with any Numeric type. I hope to contribute this to the scalala (linear algebra) project. Following that, I want to introduce a Trait which describes the responsibilities of elements in a matrix (mainly just + and * operators) and retrofit support for complex numbers into the matrix manipulation library.

+5  A: 

You are using it wrong. The correct usage is like this:

class Complex[T](val real : T, val imag : T)(implicit num: Numeric[T]) {
   import num._ // make implicit conversions available
   //... complex number methods ...
}

It is the same difference as in between Ordered and Ordering. An Ordered[T] instance can be compared to T, while an Ordering[T] provides a method that compares a a couple of T.

Daniel
From what I understand, the:T <% Numeric[T]is syntactic sugar for adding the (implicit num: Numeric[T])but I guess using the sugar means that I don't have the variable available to do:import num._ // make implicit conversions availableI did actually try the (implicit num : Numeric[T]) out but it didn't work for me. I'll report back tomorrow whether the import num._ helps! Thanks.
David Boden
@David: `T <% Numeric[T]` is a syntactic sugar for adding `(implicit ev: T => Numeric[T])`, and `T : Numeric[T]` is a syntactic sugar for adding `(implicit ev: Numeric[T])`. The first is called view bound, and the second is called typeclass bound.
missingfaktor
@missingfaktor The second is called a context bound, and happens to be used for the type class pattern.
Daniel
No, T <% Numeric[T] is a view bound. It is syntactic sugar for (implicit f: T => Numeric[T]).In contrast foo[T: Numeric] is syntactic sugar for (implicit x: Numeric[T]. This is a context bound. See http://gist.github.com/257758
michid
Works well. Thanks! I'm going to see how I get on extending this concept to arithmetic with the complex number class. With a normal Int and Double types when you do 3 + 0.5 you end up with a Double due to the Int 3 being implicitly upgraded. I'm going to implement the same thing for Complex[Int] and Complex[Double] (generally Complex[A] and Complex[B]) by requiring that there's a predefined implicit conversion between A and B (a function A => B). These conversions are already defined in Predef.scala.
David Boden
+2  A: 

In Scala 2.8, it can also be written as

class Complex[T: Numeric] (val real : T, val imag : T) {

  def +(that: Complex[T]) = {
    val r = implicitly[Numeric[T]].plus(this.real, that.real)
    val i = implicitly[Numeric[T]].plus(this.imag, that.imag)
    new Complex(r, i)
  }

}

This syntax is admittedly a bit dense, but it can be made more readable like this:

class Complex[T: Numeric] (val real : T, val imag : T) {
  val num = implicitly[Numeric[T]]

  def +(that: Complex[T]) = {
    new Complex(num.plus(this.real, that.real), num.plus(this.imag, that.imag))
  }

}

The declaration class C[T: M]( ... ) { val x = implicitly[M[T]] would seem to be equivalent to class C[T]( ... )(implicit x: M[T]) { import x._ as noted in the comments to the previous solution. It's not simply syntactic sugar, because there are differences in how it is compiled, e.g. in the first case x is a method, and in the second case it's a field.

Hoodiecrow
Looks like this will work too. At this stage, I think it's clearer having the (implicit num : Numeric[T]) then using import num._ rather than using the implicitly operation which looks a little like magic :) If I didn't want to import methods from Numeric then the syntax that you suggest would definitely be cleaner.
David Boden
I've updated the answer to take your comment into account.
Hoodiecrow