Double.isNaN missing in 2.8

Hi,

i have switched to Scala for my "Intro Computing" class at the
Univ. of Marburg. I have 220 students and many of those who
are running Windows 7 on a 64 bit machine report problems
with installing Scala.

Here are some remedies, I suggested to them
- quoting paths in scala.bat
- installing Scala in a path not containing spaces
- not using the jar-installer, but the zip folder
- running Scala from an USB stick.

All these remedies work for some, not for all. There are even
some with that same platform for whom the installation works
out of the box. In balance, though, I would say, there seems
to be serious problems with installing Scala on 64 Bit
Windows 7 systems, which I suspect will also bother other
prospective Scala users.

I would suggest that this problem should be addressed with
some priority, since the majority of users will sooner or
later work on this platform.

Until the problem is diagnosed and fixed, which I think is
probably not so easy, because the problems differ from system
to system, I would suggest to start a wiki where users can
report how they fixed the problem.

Greetings,
H.Peter Gumm

+---------------------------------------+
| Prof. Dr. H. Peter Gumm |
| FB Mathematik und Informatik |
| Philipps-Universit�t Marburg |
| Tel: (+49)-(0)6421-2821516 (office) |
| (+49)-(0)6425-6334 (home) |
+---------------------------------------+

I've just tried it, it seems to be there, whereever it may be defined:

Welcome to Scala version 2.8.0.final (Java HotSpot(TM) Client VM, Java
1.6.0_22).
Type in expressions to have them evaluated.
Type :help for more information.

scala> 3d.isNaN
res0: Boolean = false

scala> Double.NaN
res1: Double = NaN

scala> Double.NaN.isNaN
res2: Boolean = true

LML wrote:
> Hi,
>
> Scala 2.8.0 final is missing Java's Double.isNaN function,
> if this is still true for 2.8.1 it should be fixed,
> or am I missing something else?
>
> Thanks
> Lothar

> In-Reply-To: <4CCFE160.5000807@uni-bremen.de>

Unrelated to "Double.isNaN missing in 2.8" message...
Beware of replying to random messages instead of making a new message, your message can go
unnoticed by those reading mailing lists in threaded form, as they can mark a whole thread
as read when they are not interested in it (thus missing your message as it hides there).
Just FYI.

On 02/11/2010 11:09, gumm@Mathematik.Uni-Marburg.de wrote:
> i have switched to Scala for my "Intro Computing" class at the
> Univ. of Marburg. I have 220 students and many of those who
> are running Windows 7 on a 64 bit machine report problems
> with installing Scala.

> Here are some remedies, I suggested to them
> - quoting paths in scala.bat
> - installing Scala in a path not containing spaces
> - not using the jar-installer, but the zip folder
> - running Scala from an USB stick.
>
> All these remedies work for some, not for all. There are even
> some with that same platform for whom the installation works
> out of the box.

It was the case for me. I recently moved to a Win7 x64 box (HP computer) and got Scala
2.8.0.final working out of the box for me.
I always install Java applications in the path C:\Java\xxx, avoiding spaces in the path,
so no need for the first solution and the second is checked.
I avoid installers when I can, so I suppose I followed the third advice.

I will add:
- Add JAVA_HOME to the environment variables if it is not already there. I make it point
to a (32bit) JDK installation:

> set J
JAVA=C:\Java\jdk1.6.0_21\bin\java.exe
JAVA_HOME=C:\Java\jdk1.6.0_21
JRE_HOME=C:\Java\jdk1.6.0_21\jre

- Ensure everybody has the same JDK.
- Of course, also set SCALA_HOME:

> set s
SCALA_HOME=C:\Java\scala-2.8.0.final

That's some ideas I have now. Nothing new, but it completes the check list...

BTW, when you mention "many [...] report problems", what kind of problems are reported,
exactly?

Hi Phil,

thanks for the advice. On my system, setting SCALA_HOME has the adverse
effect,
that a shell window opens and closes immediately. This is what many of
my students
report, too.

