Number class

The short answer is no.

The long answer is that it looks like 2.8.0 might have it. (See, for example, http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scalax/Numeric.scala). And I see no reason why you couldn't backport this into 2.7.x yourself. I'll warn you, however, that this approach comes with significant run time performance penalties.

--j

On Mon, Feb 9, 2009 at 5:47 PM, Gabriel Claramunt <gclaramunt@optonline.net> wrote:

Does Scala have a "Number" class/interface akin to Haskell's Num typeclass? I'm re-inventing the 2D vector wheel and I want to be able to back it Float or Integers

Thanks!

Why does it incur significant runtime penalties?

2009/2/10 Jorge Ortiz <jorge.ortiz@gmail.com>

The short answer is no.

The long answer is that it looks like 2.8.0 might have it. (See, for example, http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scalax/Numeric.scala). And I see no reason why you couldn't backport this into 2.7.x yourself. I'll warn you, however, that this approach comes with significant run time performance penalties.

--j

On Mon, Feb 9, 2009 at 5:47 PM, Gabriel Claramunt <gclaramunt@optonline.net> wrote:

Does Scala have a "Number" class/interface akin to Haskell's Num typeclass? I'm re-inventing the 2D vector wheel and I want to be able to back it Float or Integers

Thanks!

Oy, brain fart. For some reason I thought it used views instead of of type classes.

It has a moderate performance penalty, but no worse than 2x optimal in my tests.

--j

On Mon, Feb 9, 2009 at 11:01 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Why does it incur significant runtime penalties?

2009/2/10 Jorge Ortiz <jorge.ortiz@gmail.com>

The short answer is no.

The long answer is that it looks like 2.8.0 might have it. (See, for example, http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scalax/Numeric.scala). And I see no reason why you couldn't backport this into 2.7.x yourself. I'll warn you, however, that this approach comes with significant run time performance penalties.

--j

On Mon, Feb 9, 2009 at 5:47 PM, Gabriel Claramunt <gclaramunt@optonline.net> wrote:

Does Scala have a "Number" class/interface akin to Haskell's Num typeclass? I'm re-inventing the 2D vector wheel and I want to be able to back it Float or Integers

Thanks!

Depends what you consider "optimal" really. It's certainly a significant amount more than 2x vs. using primitives directly. Maybe Iulian's work on specialisation will help with that eventually though.

On Tue, Feb 10, 2009 at 8:14 AM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

Oy, brain fart. For some reason I thought it used views instead of of type classes.

It has a moderate performance penalty, but no worse than 2x optimal in my tests.

--j

On Mon, Feb 9, 2009 at 11:01 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Why does it incur significant runtime penalties?

2009/2/10 Jorge Ortiz <jorge.ortiz@gmail.com>

The short answer is no.

The long answer is that it looks like 2.8.0 might have it. (See, for example, http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scalax/Numeric.scala). And I see no reason why you couldn't backport this into 2.7.x yourself. I'll warn you, however, that this approach comes with significant run time performance penalties.

--j

On Mon, Feb 9, 2009 at 5:47 PM, Gabriel Claramunt <gclaramunt@optonline.net> wrote:

Does Scala have a "Number" class/interface akin to Haskell's Num typeclass? I'm re-inventing the 2D vector wheel and I want to be able to back it Float or Integers

Thanks!

Really? I'd like to see your benchmarks.

On Tue, Feb 10, 2009 at 4:03 AM, David MacIver <david.maciver@gmail.com> wrote:

Depends what you consider "optimal" really. It's certainly a significant amount more than 2x vs. using primitives directly. Maybe Iulian's work on specialisation will help with that eventually though.

On Tue, Feb 10, 2009 at 8:14 AM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

Oy, brain fart. For some reason I thought it used views instead of of type classes.

It has a moderate performance penalty, but no worse than 2x optimal in my tests.

--j

On Mon, Feb 9, 2009 at 11:01 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Why does it incur significant runtime penalties?

2009/2/10 Jorge Ortiz <jorge.ortiz@gmail.com>

The short answer is no.

The long answer is that it looks like 2.8.0 might have it. (See, for example, http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scalax/Numeric.scala). And I see no reason why you couldn't backport this into 2.7.x yourself. I'll warn you, however, that this approach comes with significant run time performance penalties.

--j

On Mon, Feb 9, 2009 at 5:47 PM, Gabriel Claramunt <gclaramunt@optonline.net> wrote:

Does Scala have a "Number" class/interface akin to Haskell's Num typeclass? I'm re-inventing the 2D vector wheel and I want to be able to back it Float or Integers

