suggestion: let "Real" be alias for "Double"

On Sun, Mar 08, 2009 at 06:25:22PM -0700, Russ Paielli wrote:
> I tried "type Real = Double", but that does not work in general.

I believe you, but you might at least say what doesn't work.

scala> type Real = Double
defined type alias Real

scala> val x: Real = 5d
x: Real = 5.0

> I like Scala a lot, but I would like it a bit more if I could use
> "Real" in place of "Double". It's more meaningful, and it's shorter by
> two characters. I can't imagine it would be hard to implement.

You're wasting your time in a big way asking for something like this.
It'll never happen, not because it's hard to implement but because
gratuitously adding new ways to say the same thing is exactly the
opposite of good language design. It doesn't matter a bit at this point
whether it's a good choice of name - that's the name.

On Sunday March 8 2009, Russ Paielli wrote:
> Yes, this is a minor "cosmetic" issue, but I use "Double" a lot, and
> I think "Real" makes more sense as a type name. The "Double" type is
> the most widely used approximation of a real number, after all.

Emphasis on approximation.

> I tried "type Real = Double", but that does not work in general.
>
> If I am not mistaken, the "Double" type name is a leftover from C. It
> came from the term "double precision," of course, but what does
> "double" mean by itself? It makes me think of ice cream cones.

Offhand, it strikes me as carrying a lot more meaning than "Unit," and
there is also Float, which is half Double's size. At least Double is
not lie, which is what Real would be if used as a name for
fixed-precision floating-point numbers.

> I like Scala a lot, but I would like it a bit more if I could use
> "Real" in place of "Double". It's more meaningful, and it's shorter
> by two characters. I can't imagine it would be hard to implement.

That seems hard to justify, since Doubles are very far (infinitely far?)
from being real numbers. Real is not more meaningful than Double, it
just has a meaning that is not consistent with what a floating-point
number of any fixed precision represents.

And I wouldn't want to have a built-in floating-point type named Real
getting in my way if I wanted to construct a more realistic
representation of real numbers (e.g., an arbitrary precision math class
of some sort).

> Russ P.
>
> http://RussP.us

Randall Schulz

Double is double the precision of a Float. That name has a meaning, it's not just left over. Java has a Float type, and there are good reasons to use that (performance, space) in many applications. I do a lot of graphics programming, where floats are used a lot, and double are almost never needed.

Robert

On Sun, Mar 8, 2009 at 9:25 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Yes, this is a minor "cosmetic" issue, but I use "Double" a lot, and I think "Real" makes more sense as a type name. The "Double" type is the most widely used approximation of a real number, after all.

I tried "type Real = Double", but that does not work in general.

If I am not mistaken, the "Double" type name is a leftover from C. It came from the term "double precision," of course, but what does "double" mean by itself? It makes me think of ice cream cones.

I like Scala a lot, but I would like it a bit more if I could use "Real" in place of "Double". It's more meaningful, and it's shorter by two characters. I can't imagine it would be hard to implement.

Russ P.

http://RussP.us

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Offhand, it strikes me as carrying a lot more meaning than "Unit,"
>
Sorry for the divergence.

One very intuitive reason for the name "Unit" is because it is a (the)
type that is inhabited once. It has only one value (modulo bottoms).
What could be more appropriate name for such a type than Unit?

- --
Tony Morris
http://tmorris.net/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJtHXrmnpgrYe6r60RApY7AKCr7k0ztgXvtlqPMnunyUD15/lI4ACgkE6L
6bbzoiUaKfBiZlo4Hi+UNuY=
=uAq5
-----END PGP SIGNATURE-----

On Sun, Mar 8, 2009 at 6:43 PM, Randall R Schulz <rschulz@sonic.net> wrote:

Offhand, it strikes me as carrying a lot more meaning than "Unit," and
there is also Float, which is half Double's size. At least Double is
not lie, which is what Real would be if used as a name for
fixed-precision floating-point numbers.

A "Double" is intended to represent a real number. When someone uses a "Double" (or a "Float" for that matter), they really want a real number, but they are willing to settle for an approximation because the set of real numbers cannot be represented exactly in a computer.

If the name "Real" is a "lie," then so is almost every other name used in computer programming. How about "Complex," for example? Can complex numbers be represented exactly in a computer? No, they can't. Do people balk at the name "Complex" and call it a lie? Of course not. Let's not be silly.