I removed "SCALA_HOME" from the environment variables, so I can start
the scala
REPL by going to its bin-directory and double-clicking scala.bat.

I do have scala's bin-directory in my "Path" variable, but I cannot
start scala
from anywhere but from the directory in which it is located.

Ironically, in Windows 7 I should be able to start scala from the search
field of the
Windows Start Menu. But when I enter "scala" there, I get the API-docs,
file:///C:/Program%20Files%20%28x86%29/scala/doc/scala-devel-docs/api/in...

Entering "scala.bat" works.

Greetings,
H.Peter

Am 02.11.2010 11:22, schrieb Philippe Lhoste:
> On 02/11/2010 11:09, gumm@Mathematik.Uni-Marburg.de wrote:
>> i have switched to Scala for my "Intro Computing" class at the
>> Univ. of Marburg. I have 220 students and many of those who
>> are running Windows 7 on a 64 bit machine report problems
>> with installing Scala.
>
>> Here are some remedies, I suggested to them
>> - quoting paths in scala.bat
>> - installing Scala in a path not containing spaces
>> - not using the jar-installer, but the zip folder
>> - running Scala from an USB stick.
>>
>> All these remedies work for some, not for all. There are even
>> some with that same platform for whom the installation works
>> out of the box.
>
> It was the case for me. I recently moved to a Win7 x64 box (HP
> computer) and got Scala 2.8.0.final working out of the box for me.
> I always install Java applications in the path C:\Java\xxx, avoiding
> spaces in the path, so no need for the first solution and the second
> is checked.
> I avoid installers when I can, so I suppose I followed the third advice.
>
> I will add:
> - Add JAVA_HOME to the environment variables if it is not already
> there. I make it point to a (32bit) JDK installation:
>
> > set J
> JAVA=C:\Java\jdk1.6.0_21\bin\java.exe
> JAVA_HOME=C:\Java\jdk1.6.0_21
> JRE_HOME=C:\Java\jdk1.6.0_21\jre
>
> - Ensure everybody has the same JDK.
> - Of course, also set SCALA_HOME:
>
> > set s
> SCALA_HOME=C:\Java\scala-2.8.0.final
>
> That's some ideas I have now. Nothing new, but it completes the check
> list...
>
> BTW, when you mention "many [...] report problems", what kind of
> problems are reported, exactly?
>

On 2010-11-02 06:54, H. Peter Gumm wrote:

> thanks for the advice. On my system, setting SCALA_HOME has the adverse
> effect,
> that a shell window opens and closes immediately. This is what many of
> my students
> report, too.

For what it's worth I've installed Scala on about a half dozen Windows
7, 64 bit systems (there were all Dell systems) and it worked fine "out
of the box." I used the jar installer.

Perhaps there is some other software on your systems, and that the
students are using too, that is causing interference for some reason.

Peter

On 02/11/2010 11:54, H. Peter Gumm wrote:
> thanks for the advice. On my system, setting SCALA_HOME has the adverse
> effect,
> that a shell window opens and closes immediately. This is what many of
> my students
> report, too.
>
> I removed "SCALA_HOME" from the environment variables, so I can start
> the scala
> REPL by going to its bin-directory and double-clicking scala.bat.

Mmm, I never double-click the .bat file, I don't think it is designed for that.
I have a convenient shortcut allowing me to get a console window with a path set to the
folder I right-clicked on in Windows Explorer (search "Command Line Here", that's actually
a simple registry trick). And then I use commands like:

scalac -d bin foo.scala

to compile a file or just

scala

if I want the REPL.

And, yes, of course, I have put %SCALA_HOME%\bin in my path, too.

Each student has his individual machine, of course. I have no idea what
each of their configuration is. I already mentiond that on *some* 64-bit
machines the installation works fine, but these are not my concern. On
*all* machines "normal" software should install out of the box, whether
64 or 32 bit. This is apparently not the case with the current Scala
distribution.