Thanks!

On Tue, Feb 10, 2009 at 4:03 AM, David MacIver wrote:
> Depends what you consider "optimal" really. It's certainly a significant
> amount more than 2x vs. using primitives directly. Maybe Iulian's work on
> specialisation will help with that eventually though.

Is there a pointer to his work on this? I'm very curious to see what's
in the works on this front.

http://lampsvn.epfl.ch/trac/scala/browser/scala/branches/specialized is the branch for it I think. I don't think there's anywhere other than that to look at the moment.

On Tue, Feb 10, 2009 at 7:56 PM, David Hall <david.lw.hall@gmail.com> wrote:

On Tue, Feb 10, 2009 at 4:03 AM, David MacIver <david.maciver@gmail.com> wrote:
> Depends what you consider "optimal" really. It's certainly a significant
> amount more than 2x vs. using primitives directly. Maybe Iulian's work on
> specialisation will help with that eventually though.

Is there a pointer to his work on this? I'm very curious to see what's
in the works on this front.

Awesome!

On Tue, Feb 10, 2009 at 12:00 PM, David MacIver wrote:
> http://lampsvn.epfl.ch/trac/scala/browser/scala/branches/specialized is the
> branch for it I think. I don't think there's anywhere other than that to
> look at the moment.
>
> On Tue, Feb 10, 2009 at 7:56 PM, David Hall wrote:
>>
>> On Tue, Feb 10, 2009 at 4:03 AM, David MacIver
>> wrote:
>> > Depends what you consider "optimal" really. It's certainly a significant
>> > amount more than 2x vs. using primitives directly. Maybe Iulian's work
>> > on
>> > specialisation will help with that eventually though.
>>
>> Is there a pointer to his work on this? I'm very curious to see what's
>> in the works on this front.
>>

Is there some theory/explnanation of it?
Perhaps Iulian would care to endulge me/us? :)

On Tue, Feb 10, 2009 at 9:18 PM, David Hall <david.lw.hall@gmail.com> wrote:

Awesome!

On Tue, Feb 10, 2009 at 12:00 PM, David MacIver <david.maciver@gmail.com> wrote:
> http://lampsvn.epfl.ch/trac/scala/browser/scala/branches/specialized is the
> branch for it I think. I don't think there's anywhere other than that to
> look at the moment.
>
> On Tue, Feb 10, 2009 at 7:56 PM, David Hall <david.lw.hall@gmail.com> wrote:
>>
>> On Tue, Feb 10, 2009 at 4:03 AM, David MacIver <david.maciver@gmail.com>
>> wrote:
>> > Depends what you consider "optimal" really. It's certainly a significant
>> > amount more than 2x vs. using primitives directly. Maybe Iulian's work
>> > on
>> > specialisation will help with that eventually though.
>>
>> Is there a pointer to his work on this? I'm very curious to see what's
>> in the works on this front.
>>
>> -- David
>>
>> >
>> > On Tue, Feb 10, 2009 at 8:14 AM, Jorge Ortiz <jorge.ortiz@gmail.com>
>> > wrote:
>> >>
>> >> Oy, brain fart. For some reason I thought it used views instead of of
>> >> type
>> >> classes.
>> >>
>> >> It has a moderate performance penalty, but no worse than 2x optimal in
>> >> my
>> >> tests.
>> >>
>> >> --j
>> >>
>> >> On Mon, Feb 9, 2009 at 11:01 PM, Ricky Clarkson
>> >> <ricky.clarkson@gmail.com>
>> >> wrote:
>> >>>
>> >>> Why does it incur significant runtime penalties?
>> >>>
>> >>> 2009/2/10 Jorge Ortiz <jorge.ortiz@gmail.com>
>> >>>>
>> >>>> The short answer is no.
>> >>>>
>> >>>> The long answer is that it looks like 2.8.0 might have it. (See, for
>> >>>> example,
>> >>>>
>> >>>> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scalax/Numeric.scala).
>> >>>> And I see no reason why you couldn't backport this into 2.7.x
>> >>>> yourself. I'll
>> >>>> warn you, however, that this approach comes with significant run time
>> >>>> performance penalties.
>> >>>>
>> >>>> --j
>> >>>>
>> >>>> On Mon, Feb 9, 2009 at 5:47 PM, Gabriel Claramunt
>> >>>> <gclaramunt@optonline.net> wrote:
>> >>>>>
>> >>>>> Does Scala have a "Number" class/interface akin to Haskell's Num
>> >>>>> typeclass? I'm re-inventing the 2D vector wheel and I want to be
>> >>>>> able to
>> >>>>> back it Float or Integers
>> >>>>>
>> >>>>> Thanks!
>> >>>>>
>> >>>>> --
>> >>>>> Gabriel Claramunt
>> >>>>> http://gabrielsw.blogspot.com
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>
>