> I like Scala a lot, but I would like it a bit more if I could use
> "Real" in place of "Double". It's more meaningful, and it's shorter
> by two characters. I can't imagine it would be hard to implement.

That seems hard to justify, since Doubles are very far (infinitely far?)
from being real numbers. Real is not more meaningful than Double, it
just has a meaning that is not consistent with what a floating-point
number of any fixed precision represents.

And I wouldn't want to have a built-in floating-point type named Real
getting in my way if I wanted to construct a more realistic
representation of real numbers (e.g., an arbitrary precision math class
of some sort).

So the name "Real" should be reserved for some obscure class that does not even exist yet and would be rarely used if it did exist? With all due respect, that seems silly to me.

--Russ

On Sun, Mar 8, 2009 at 6:39 PM, Robert Kosara <rkosara@gmail.com> wrote:

Double is double the precision of a Float. That name has a meaning, it's not just left over. Java has a Float type, and there are good reasons to use that (performance, space) in many applications. I do a lot of graphics programming, where floats are used a lot, and double are almost never needed.

Fine, but what does that have to do with my suggestion? I'll venture to say that, in most numerical programming other than graphics, Doubles are now used far more than Floats. Float is now essentially a specialty type for extremely large arrays of (approximated) real numbers.

And yes, I realize that "Double" means double precision Float. But it could also mean a double long integer, a double character, double foo, double bar, or double anything. It's just not a very good name for one of the two or three most important types used in modern computer programming.

--Russ

On Sunday March 8 2009, Russ Paielli wrote:
> On Sun, Mar 8, 2009 at 6:43 PM, Randall R Schulz wrote:
> > ...
>
> A "Double" is intended to represent a real number. When someone uses
> a "Double" (or a "Float" for that matter), they really want a real
> number, but they are willing to settle for an approximation because
> the set of real numbers cannot be represented exactly in a computer.

If they _need_ a real number, neither Float / float nor Double / double
will suffice. Calling a 64-bit floating-point number "real" _is_ a lie.

> If the name "Real" is a "lie," then so is almost every other name
> used in computer programming.

Real numbers have precise meanings in mathematics. Calling a crude
approximation a real is a bad idea. Computer science does this sort of
thing too much. Taking well defined, well established concepts from
other fields and butchering them is not a good idea.

> How about "Complex," for example? Can complex numbers be represented
> exactly in a computer? Do people balk at the name "Complex" and call
> it a lie? Of course not. Let's not be silly.

If real numbers can be manipulated with arbitrary precision in a
computer (and they can, subject to limits on the amount of precision
required to represent them), then so can complex numbers.

> > ...
> >
> > And I wouldn't want to have a built-in floating-point type named
> > Real getting in my way if I wanted to construct a more realistic
> > representation of real numbers (e.g., an arbitrary precision math
> > class of some sort).
> >
> > So the name "Real" should be reserved for some obscure class that
> > does not even exist yet and would be rarely used if it did exist?
> > With all due respect, that seems silly to me.

Yes, it should be reserved for someone who's going to create an
arbitrary-precision number system that makes a legitimate claim to
representing real numbers. Floating-point numbers just discard
precision when they run out of room for it, and it's possible to do
much better.

Basically, I disagree with how you characterize things as "silly."

> --Russ

Randall Schulz

Quoting Russ Paielli :

> Yes, this is a minor "cosmetic" issue, but I use "Double" a lot, and I think
> "Real" makes more sense as a type name. The "Double" type is the most widely
> used approximation of a real number, after all.

I say we take a page from Fortress's book and use ℝ64. :)

-0xe1a

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

This is off topic. Another thing that I don't like in computer science
is "Closure". Can anyone tell me the relationship between
http://en.wikipedia.org/wiki/Closure_(mathematics) and closure as
code blocks ?

Pi Song

On Mon, Mar 9, 2009 at 2:24 PM, Alex Cruise wrote:
> Quoting Russ Paielli :
>
>> Yes, this is a minor "cosmetic" issue, but I use "Double" a lot, and I
>> think
>> "Real" makes more sense as a type name. The "Double" type is the most
>> widely
>> used approximation of a real number, after all.
>
> I say we take a page from Fortress's book and use ℝ64. :)
>
> -0xe1a
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>