What I am saying is that something "not normal" is going on with the
Scala installation, and this ought to be fixed.

Greetings,
H.Peter

Am 02.11.2010 12:58, schrieb Peter C. Chapin:
> On 2010-11-02 06:54, H. Peter Gumm wrote:
>
>> thanks for the advice. On my system, setting SCALA_HOME has the adverse
>> effect,
>> that a shell window opens and closes immediately. This is what many of
>> my students
>> report, too.
> For what it's worth I've installed Scala on about a half dozen Windows
> 7, 64 bit systems (there were all Dell systems) and it worked fine "out
> of the box." I used the jar installer.
>
> Perhaps there is some other software on your systems, and that the
> students are using too, that is causing interference for some reason.
>
> Peter

So, let me try to sum up the symptoms so that we can agree on the facts:
* Everyone of your students has `/bin` folder added
to his path environment variable (system or user wide?) with an
absolute path
* When SCALA_HOME is set as an environment variable (system or user
wide or in a command prompt?), clicking on scala.bat opens a a shell
window which closes directly afterwards instead of showing the Scala
console interpreter. When SCALA_HOME isn't set, clicking on scala.bat
opens a shell window with the Scala console.
* In the shell, running `scala` from any directory does not work in
general, even if the PATH variable is set correctly. Only running
directly from the bin directory works.
* Starting the Scala console from the search bar inside of the start
menu works only by typing in scala.bat and not by typing scala.
* Students experience these problems *only* on Windows 7 with the 64bit version

If I understand you correctly, not all of those students with Windows
7 64bit version are experiencing these problems, but some are. Are
there other problems? How was Scala installed by the students?

On Tue, Nov 2, 2010 at 2:39 PM, H. Peter Gumm
wrote:
> On *all* machines "normal" software should install out of the box, whether
> 64 or 32 bit.  This is apparently not the case with the current Scala
> distribution.

I think we all agree that Scala should work properly under normal
circumstances. Only recently a ticket was opened with a similar issue:
http://lampsvn.epfl.ch/trac/scala/ticket/3959

Thanks for bringing this up. Perhaps we can come up with a series of
steps for your students to execute and verify so we can isolate the
issue further.

I made some experiments with a Windows 7 virtual machine I had
somewhere lying around.

IMO the most probable explanation really is the problem with the
special chars in the directory name "Program Files (x86)". That's the
only probable explanation for the issue's provenance with 64bit
systems.
But as the non-deterministic appearance of the issue shows this may
not be the only problem. I see these as additional confusing issues:

* Changes to User environment variables are only taken into account
after a logout/login (!) (Windows distinguishes User and System
environment variables)
* Scala's lzpack installer changes User environment variables.
* Java binaries have to be on the path
* SCALA_HOME must not be on the path because of issue #3959 (or as
long as it's not fixed)

So, steps to make sure you've got a working installation would be:

1. Install Java and make sure Java is working on the command line
2. Install Scala from the lzpack distribution
3. Goto Control Panel/System/Advanced Settings (?)/Advanced
Tab/Environment Variables and delete the entry for SCALA_HOME
(As long as #3959 is not fixed). That's
Systemsteuerung/System/Erweiterte
Systemeinstellungen/Erweitert/Umgebungsvariablen in German.
4. Logout and login (!)

If it then still doesn't work, open a command prompt and type each of

set
java
scala

and post the output of these programs.

As for the problem with the start menu: The search bar in the start
menu does not work like the old "Run Command" box. It uses some type
of search engine to search through start menu entries and some files.
If you type `scala` into the box, it finds several entries containing
the word 'scala'. The first one coincidentally is "Scala API
Documentation". Another entry reads 'Scala Interpreter'. Use this one.
On the other hand, if you type in `scala.bat`, it finds the actual
file.

I hope this helps.

Johannes

On Tue, Nov 2, 2010 at 3:42 PM, Johannes Rudolph
wrote:
> So, let me try to sum up the symptoms so that we can agree on the facts:
>  * Everyone of your students has `/bin` folder added
> to his path environment variable (system or user wide?) with an
> absolute path
>  * When SCALA_HOME is set as an environment variable (system or user
> wide or in a command prompt?), clicking on scala.bat opens a a shell
> window which closes directly afterwards instead of showing the Scala
> console interpreter. When SCALA_HOME isn't set, clicking on scala.bat
> opens a shell window with the Scala console.
>  * In the shell, running `scala` from any directory does not work in
> general, even if the PATH variable is set correctly. Only running
> directly from the bin directory works.
>  * Starting the Scala console from the search bar inside of the start
> menu works only by typing in scala.bat and not by typing scala.
>  * Students experience these problems *only* on Windows 7 with the 64bit version
>
> If I understand you correctly, not all of those students with Windows
> 7 64bit version are experiencing these problems, but some are. Are
> there other problems? How was Scala installed by the students?
>
> On Tue, Nov 2, 2010 at 2:39 PM, H. Peter Gumm
> wrote:
>> On *all* machines "normal" software should install out of the box, whether
>> 64 or 32 bit.  This is apparently not the case with the current Scala
>> distribution.
>
> I think we all agree that Scala should work properly under normal
> circumstances. Only recently a ticket was opened with a similar issue:
> http://lampsvn.epfl.ch/trac/scala/ticket/3959
>
> Thanks for bringing this up. Perhaps we can come up with a series of
> steps for your students to execute and verify so we can isolate the
> issue further.
>
> --
> Johannes
>
> -----------------------------------------------
> Johannes Rudolph
> http://virtual-void.net
>

On 2 November 2010 15:29, Johannes Rudolph <johannes.rudolph@googlemail.com> wrote:

 * Changes to User environment variables are only taken into account
after a logout/login (!) (Windows distinguishes User and System
environment variables)

If you're testing this, it's usually enough to just open a fresh command window - should save you a bit of time! --
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Did you test this? I think that this isn't correct for user environment variables. To the contrary, I'm actually pretty sure this very fact is the source of most of this confusion.

Am 02.11.2010 16:39 schrieb "Kevin Wright" <kev.lee.wright@gmail.com>:
> On 2 November 2010 15:29, Johannes Rudolph
> <johannes.rudolph@googlemail.com>wrote:
>
>>
>> * Changes to User environment variables are only taken into account
>> after a logout/login (!) (Windows distinguishes User and System
>> environment variables)
>>
>
> If you're testing this, it's usually enough to just open a fresh command
> window - should save you a bit of time!
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wright@gmail.com
> pulse / skype: kev.lee.wright
> twitter: @thecoda

I've never found any need to restart a machine after making changes to the user PATH or JAVA_HOME variables.  On either WinXP 32-bit or Win7 64-bit
The only "odd" behaviour that I've been unfortunate enough to suffer from, is when PATH references %JAVA_HOME%/bin instead of the absolute location - so I don't try to do that any more :)


On 2 November 2010 15:46, Johannes Rudolph <johannes.rudolph@googlemail.com> wrote:

Did you test this? I think that this isn't correct for user environment variables. To the contrary, I'm actually pretty sure this very fact is the source of most of this confusion.

Am 02.11.2010 16:39 schrieb "Kevin Wright" <kev.lee.wright@gmail.com>:
> On 2 November 2010 15:29, Johannes Rudolph
> <johannes.rudolph@googlemail.com>wrote:
>
>>
>> * Changes to User environment variables are only taken into account
>> after a logout/login (!) (Windows distinguishes User and System
>> environment variables)
>>
>
> If you're testing this, it's usually enough to just open a fresh command
> window - should save you a bit of time!
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wright@gmail.com
> pulse / skype: kev.lee.wright
> twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On 02/11/2010 16:46, Johannes Rudolph wrote:
> Did you test this? I think that this isn't correct for user environment variables. To the
> contrary, I'm actually pretty sure this very fact is the source of most of this confusion.