--
Viktor Klang
Senior Systems Analyst

Sorry Iulian, I didn't mean to put you on the spot like this. :-)

As I understand it the basic idea is that there is / will be a @specialised annotation that, when applied to type parameters of classes or methods, will cause specialised versions to be generated for primitive classes, allowing one to avoid boxing.

So suppose I have

def foo[@specialized T](n : Int) = new Array[T](n);

Currently what will happen when I do

val x = foo[Int](3);

is that a polymorphic boxed array will be generated and then converted to an Array[Int];

With specialisation what will happen is that this will be translated to

val x = foo$somemangling(3)

where

def foo$somemangling(n : Int) = new Array[Int](3);

At least that's what I've gathered. I may have the wrong end of the stick.

On Tue, Feb 10, 2009 at 8:26 PM, Viktor Klang <viktor.klang@gmail.com> wrote:

Is there some theory/explnanation of it?
Perhaps Iulian would care to endulge me/us? :)

On Tue, Feb 10, 2009 at 9:18 PM, David Hall <david.lw.hall@gmail.com> wrote:

Awesome!

On Tue, Feb 10, 2009 at 12:00 PM, David MacIver <david.maciver@gmail.com> wrote:
> http://lampsvn.epfl.ch/trac/scala/browser/scala/branches/specialized is the
> branch for it I think. I don't think there's anywhere other than that to
> look at the moment.
>
> On Tue, Feb 10, 2009 at 7:56 PM, David Hall <david.lw.hall@gmail.com> wrote:
>>
>> On Tue, Feb 10, 2009 at 4:03 AM, David MacIver <david.maciver@gmail.com>
>> wrote:
>> > Depends what you consider "optimal" really. It's certainly a significant
>> > amount more than 2x vs. using primitives directly. Maybe Iulian's work
>> > on
>> > specialisation will help with that eventually though.
>>
>> Is there a pointer to his work on this? I'm very curious to see what's
>> in the works on this front.
>>
>> -- David
>>
>> >
>> > On Tue, Feb 10, 2009 at 8:14 AM, Jorge Ortiz <jorge.ortiz@gmail.com>
>> > wrote:
>> >>
>> >> Oy, brain fart. For some reason I thought it used views instead of of
>> >> type
>> >> classes.
>> >>
>> >> It has a moderate performance penalty, but no worse than 2x optimal in
>> >> my
>> >> tests.
>> >>
>> >> --j
>> >>
>> >> On Mon, Feb 9, 2009 at 11:01 PM, Ricky Clarkson
>> >> <ricky.clarkson@gmail.com>
>> >> wrote:
>> >>>
>> >>> Why does it incur significant runtime penalties?
>> >>>
>> >>> 2009/2/10 Jorge Ortiz <jorge.ortiz@gmail.com>
>> >>>>
>> >>>> The short answer is no.
>> >>>>
>> >>>> The long answer is that it looks like 2.8.0 might have it. (See, for
>> >>>> example,
>> >>>>
>> >>>> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scalax/Numeric.scala).
>> >>>> And I see no reason why you couldn't backport this into 2.7.x
>> >>>> yourself. I'll
>> >>>> warn you, however, that this approach comes with significant run time
>> >>>> performance penalties.
>> >>>>
>> >>>> --j
>> >>>>
>> >>>> On Mon, Feb 9, 2009 at 5:47 PM, Gabriel Claramunt
>> >>>> <gclaramunt@optonline.net> wrote:
>> >>>>>
>> >>>>> Does Scala have a "Number" class/interface akin to Haskell's Num
>> >>>>> typeclass? I'm re-inventing the 2D vector wheel and I want to be
>> >>>>> able to
>> >>>>> back it Float or Integers
>> >>>>>
>> >>>>> Thanks!
>> >>>>>
>> >>>>> --
>> >>>>> Gabriel Claramunt
>> >>>>> http://gabrielsw.blogspot.com
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>
>

--
Viktor Klang
Senior Systems Analyst