On Sun, Mar 8, 2009 at 8:11 PM, Randall R Schulz <rschulz@sonic.net> wrote:

If they _need_ a real number, neither Float / float nor Double / double
will suffice. Calling a 64-bit floating-point number "real" _is_ a lie.


> If the name "Real" is a "lie," then so is almost every other name
> used in computer programming.

Real numbers have precise meanings in mathematics. Calling a crude
approximation a real is a bad idea. Computer science does this sort of
thing too much. Taking well defined, well established concepts from
other fields and butchering them is not a good idea.

I'm sorry, but that's just nonsense. First of all, a 64 bit Double is not a "crude approximation" of a real. It is actually a very good approximation for virtually all practical purposes. And nobody is going to get confused between an actual real number is the strict mathematical sense and a computer approximation of a real number. Fortran has had a "real" type for a long time, and it has worked out very well.

Suppose I had a class that I called "airplane." Would you call the name a "lie" if it doesn't represent an actual airplane in every detail, right down to the last rivet? I hope not. Sorry, but your use of the word "lie" is just plain silly.

> How about "Complex," for example? Can complex numbers be represented
> exactly in a computer? Do people balk at the name "Complex" and call
> it a lie? Of course not. Let's not be silly.

If real numbers can be manipulated with arbitrary precision in a
computer (and they can, subject to limits on the amount of precision
required to represent them), then so can complex numbers.

Many widely used programming languages have a type called "complex"  (or "Complex"). According to your definition, that is a "lie" -- but I have yet to hear anyone other than you make such a claim.

> > ...
> >
> > And I wouldn't want to have a built-in floating-point type named
> > Real getting in my way if I wanted to construct a more realistic
> > representation of real numbers (e.g., an arbitrary precision math
> > class of some sort).
> >
> > So the name "Real" should be reserved for some obscure class that
> > does not even exist yet and would be rarely used if it did exist?
> > With all due respect, that seems silly to me.

Yes, it should be reserved for someone who's going to create an
arbitrary-precision number system that makes a legitimate claim to
representing real numbers. Floating-point numbers just discard
precision when they run out of room for it, and it's possible to do
much better.

An arbitrary-precision real might be useful for a few applications in pure mathematics, but it would be too inefficient for most uses of the current "Double" type. Competent numerical programmers are usually very satisfied with 64 bits. In the old days, they managed with only 32, 16, or even 8 bits. I once developed an integrated GPS/INS navigation system for research in precision landing of aircraft, and 64 bits was plenty.

--Russ

--
http://RussP.us

On Sunday March 8 2009, Russ Paielli wrote:
> On Sun, Mar 8, 2009 at 8:11 PM, Randall R Schulz wrote:
> > If they _need_ a real number, neither Float / float nor Double /
> > double will suffice. Calling a 64-bit floating-point number "real"
> > _is_ a lie.
> >
> > > If the name "Real" is a "lie," then so is almost every other name
> > > used in computer programming.
> >
> > Real numbers have precise meanings in mathematics. Calling a crude
> > approximation a real is a bad idea. Computer science does this sort
> > of thing too much. Taking well defined, well established concepts
> > from other fields and butchering them is not a good idea.
>
> I'm sorry, but that's just nonsense. ...

Well, I'm not sorry. Calling a thing something it is not _is_ nonsense.

> --Russ

Randall Schulz

On Mon, Mar 9, 2009 at 3:44 AM, pi song wrote:
> This is off topic. Another thing that I don't like in computer science
> is "Closure". Can anyone tell me the relationship between
> http://en.wikipedia.org/wiki/Closure_(mathematics)  and closure as
> code blocks ?

The name has a different etymology. A closure in programming languages
closes over its environment -- hence the name. It is a relic of the
development from dynamic -> lexical scoping.

[Regarding real vs double, I'd stick with double. The name is widely
known and there are people who care about the difference and implement
things much closer to real numbers on computers.]

N.

Sorry, but I'm going to post one more reply on this.

First, let me point that the "Int" type does not really represent the integers. The set of integers is infinite, of course, and no finite computer could possibly represent the complete set. So, for those who object to "Real" as an alias for "Double" because they do not represent the complete set of real numbers, why don't you be consistent and insist that the name "Int" be changed to something else?