Just tested it (on an XP machine, will try on a Win7 as well) and it works too.
Indeed, I recall the logout/login trick was necessary on old versions of Windows (perhaps
even in early XP systems) but it is no longer needed, fortunately.

BTW, I rarely (well, never) define user environment variables, particularly to define
paths of applications. Well, can be useful if you share your computer and want a different
version depending on login, but it is probably a rare scenario on a developer's machine.

Note: I don't put SCALA_HOME in the path, I put %SCALA_HOME%\bin. And well, as said, it
has no spaces in the path.
Note that you mention bug #3559 which points to
http://eliasbland.wordpress.com/2010/10/13/how-to-fix-the-scala-interpre...
page which describes the problem the OP has (flashing interpreter box).

On Tue, Nov 2, 2010 at 6:57 PM, Philippe Lhoste wrote:
> On 02/11/2010 16:46, Johannes Rudolph wrote:
>>
>> Did you test this? I think that this isn't correct for user environment
>> variables. To the
>> contrary, I'm actually pretty sure this very fact is the source of most of
>> this confusion.
>
> Just tested it (on an XP machine, will try on a Win7 as well) and it works
> too.

Ok, you are both right. Don't know what I've did before and how I came
to that conclusion... Perhaps I should leave Windows alone like I did
the last years...

Why the students are using Windows is a very good question too.

On Wed, Nov 3, 2010 at 8:32 AM, Johannes Rudolph <johannes.rudolph@googlemail.com> wrote:

On Tue, Nov 2, 2010 at 6:57 PM, Philippe Lhoste <PhiLho@gmx.net> wrote:
> On 02/11/2010 16:46, Johannes Rudolph wrote:
>>
>> Did you test this? I think that this isn't correct for user environment
>> variables. To the
>> contrary, I'm actually pretty sure this very fact is the source of most of
>> this confusion.
>
> Just tested it (on an XP machine, will try on a Win7 as well) and it works
> too.

Ok, you are both right. Don't know what I've did before and how I came
to that conclusion... Perhaps I should leave Windows alone like I did
the last years...

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

--
Viktor Klang,
Code Connoisseur
Work:   akka.io
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

It is simply a fact of life that my students - like most of the world - use Windows
and it is not a good idea - not even for professionals - to ignore facts.
H.Peter

Am 03.11.2010 08:35, schrieb √iktor Klang:

AANLkTimHdzXjRXiMfe3d4_8E97d_ZzRrmZt-tUrkLdfX [at] mail [dot] gmail [dot] com" type="cite">Why the students are using Windows is a very good question too.

On Wed, Nov 3, 2010 at 8:32 AM, Johannes Rudolph <johannes [dot] rudolph [at] googlemail [dot] com" rel="nofollow">johannes.rudolph@googlemail.com> wrote:

On Tue, Nov 2, 2010 at 6:57 PM, Philippe Lhoste <PhiLho [at] gmx [dot] net" rel="nofollow">PhiLho@gmx.net> wrote:
> On 02/11/2010 16:46, Johannes Rudolph wrote:
>>
>> Did you test this? I think that this isn't correct for user environment
>> variables. To the
>> contrary, I'm actually pretty sure this very fact is the source of most of
>> this confusion.
>
> Just tested it (on an XP machine, will try on a Win7 as well) and it works
> too.

Ok, you are both right. Don't know what I've did before and how I came
to that conclusion... Perhaps I should leave Windows alone like I did
the last years...

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

--
Viktor Klang,
Code Connoisseur
Work:   akka.io
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

I think the OP was looking for Double.isNaN(x) similar to to
java.lang.Double.isNaN(x). There is no good documentation on
scala.Double, and x.isNaN is hardly intuitive.