On Tue, Feb 10, 2009 at 9:32 PM, David MacIver wrote:
> Sorry Iulian, I didn't mean to put you on the spot like this. :-)
>
> As I understand it the basic idea is that there is / will be a @specialised
> annotation that, when applied to type parameters of classes or methods, will
> cause specialised versions to be generated for primitive classes, allowing
> one to avoid boxing.
>
> So suppose I have
>
> def foo[@specialized T](n : Int) = new Array[T](n);
>
> Currently what will happen when I do
>
> val x = foo[Int](3);
>
> is that a polymorphic boxed array will be generated and then converted to an
> Array[Int];
>
> With specialisation what will happen is that this will be translated to
>
> val x = foo$somemangling(3)
>
> where
>
> def foo$somemangling(n : Int) = new Array[Int](3);
>
> At least that's what I've gathered. I may have the wrong end of the stick.
>
No, that's pretty accurate.

Cheers

On Tue, Feb 10, 2009 at 2:32 PM, David MacIver <david.maciver@gmail.com> wrote:

As I understand it the basic idea is that there is / will be a @specialised annotation that, when applied to type parameters of classes or methods, will cause specialised versions to be generated for primitive classes, allowing one to avoid boxing.

Shouldn't this be default behavior without an annotation?

On Sun, Feb 15, 2009 at 10:47 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Tue, Feb 10, 2009 at 2:32 PM, David MacIver <david.maciver@gmail.com> wrote:

As I understand it the basic idea is that there is / will be a @specialised annotation that, when applied to type parameters of classes or methods, will cause specialised versions to be generated for primitive classes, allowing one to avoid boxing.

Shouldn't this be default behavior without an annotation?

I like defaults which don't cause Scala to generate 90 times as much bytecode for common usage patterns. :-)

On Sun, Feb 15, 2009 at 4:58 PM, David MacIver <david.maciver@gmail.com> wrote:

On Sun, Feb 15, 2009 at 10:47 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Tue, Feb 10, 2009 at 2:32 PM, David MacIver <david.maciver@gmail.com> wrote:

As I understand it the basic idea is that there is / will be a @specialised annotation that, when applied to type parameters of classes or methods, will cause specialised versions to be generated for primitive classes, allowing one to avoid boxing.

Shouldn't this be default behavior without an annotation?

I like defaults which don't cause Scala to generate 90 times as much bytecode for common usage patterns. :-)

Could you elaborate? Are you saying that using primitive arrays will generate more bytecode, or maybe I misunderstood how the @specialised annotation is supposed to work.

On Sun, Feb 15, 2009 at 5:35 PM, Nils Kilden-Pedersen wrote:
> On Sun, Feb 15, 2009 at 4:58 PM, David MacIver
> wrote:
>>
>> On Sun, Feb 15, 2009 at 10:47 PM, Nils Kilden-Pedersen
>> wrote:
>>>
>>> On Tue, Feb 10, 2009 at 2:32 PM, David MacIver
>>> wrote:
>>>>
>>>> As I understand it the basic idea is that there is / will be a
>>>> @specialised annotation that, when applied to type parameters of classes or
>>>> methods, will cause specialised versions to be generated for primitive
>>>> classes, allowing one to avoid boxing.
>>>
>>> Shouldn't this be default behavior without an annotation?
>>
>> I like defaults which don't cause Scala to generate 90 times as much
>> bytecode for common usage patterns. :-)
>
> Could you elaborate? Are you saying that using primitive arrays will
> generate more bytecode, or maybe I misunderstood how the @specialised
> annotation is supposed to work.
>

Think about C++ templates. Whenever you use vector with a new type,
you generate another new vector for that type. This can lead to a lot
of extra object code that results in huge binaries. In JVM, this
translates to either large class files, or a lot of extra class files.

The purpose of this optimization is (I hope!) to allow for
specialization for primitive types when you think you need it. You
might not want to @specialize 10 type parameters in a single
class/method, since that will generated (num primitives + 1)^10
different instantiations. Exponential blowup is bad news.

On Sun, Feb 15, 2009 at 10:25 PM, David Hall <david.lw.hall@gmail.com> wrote:

Think about C++ templates. Whenever you use vector with a new type,
you generate another new vector for that type. This can lead to a lot
of extra object code that results in huge binaries. In JVM, this
translates to either large class files, or a lot of extra class files.

The purpose of this optimization is (I hope!) to allow for
specialization for primitive types when you think you need it. You
might not want to @specialize 10 type parameters in a single
class/method, since that will generated (num primitives + 1)^10
different instantiations.  Exponential blowup is bad news.

I see. Thanks for explaining.