Second, no finite computer could possibly implement a full implementation of real numbers either. So the idea of reserving the name "Real" for some arcane, super-precise implementation of a float is a "lie" too.

Look, if you want to stick with the status quo, just say so, but please don't try to justify it with bogus arguments.

--Russ

On Mon, Mar 9, 2009 at 12:06 AM, Noel Welsh <noelwelsh@gmail.com> wrote:

On Mon, Mar 9, 2009 at 3:44 AM, pi song <pi.songs@gmail.com> wrote:
> This is off topic. Another thing that I don't like in computer science
> is "Closure". Can anyone tell me the relationship between
> http://en.wikipedia.org/wiki/Closure_(mathematics)  and closure as
> code blocks ?

The name has a different etymology. A closure in programming languages
closes over its environment -- hence the name. It is a relic of the
development from dynamic -> lexical scoping.

[Regarding real vs double, I'd stick with double. The name is widely
known and there are people who care about the difference and implement
things much closer to real numbers on computers.]

N.

--
http://RussP.us

t's the least fruitful discussion I've ever read on this list.

Still, there are some points I would like to clarify:

1) If a data structure is open-ended in a way that it is only limited by resources (like memory) not by representation, then we can call it a true representation (of a potentially infinite set) for any practical and theoretical purposes.

2) Consequently, (big-)integers are fairly true representations of the set of integers as the only limit is the memory. Consequently, rational numbers can described as pairs of (big-).integers, still truly. Likewise, strings, binary-trees, boolean functions, etc, etc... all can all be represented truly.

3) Binary floating point numbers (even arbitrary-precision ones!) are not true representations even of the rational numbers, let alone reals: there is no way to represent simple numbers like 1/3, however big is your memory.

On Mon, Mar 9, 2009 at 12:55 AM, Russ Paielli <russ.paielli@gmail.com> wrote:

Sorry, but I'm going to post one more reply on this.

First, let me point that the "Int" type does not really represent the integers. The set of integers is infinite, of course, and no finite computer could possibly represent the complete set. So, for those who object to "Real" as an alias for "Double" because they do not represent the complete set of real numbers, why don't you be consistent and insist that the name "Int" be changed to something else?

Second, no finite computer could possibly implement a full implementation of real numbers either. So the idea of reserving the name "Real" for some arcane, super-precise implementation of a float is a "lie" too.

Look, if you want to stick with the status quo, just say so, but please don't try to justify it with bogus arguments.

--Russ

On Mon, Mar 9, 2009 at 12:06 AM, Noel Welsh <noelwelsh@gmail.com> wrote:

On Mon, Mar 9, 2009 at 3:44 AM, pi song <pi.songs@gmail.com> wrote:
> This is off topic. Another thing that I don't like in computer science
> is "Closure". Can anyone tell me the relationship between
> http://en.wikipedia.org/wiki/Closure_(mathematics)  and closure as
> code blocks ?

The name has a different etymology. A closure in programming languages
closes over its environment -- hence the name. It is a relic of the
development from dynamic -> lexical scoping.

[Regarding real vs double, I'd stick with double. The name is widely
known and there are people who care about the difference and implement
things much closer to real numbers on computers.]

N.

--
http://RussP.us

Christian Szegedy wrote:
> t's the least fruitful discussion I've ever read on this list.
>
> Still, there are some points I would like to clarify:
>
> 1) If a data structure is open-ended in a way that it is only limited by
> resources (like memory) not by representation, then we can call it a
> true representation (of a potentially infinite set) for any practical
> and theoretical purposes.
>
> 2) Consequently, (big-)integers are fairly true representations of the
> set of integers as the only limit is the memory. Consequently, rational
> numbers can described as pairs of (big-).integers, still truly.
> Likewise, strings, binary-trees, boolean functions, etc, etc... all can
> all be represented truly.
>
> 3) Binary floating point numbers (even arbitrary-precision ones!) are
> not true representations even of the rational numbers, let alone reals:
> there is no way to represent simple numbers like 1/3, however big is
> your memory.

This is not true it you talk about the Java implementations. String,
BigInteger etc. are not "true" representations of their theoretical
counterparts, they have size limitations (for example the length of a
string is limited to 2^31 - 1). String and a double are both
approximations, the only difference is which values you can represent.