On Tue, Nov 2, 2010 at 6:17 AM, Andreas Flierl wrote:
>
> I've just tried it, it seems to be there, whereever it may be defined:
>
> Welcome to Scala version 2.8.0.final (Java HotSpot(TM) Client VM, Java
> 1.6.0_22).
> Type in expressions to have them evaluated.
> Type :help for more information.
>
> scala> 3d.isNaN
> res0: Boolean = false
>
> scala> Double.NaN
> res1: Double = NaN
>
> scala> Double.NaN.isNaN
> res2: Boolean = true
>
> LML wrote:
>> Hi,
>>
>> Scala 2.8.0 final is missing Java's Double.isNaN function,
>> if this is still true for 2.8.1 it should be fixed,
>> or am I missing something else?
>>
>> Thanks
>>   Lothar
>
>

Hi,
it seems that isNaN is not documented in 2.8.0 final
as a method of RichDouble...

Thanks
Lothar

> I think the OP was looking for Double.isNaN(x) similar to to
> java.lang.Double.isNaN(x). There is no good documentation on
> scala.Double, and x.isNaN is hardly intuitive.
>
> On Tue, Nov 2, 2010 at 6:17 AM, Andreas Flierl wrote:
>>
>> I've just tried it, it seems to be there, whereever it may be defined:
>>
>> Welcome to Scala version 2.8.0.final (Java HotSpot(TM) Client VM, Java
>> 1.6.0_22).
>> Type in expressions to have them evaluated.
>> Type :help for more information.
>>
>> scala> 3d.isNaN
>> res0: Boolean = false
>>
>> scala> Double.NaN
>> res1: Double = NaN
>>
>> scala> Double.NaN.isNaN
>> res2: Boolean = true
>>
>> LML wrote:
>>> Hi,
>>>
>>> Scala 2.8.0 final is missing Java's Double.isNaN function,
>>> if this is still true for 2.8.1 it should be fixed,
>>> or am I missing something else?
>>>
>>> Thanks
>>> Lothar
>>
>>
>

On Thu, Nov 04, 2010 at 11:00:00AM +0100, LML wrote:
> it seems that isNaN is not documented in 2.8.0 final as a method of
> RichDouble...

That is because it isn't. It's a member of java.lang.Double.

On Thu, Nov 4, 2010 at 12:12 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Nov 04, 2010 at 11:00:00AM +0100, LML wrote:
> it seems that isNaN is not documented in 2.8.0 final as a method of
> RichDouble...

That is because it isn't.  It's a member of java.lang.Double.

For completeness: http://download.oracle.com/javase/6/docs/api/java/lang/Double.html#isNaN%28%29
 

--
Paul Phillips      | Christ died for our sins.  Dare we make his martyrdom
Caged Spirit       | meaningless by not committing them?
Empiricist         |     -- Jules Feiffer
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

On Thu, Nov 4, 2010 at 7:12 AM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Nov 04, 2010 at 11:00:00AM +0100, LML wrote:
> it seems that isNaN is not documented in 2.8.0 final as a method of
> RichDouble...

That is because it isn't.  It's a member of java.lang.Double.

But because of compiler magic, it's made to look like it is a method of RichDouble.

That's the confusing part.  When you had to Double.isNaN(2.0), it was obvious what to do.  It is much less obvious--because it's not written down where you might expect it--that 2.0.isNaN is the thing to do now.

  --Rex

On Thu, Nov 04, 2010 at 10:34:20AM -0400, Rex Kerr wrote:
> > That is because it isn't. It's a member of java.lang.Double.
>
> But because of compiler magic, it's made to look like it is a method of
> RichDouble.

It is? There's no compiler magic. It's the same implicit conversion
which always existed, Double => java.lang.Double. Where is it made to
look like a method on RichDouble?

> That's the confusing part. When you had to Double.isNaN(2.0), it was
> obvious what to do.

When did you have to do that? Looks like it's been a while.

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

scala> (2.0).isNaN
res0: Boolean = false

On Thu, Nov 4, 2010 at 10:39 AM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Nov 04, 2010 at 10:34:20AM -0400, Rex Kerr wrote:

It is? There's no compiler magic.  It's the same implicit conversion
which always existed, Double => java.lang.Double.  Where is it made to
look like a method on RichDouble?

