a scala puzzler for jun 7 2010

Paul Phillips wrote:
> What are x1 and x2?

scala> val x1 = new { def ==(that: String) = false ;
override def equals(that: Any) = true }

scala> val x2 = ""

On Tue, Jun 08, 2010 at 02:07:36PM +1000, Eric Willigers wrote:
> scala> val x1 = new { def ==(that: String) = false ;
> override def equals(that: Any) = true }
>
> scala> val x2 = ""

I figured there would be some attempts to cheat, and I do kind of like
that one, but let me add some of the conditions which made it hard
enough that I wondered if anyone would get it.

No custom classes. No custom equality. No blocks.

something that is unboxed when calling f. this is probably the
scal-version of the java puzzle
new Integer(5) == new Integer(5) -> false

and it's unboxd because of specialisation

win?
Paul Phillips schrieb:
> What are x1 and x2?
>
> scala> def f[T](x1: T, x2: T) = x1 == x2
> f: [T](x1: T,x2: T)Boolean
>
> [Cut assignments to val x1 and val x2.]
>
> scala> x1 == x2
> res0: Boolean = false
>
> scala> f(x1, x2)
> res1: Boolean = true
>
>

On Tue, Jun 08, 2010 at 07:44:38AM +0200, HamsterofDeath wrote:
> something that is unboxed when calling f. and it's unboxd because of
> specialisation
>
> win?

I can still see a few acres in outer mongolia you failed to fence in
with that one. This isn't your sociology final! We're programmers, let
us traffic in questions which have answers. Not always, but often, and
in this case.

Am 08.06.2010 um 04:51 schrieb Paul Phillips:

> What are x1 and x2?
>
> scala> def f[T](x1: T, x2: T) = x1 == x2
> f: [T](x1: T,x2: T)Boolean
>

val x1 = java.lang.Double.valueOf(-0d)
val x2 = java.lang.Double.valueOf(0d)

> scala> x1 == x2
> res0: Boolean = false
>
> scala> f(x1, x2)
> res1: Boolean = true

Bonus round: what are the values for the following results?

scala> x1 == x2
res0: Boolean = true

scala> f(x1, x2)
res1: Boolean = false

Moritz

can you repeat that in simple english?

-------- Original-Nachricht --------
> Datum: Mon, 7 Jun 2010 22:52:47 -0700
> Von: Paul Phillips
> An: HamsterofDeath
> CC: scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] a scala puzzler for jun 7 2010

> On Tue, Jun 08, 2010 at 07:44:38AM +0200, HamsterofDeath wrote:
> > something that is unboxed when calling f. and it's unboxd because of
> > specialisation
> >
> > win?
>
> I can still see a few acres in outer mongolia you failed to fence in
> with that one. This isn't your sociology final! We're programmers, let
> us traffic in questions which have answers. Not always, but often, and
> in this case.
>

On Tue, Jun 08, 2010 at 02:10:24PM +0200, Moritz Uhlig wrote:
> val x1 = java.lang.Double.valueOf(-0d)
> val x2 = java.lang.Double.valueOf(0d)

Nicely done! We also would have accepted Floats.

BTW, there's a little known shortcut:

scala> val x1 = Double.box(-0d)
x1: java.lang.Double = -0.0

scala> Double.unbox(x1)
res0: Double = -0.0

> Bonus round: what are the values for the following results?

Bonus round? I love bonus rounds! I'm going to act like I know the
answer to that but don't want to ruin it for anyone else.

On Tue, Jun 08, 2010 at 02:57:51PM +0200, Dennis Haupt wrote:
> can you repeat that in simple english?

A strange request: if I repeat it, it will still be in fancy english or
whatever dialect it is that I speak. Remember, "the limits of my
language mean the limits of my world."

On Tue, Jun 8, 2010 at 8:10 AM, Moritz Uhlig <moritz.uhlig@jsolution.de> wrote:

Bonus round: what are the values for the following results?

scala> x1 == x2
res0: Boolean = true

scala> f(x1, x2)
res1: Boolean = false

I guess it's been long enough....

scala> def f[T](x: T, y: T) = x == y
f: [T](x: T,y: T)Boolean

scala> val x = new java.lang.Double(Double.NaN)
x: java.lang.Double = NaN

scala> val y = new java.lang.Double(Double.NaN)
y: java.lang.Double = NaN

scala> x == y
res0: Boolean = true

scala> f(x,y)
res1: Boolean = false

The java.lang.Double.equals spec is really weird.

And let's not even get hashCode involved here.

  --Rex

But maybe somebody would be so kind to enlighten us lesser mortals as to why this is happening? :)

-Tako


On Tue, Jun 8, 2010 at 23:59, Rex Kerr <ichoran@gmail.com> wrote:

On Tue, Jun 8, 2010 at 8:10 AM, Moritz Uhlig <moritz.uhlig@jsolution.de> wrote:

Bonus round: what are the values for the following results?