A "true" representation of integers would use VLQ or similar.

/Jesper Nordenberg

Calling Double Real would be a wasted opportunity to create a
typeclass called Real of which each non-integer numeric type provided
by Scala or a user would be an instance of.

object RussP { type Real = Double }
import RussP._

should work for what RussP wants, without affecting the rest of us.

2009/3/9 Jesper Nordenberg :
> Christian Szegedy wrote:
>>
>> t's the least fruitful discussion I've ever read on this list.
>>
>> Still, there are some points I would like to clarify:
>>
>> 1) If a data structure is open-ended in a way that it is only limited by
>> resources (like memory) not by representation, then we can call it a true
>> representation (of a potentially infinite set) for any practical and
>> theoretical purposes.
>>
>> 2) Consequently, (big-)integers are fairly true representations of the set
>> of integers as the only limit is the memory. Consequently, rational numbers
>> can described as pairs of (big-).integers, still truly. Likewise, strings,
>> binary-trees, boolean functions, etc, etc... all can all be represented
>> truly.
>>
>> 3) Binary floating point numbers (even arbitrary-precision ones!) are not
>> true representations even of the rational numbers, let alone reals: there is
>> no way to represent simple numbers like 1/3, however big is your memory.
>
> This is not true it you talk about the Java implementations. String,
> BigInteger etc. are not "true" representations of their theoretical
> counterparts, they have size limitations (for example the length of a string
> is limited to 2^31 - 1). String and a double are both approximations, the
> only difference is which values you can represent.
>
> A "true" representation of integers would use VLQ or similar.
>
> /Jesper Nordenberg
>
>

First, let me point that the "Int" type does not really represent the integers. The set of integers is infinite, of course, and no finite computer could possibly represent the complete set. So, for those who object to "Real" as an alias for "Double" because they do not represent the complete set of real numbers, why don't you be consistent and insist that the name "Int" be changed to something else?

  Agreed.  It's always bothered me that we have Int and Long instead of Int32 and Int64.

On Mon, Mar 9, 2009 at 3:55 AM, Russ Paielli <russ.paielli@gmail.com> wrote:

Sorry, but I'm going to post one more reply on this.

First, let me point that the "Int" type does not really represent the integers. The set of integers is infinite, of course, and no finite computer could possibly represent the complete set. So, for those who object to "Real" as an alias for "Double" because they do not represent the complete set of real numbers, why don't you be consistent and insist that the name "Int" be changed to something else?

Second, no finite computer could possibly implement a full implementation of real numbers either. So the idea of reserving the name "Real" for some arcane, super-precise implementation of a float is a "lie" too.

Look, if you want to stick with the status quo, just say so, but please don't try to justify it with bogus arguments.

--Russ

On Mon, Mar 9, 2009 at 12:06 AM, Noel Welsh <noelwelsh@gmail.com> wrote:

On Mon, Mar 9, 2009 at 3:44 AM, pi song <pi.songs@gmail.com> wrote:
> This is off topic. Another thing that I don't like in computer science
> is "Closure". Can anyone tell me the relationship between
> http://en.wikipedia.org/wiki/Closure_(mathematics)  and closure as
> code blocks ?

The name has a different etymology. A closure in programming languages
closes over its environment -- hence the name. It is a relic of the
development from dynamic -> lexical scoping.

[Regarding real vs double, I'd stick with double. The name is widely
known and there are people who care about the difference and implement
things much closer to real numbers on computers.]

N.

--
http://RussP.us

--
http://erikengbrecht.blogspot.com/

On Mon, Mar 9, 2009 at 3:02 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Calling Double Real would be a wasted opportunity to create a
typeclass called Real of which each non-integer numeric type provided
by Scala or a user would be an instance of.

object RussP { type Real = Double }
import RussP._

should work for what RussP wants, without affecting the rest of us.

That would be a nice solution, but it does not seem to work. I hope I'm not doing something dumb. I've tried it both in a file and in the interpreter (2.7.3.final on Red Hat 5 on a Sun Ultra 24). In the interpreter, I've tried it as both

type Real = Double

and

object RussP { type Real = Double }

Either way, it gives the following message and crashes the interpreter.

Welcome to Scala version 2.7.3.final (GNU libgcj, Java 1.4.2).
Type in expressions to have them evaluated.
Type :help for more information.