Oops.  My mistake.  I guess I was projecting what I wished happened, instead of what actually happens.
 

> That's the confusing part.  When you had to Double.isNaN(2.0), it was
> obvious what to do.

When did you have to do that? Looks like it's been a while.

I meant that you used to be able to Double.isNaN(2.0), which is the natural thing to do coming from Java.  java.lang.Double.isNaN(2.0) is not quite as natural, nor is 2.0.isNaN.

I wonder if this is the cause of a performance glitch in code I translated from 2.7 (that uses NaN heavily as a much cheaper alternative to Option[Double])?  Better go check that the JVM was able to make it work the way it should.  *sigh*

  --Rex

Rex Kerr wrote:
> I meant that you used to be able to Double.isNaN(2.0), which is the
> natural thing to do coming from Java.  java.lang.Double.isNaN(2.0) is
> not quite as natural, nor is 2.0.isNaN.

I find it quite surprising that anyone finds "if (2d isNaN) { ... }"
actually LESS natural than "if (Double.isNaN(2d)) { ... }". Maybe if
one's coming from Java one's used to it. But then again, we don't write
String.getLength("abc") but "abc".length().

Best regards
Andreas

On Thu, Nov 4, 2010 at 11:23 AM, Andreas Flierl <andreas@flierl.eu> wrote:

Rex Kerr <ichoran@gmail.com> wrote:
> I meant that you used to be able to Double.isNaN(2.0), which is the
> natural thing to do coming from Java.  java.lang.Double.isNaN(2.0) is
> not quite as natural, nor is 2.0.isNaN.

I find it quite surprising that anyone finds "if (2d isNaN) { ... }"
actually LESS natural than "if (Double.isNaN(2d)) { ... }". Maybe if
one's coming from Java one's used to it.

Indeed.  That's why I said "coming from Java".  I prefer 2d.isNaN.

Except I won't be using that again in high-performance code.  I just checked, and there's a 10-20x performance penalty for doing it that way.  So I'm back to java.lang.Double.isNaN(2d).
 

But then again, we don't write
String.getLength("abc") but "abc".length().

That's because strings are not primitive objects.  (And for the person who asked about leaving off the parens--yes, that's standard Scala style: "abc".length, since length has no side effects.)

  --Rex

On Thu, Nov 4, 2010 at 10:40 AM, Rex Kerr <ichoran@gmail.com> wrote:

Except I won't be using that again in high-performance code.  I just checked, and there's a 10-20x performance penalty for doing it that way. 

Does -XX:+DoEscapeAnalysis do anything to alleviate that? I would think that that is one of the easiest cases to escape.

Yes, it's turned on. 10x appears to be when escape analysis is working, 20x when it is not.
  --Rex

On Thu, Nov 4, 2010 at 12:05 PM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

On Thu, Nov 4, 2010 at 10:40 AM, Rex Kerr <ichoran@gmail.com> wrote:

Except I won't be using that again in high-performance code.  I just checked, and there's a 10-20x performance penalty for doing it that way. 

Does -XX:+DoEscapeAnalysis do anything to alleviate that? I would think that that is one of the easiest cases to escape.

On Thu, Nov 4, 2010 at 11:28 AM, Rex Kerr <ichoran@gmail.com> wrote:

Yes, it's turned on. 10x appears to be when escape analysis is working, 20x when it is not.

Weird for such a simple case. One (me) would think that it would either be able to do the optimization or not. Is there room for something in between?

On Thu, Nov 4, 2010 at 5:40 PM, Nils Kilden-Pedersen wrote:
> Weird for such a simple case. One (me) would think that it would either be
> able to do the optimization or not. Is there room for something in between?

Yes, see an old blog post and the comments:

http://blog.juma.me.uk/2008/12/17/objects-with-no-allocation-overhead/

As usual, it's also important to make sure that the micro-benchmark
represents a realistic situation.

Best,
Ismael