scala> x1 == x2
res0: Boolean = true

scala> f(x1, x2)
res1: Boolean = false

I guess it's been long enough....

scala> def f[T](x: T, y: T) = x == y
f: [T](x: T,y: T)Boolean

scala> val x = new java.lang.Double(Double.NaN)
x: java.lang.Double = NaN

scala> val y = new java.lang.Double(Double.NaN)
y: java.lang.Double = NaN

scala> x == y
res0: Boolean = true

scala> f(x,y)
res1: Boolean = false

The java.lang.Double.equals spec is really weird.

And let's not even get hashCode involved here.

  --Rex

Am 09.06.2010 um 08:24 schrieb Tako Schotanus:

> But maybe somebody would be so kind to enlighten us lesser mortals as to why
> this is happening? :)

IEEE floating point numbers have certain rules for identity that are incompatible with the Java model for object identity.
For details see e.g.: .

If the Scala compiler encounters an expression "x == y" and the possible types for x and y contain the types used for boxing primitive values (java.lang.Character or descendants of java.lang.Number) then it substitutes that expression with a call to BoxesRunTime.equals(x,y).
This Method unboxes all boxed values before comparing them - thus you get the correct result regarding the floating point spec.

Moritz

Ok understood, and the reason why it isn't doing that in the case of the function?

-Tako


On Wed, Jun 9, 2010 at 17:43, Moritz Uhlig <moritz.uhlig@jsolution.de> wrote:

Am 09.06.2010 um 08:24 schrieb Tako Schotanus:

> But maybe somebody would be so kind to enlighten us lesser mortals as to why
> this is happening? :)

IEEE floating point numbers have certain rules for identity that are incompatible with the Java model for object identity.
For details see e.g.: <http://www.concentric.net/~Ttwang/tech/javafloat.htm>.

If the Scala compiler encounters an expression "x == y" and the possible types for x and y contain the types used for boxing primitive values (java.lang.Character or descendants of java.lang.Number) then it substitutes that expression with a call to BoxesRunTime.equals(x,y).
This Method unboxes all boxed values before comparing them - thus you get the correct result regarding the floating point spec.


Moritz

Am 09.06.2010 um 18:13 schrieb Tako Schotanus:

> Ok understood, and the reason why it isn't doing that in the case of the
> function?

Actually it ONLY does it that way inside the function because it does not know the type of the function arguments yet.

The comparison outside the function is performed with full type information and thus - as java.lang.Double <: AnyRef - it results in a call to x1.equals(x2).

> On Wed, Jun 9, 2010 at 17:43, Moritz Uhlig wrote:
>
>>
>> Am 09.06.2010 um 08:24 schrieb Tako Schotanus:
>>
>>> But maybe somebody would be so kind to enlighten us lesser mortals as to
>> why
>>> this is happening? :)
>>
>> IEEE floating point numbers have certain rules for identity that are
>> incompatible with the Java model for object identity.
>> For details see e.g.: <
>> http://www.concentric.net/~Ttwang/tech/javafloat.htm
>>> .
>>
>> If the Scala compiler encounters an expression "x == y" and the possible
>> types for x and y contain the types used for boxing primitive values
>> (java.lang.Character or descendants of java.lang.Number) then it substitutes
>> that expression with a call to BoxesRunTime.equals(x,y).
>> This Method unboxes all boxed values before comparing them - thus you get
>> the correct result regarding the floating point spec.
>>
>>
>> Moritz
>>
>>
>>

Sorry for coming so late (but I had some issues with this list and my
reply)

But here is my weird question.

You may take both methods:

def f(a1: Any, a2: Any)= a1== a2

or

def f1[T](a1: T, a2: T)= a1== a2

Show that f ( or f1 ) return true for the (non-existing!) value of type
Nothing and the value null.

regards
friedrich

My guess is he was trying to say that "something that is unboxed when ..." is too vague.

On Tue, Jun 8, 2010 at 8:57 AM, Dennis Haupt <h-star@gmx.de> wrote:

can you repeat that in simple english?

-------- Original-Nachricht --------
> Datum: Mon, 7 Jun 2010 22:52:47 -0700
> Von: Paul Phillips <paulp@improving.org>
> An: HamsterofDeath <h-star@gmx.de>
> CC: scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] a scala puzzler for jun 7 2010

> On Tue, Jun 08, 2010 at 07:44:38AM +0200, HamsterofDeath wrote:
> > something that is unboxed when calling f. and it's unboxd because of
> > specialisation
> >
> > win?
>
> I can still see a few acres in outer mongolia you failed to fence in
> with that one.  This isn't your sociology final! We're programmers, let
> us traffic in questions which have answers.  Not always, but often, and
> in this case.
>
> --
> Paul Phillips      | It is hard to believe that a man is
> Moral Alien        | telling the truth when you know that you
> Empiricist         | would lie if you were in his place.
> all hip pupils!    |     -- H. L. Mencken

--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01