scala> type Real = Double
Exception in thread "main" scala.MatchError: type Real = Double
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:62)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at scala.List.foreach(List.scala:834)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at scala.List.foreach(List.scala:834)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at scala.List.foreach(List.scala:834)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
   at scala.List.foreach(List.scala:834)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:65)
   at units.check.UnitsCheckerComponent$$anon$1.checkUnit(UnitsCheckerComponent.scala:180)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
   at scala.Iterator$class.foreach(Iterator.scala:414)
   at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:266)
   at units.check.UnitsCheckerComponent$$anon$1.run(UnitsCheckerComponent.scala:184)
   at scala.tools.nsc.Global$Run.compileSources(Global.scala:574)
   at scala.tools.nsc.Interpreter$Request.compile(Interpreter.scala:820)
   at scala.tools.nsc.Interpreter.interpret(Interpreter.scala:505)
   at scala.tools.nsc.InterpreterLoop.interpretStartingWith(InterpreterLoop.scala:242)
   at scala.tools.nsc.InterpreterLoop.command(InterpreterLoop.scala:230)
   at scala.tools.nsc.InterpreterLoop.repl(InterpreterLoop.scala:142)
   at scala.tools.nsc.InterpreterLoop.main(InterpreterLoop.scala:298)
   at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:141)
   at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

It works for me using Sun's Java 1.6.  I noticed you are using GCJ and your Java version is 1.4.2.  I don't have access to anything with 1.4 installed so I can't tell if it is a bug caused by the old Java rev or by GCJ.

On Mon, Mar 9, 2009 at 5:04 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Mon, Mar 9, 2009 at 3:02 AM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Calling Double Real would be a wasted opportunity to create a
typeclass called Real of which each non-integer numeric type provided
by Scala or a user would be an instance of.

object RussP { type Real = Double }
import RussP._

should work for what RussP wants, without affecting the rest of us.

That would be a nice solution, but it does not seem to work. I hope I'm not doing something dumb. I've tried it both in a file and in the interpreter (2.7.3.final on Red Hat 5 on a Sun Ultra 24). In the interpreter, I've tried it as both

type Real = Double

and

object RussP { type Real = Double }

Either way, it gives the following message and crashes the interpreter.

Welcome to Scala version 2.7.3.final (GNU libgcj, Java 1.4.2).
Type in expressions to have them evaluated.
Type :help for more information.

scala> type Real = Double
Exception in thread "main" scala.MatchError: type Real = Double
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:62)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at scala.List.foreach(List.scala:834)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at scala.List.foreach(List.scala:834)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
   at scala.List.foreach(List.scala:834)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
   at scala.List.foreach(List.scala:834)
   at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:65)
   at units.check.UnitsCheckerComponent$$anon$1.checkUnit(UnitsCheckerComponent.scala:180)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
   at units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
   at scala.Iterator$class.foreach(Iterator.scala:414)
   at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:266)
   at units.check.UnitsCheckerComponent$$anon$1.run(UnitsCheckerComponent.scala:184)
   at scala.tools.nsc.Global$Run.compileSources(Global.scala:574)
   at scala.tools.nsc.Interpreter$Request.compile(Interpreter.scala:820)
   at scala.tools.nsc.Interpreter.interpret(Interpreter.scala:505)
   at scala.tools.nsc.InterpreterLoop.interpretStartingWith(InterpreterLoop.scala:242)
   at scala.tools.nsc.InterpreterLoop.command(InterpreterLoop.scala:230)
   at scala.tools.nsc.InterpreterLoop.repl(InterpreterLoop.scala:142)
   at scala.tools.nsc.InterpreterLoop.main(InterpreterLoop.scala:298)
   at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:141)
   at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

--
http://erikengbrecht.blogspot.com/

You are aware that you are using the pretty much abandoned units
compiler plugin? It's that plugin that chokes on your type alias as you
can tell from the stack trace.

Ingo

Russ Paielli wrote:
> On Mon, Mar 9, 2009 at 3:02 AM, Ricky Clarkson > wrote:
>
> Calling Double Real would be a wasted opportunity to create a
> typeclass called Real of which each non-integer numeric type provided
> by Scala or a user would be an instance of.
>
> object RussP { type Real = Double }
> import RussP._
>
> should work for what RussP wants, without affecting the rest of us.
>
>
> That would be a nice solution, but it does not seem to work. I hope I'm
> not doing something dumb. I've tried it both in a file and in the
> interpreter (2.7.3.final on Red Hat 5 on a Sun Ultra 24). In the
> interpreter, I've tried it as both
>
> type Real = Double
>
> and
>
> object RussP { type Real = Double }
>
> Either way, it gives the following message and crashes the interpreter.
>
> Welcome to Scala version 2.7.3.final (GNU libgcj, Java 1.4.2).
> Type in expressions to have them evaluated.
> Type :help for more information.
>
> scala> type Real = Double
> Exception in thread "main" scala.MatchError: type Real = Double
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:62)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at scala.List.foreach(List.scala:834)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at scala.List.foreach(List.scala:834)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at scala.List.foreach(List.scala:834)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
> at scala.List.foreach(List.scala:834)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:65)
> at
> units.check.UnitsCheckerComponent$$anon$1.checkUnit(UnitsCheckerComponent.scala:180)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
> at scala.Iterator$class.foreach(Iterator.scala:414)
> at
> scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:266)
> at
> units.check.UnitsCheckerComponent$$anon$1.run(UnitsCheckerComponent.scala:184)
> at scala.tools.nsc.Global$Run.compileSources(Global.scala:574)
> at scala.tools.nsc.Interpreter$Request.compile(Interpreter.scala:820)
> at scala.tools.nsc.Interpreter.interpret(Interpreter.scala:505)
> at
> scala.tools.nsc.InterpreterLoop.interpretStartingWith(InterpreterLoop.scala:242)
> at scala.tools.nsc.InterpreterLoop.command(InterpreterLoop.scala:230)
> at scala.tools.nsc.InterpreterLoop.repl(InterpreterLoop.scala:142)
> at scala.tools.nsc.InterpreterLoop.main(InterpreterLoop.scala:298)
> at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:141)
> at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
>

On Mon, Mar 9, 2009 at 2:47 PM, Ingo Maier <ingo.maier@epfl.ch> wrote:

You are aware that you are using the pretty much abandoned units compiler plugin? It's that plugin that chokes on your type alias as you can tell from the stack trace.

I upgraded to Java 1.6, but Scala is still choking on my type alias. What is this units plugin all about, and what do I need to do to replace it? (I have no experience with Java). Here is what I am getting now (Red Hat 5 on a Sun Ultra 24):

Welcome to Scala version 2.7.3.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_11).
Type in expressions to have them evaluated.
Type :help for more information.

scala> type Real = Double
Exception in thread "main" scala.MatchError: type Real = Double
    at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:62)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
    at scala.List.foreach(List.scala:834)
    at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
    at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
    at scala.List.foreach(List.scala:834)
    at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
    at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
    at scala.List.foreach(List.scala:834)
    at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
    at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
    at scala.List.foreach(List.scala:834)
    at units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:65)
    at units.check.UnitsCheckerComponent$$anon$1.checkUnit(UnitsCheckerComponent.scala:180)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
    at units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
    at scala.Iterator$class.foreach(Iterator.scala:414)
    at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:266)
    at units.check.UnitsCheckerComponent$$anon$1.run(UnitsCheckerComponent.scala:184)
    at scala.tools.nsc.Global$Run.compileSources(Global.scala:574)
    at scala.tools.nsc.Interpreter$Request.compile(Interpreter.scala:820)
    at scala.tools.nsc.Interpreter.interpret(Interpreter.scala:505)
    at scala.tools.nsc.InterpreterLoop.interpretStartingWith(InterpreterLoop.scala:242)
    at scala.tools.nsc.InterpreterLoop.command(InterpreterLoop.scala:230)
    at scala.tools.nsc.InterpreterLoop.repl(InterpreterLoop.scala:142)
    at scala.tools.nsc.InterpreterLoop.main(InterpreterLoop.scala:298)
    at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:141)
    at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

You probably just want to remove the plugin. I guess you are not
specifiying it as a command line option, otherwise you would have known
about it. It's probably in $SCALA_HOME/misc/scala-devel/plugins then,
called units.jar or so. To make sure you are plugin-free, just remove
all jars from this folder. I don't know why it's there, it definitely
should not be per default, since it's currently unmaintained. Are you
using some distribution specific package (rpm, deb)?

Hope this helps,
Ingo

Russ Paielli wrote:
> On Mon, Mar 9, 2009 at 2:47 PM, Ingo Maier wrote:
>
> You are aware that you are using the pretty much abandoned units
> compiler plugin? It's that plugin that chokes on your type alias as
> you can tell from the stack trace.
>
>
> I upgraded to Java 1.6, but Scala is still choking on my type alias.
> What is this units plugin all about, and what do I need to do to replace
> it? (I have no experience with Java). Here is what I am getting now (Red
> Hat 5 on a Sun Ultra 24):
>
> Welcome to Scala version 2.7.3.final (Java HotSpot(TM) 64-Bit Server VM,
> Java 1.6.0_11).
> Type in expressions to have them evaluated.
> Type :help for more information.
>
> scala> type Real = Double
> Exception in thread "main" scala.MatchError: type Real = Double
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:62)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at scala.List.foreach(List.scala:834)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at scala.List.foreach(List.scala:834)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$2.apply(UnitsCheckerComponent.scala:96)
> at scala.List.foreach(List.scala:834)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:96)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:68)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$check$1$1.apply(UnitsCheckerComponent.scala:65)
> at scala.List.foreach(List.scala:834)
> at
> units.check.UnitsCheckerComponent$$anon$1.check$1(UnitsCheckerComponent.scala:65)
> at
> units.check.UnitsCheckerComponent$$anon$1.checkUnit(UnitsCheckerComponent.scala:180)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
> at
> units.check.UnitsCheckerComponent$$anon$1$$anonfun$run$1.apply(UnitsCheckerComponent.scala:184)
> at scala.Iterator$class.foreach(Iterator.scala:414)
> at
> scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:266)
> at
> units.check.UnitsCheckerComponent$$anon$1.run(UnitsCheckerComponent.scala:184)
> at scala.tools.nsc.Global$Run.compileSources(Global.scala:574)
> at scala.tools.nsc.Interpreter$Request.compile(Interpreter.scala:820)
> at scala.tools.nsc.Interpreter.interpret(Interpreter.scala:505)
> at
> scala.tools.nsc.InterpreterLoop.interpretStartingWith(InterpreterLoop.scala:242)
> at scala.tools.nsc.InterpreterLoop.command(InterpreterLoop.scala:230)
> at scala.tools.nsc.InterpreterLoop.repl(InterpreterLoop.scala:142)
> at scala.tools.nsc.InterpreterLoop.main(InterpreterLoop.scala:298)
> at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:141)
> at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
>

On Tue, Mar 10, 2009 at 1:00 AM, Ingo Maier <ingo.maier@epfl.ch> wrote:

You probably just want to remove the plugin. I guess you are not specifiying it as a command line option, otherwise you would have known about it. It's probably in $SCALA_HOME/misc/scala-devel/plugins then, called units.jar or so. To make sure you are plugin-free, just remove all jars from this folder. I don't know why it's there, it definitely should not be per default, since it's currently unmaintained. Are you using some distribution specific package (rpm, deb)?

Hope this helps,

Yes, that solves the problem. Thanks.

I had installed the "units" package using sbaz a couple of months ago because I wanted to see how it compared to my "Scalar" package. I had no idea that it added a plugin to my Scala installation (I didn't even know Scala had plugins or what that even means in Scala).

By the way, my Scalar package has a complete user guide and can be found at

http://RussP.us/scalar-scala.htm

Here is a summary:

An Efficient Scalar Package in Scala

Summary-- A Scala class was designed to represent physical scalars and to eliminate errors involving implicit physical units (e.g., confusing radians and degrees). The standard arithmetic operators are overloaded to provide syntax identical to that for basic numeric types. The Scalar class itself does not define any units but is part of a package that includes a complete implementation of the standard metric system of units and many common non-metric units. The scalar package also allows the user to define a specialized or reduced set of physical units for any particular application or domain. Once an application has been developed and tested, the Scalar class can be switched off at compile time to achieve the execution efficiency of operations on basic numeric types, which are an order of magnitude faster. The scalar class can also be used for discrete units to enforce type checking of integer counts, thereby enhancing the static type checking of Scala with additional dynamic type checking.