[Caml-list] Stupid question

[Caml-list] Stupid question

[Brian Hurt]

I was poking around in the produced assembly code of some ocaml code of 
mine, and I noticed something.  The construct:
	if (x < m) <> (y < m) then
		...

when the compiler knows that x, y, and m are all ints, it calls an 
external C routine to compare the two booleans.  But the construct:

	if (x < m) != (y < m) then
		...

does not.  Now, this isn't a big deal- I just replaced <> with != and no 
problem.  But I was kind of interested in why the compiler didn't catch 
and optimize this.  Is there some sort of subtle semantic difference I'm 
too dense to see?

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Stupid question

[skaller]

On Thu, 2004-01-15 at 11:03, Brian Hurt wrote:
> I was poking around in the produced assembly code of some ocaml code of 
> mine, and I noticed something.  The construct:
> 	if (x < m) <> (y < m) then
> 		...
> 
> when the compiler knows that x, y, and m are all ints, it calls an 
> external C routine to compare the two booleans.  But the construct:
> 
> 	if (x < m) != (y < m) then
> 		...
> 
> does not.  Now, this isn't a big deal- I just replaced <> with != and no 
> problem.  But I was kind of interested in why the compiler didn't catch 
> and optimize this.  Is there some sort of subtle semantic difference I'm 
> too dense to see?

Well, <> is a polymorphic value comparison.
Whereas != is a physical inequality comparison.

-- 
John Max Skaller, mailto:skaller@tpg.com.au
snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Stupid question

[Brian Hurt]

On 15 Jan 2004, skaller wrote:

> Well, <> is a polymorphic value comparison.
> Whereas != is a physical inequality comparison.

Yes.  I was wondering why the compiler didn't catch that I was comparing 
booleans and thus it could inline the value comparison, and reduce it to 
the equivelent to !=.  I've gotten into the habit of writting <> because 
I'm playing around with FP, and 1. <> 1. is false, while 1. != 1. is true.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Stupid question

[Christophe Raffalli]

Brian Hurt wrote:
> On 15 Jan 2004, skaller wrote:
> 
> 
>>Well, <> is a polymorphic value comparison.
>>Whereas != is a physical inequality comparison.
> 
> 
> Yes.  I was wondering why the compiler didn't catch that I was comparing 
> booleans and thus it could inline the value comparison, and reduce it to 
> the equivelent to !=.  I've gotten into the habit of writting <> because 
> I'm playing around with FP, and 1. <> 1. is false, while 1. != 1. is true.
> 

Usually it is good to avoid comparing float with = and <> ...

|a-b|<epsilon is usually what you really need (except when you use float 
as higher precision int to store date (see Unix.stats) or other similar 
stuff ...). By the way why not use Int64 instead ?



-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Stupid question

[Jacques Garrigue]

From: skaller <skaller@tpg.com.au>
> On Thu, 2004-01-15 at 11:03, Brian Hurt wrote:
> > I was poking around in the produced assembly code of some ocaml code of 
> > mine, and I noticed something.  The construct:
> > 	if (x < m) <> (y < m) then
> > 		...
> > 
> > when the compiler knows that x, y, and m are all ints, it calls an 
> > external C routine to compare the two booleans.  But the construct:
> > 
> > 	if (x < m) != (y < m) then
> > 		...
> > 
> > does not.  Now, this isn't a big deal- I just replaced <> with != and no 
> > problem.  But I was kind of interested in why the compiler didn't catch 
> > and optimize this.  Is there some sort of subtle semantic difference I'm 
> > too dense to see?
> 
> Well, <> is a polymorphic value comparison.
> Whereas != is a physical inequality comparison.

Yes indeed.
But the compiler is clever enough to use specific comparison functions
when the type is known to be int or float.
Since bool looks like a subset of int, one might expect it to be
optimised also. However, bool is just a normal sum type, and since
some sum types have non-constant constructors, in general sum types
require a recursive comparison operation.
For types where constructors are constant, this might be optimised...

Jacques Garrigue

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Stupid question

[Brian Hurt]

On Fri, 16 Jan 2004, Jacques Garrigue wrote:

> From: skaller <skaller@tpg.com.au>
> Yes indeed.
> But the compiler is clever enough to use specific comparison functions
> when the type is known to be int or float.
> Since bool looks like a subset of int, one might expect it to be
> optimised also. However, bool is just a normal sum type, and since
> some sum types have non-constant constructors, in general sum types
> require a recursive comparison operation.
> For types where constructors are constant, this might be optimised...

OK.  This makes more sense.  Well, except for the nitpicking detail that 
true and false are not valid variant type identifiers, they should be True 
and False.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Stupid question

[Nicolas Cannasse]

> > > I was poking around in the produced assembly code of some ocaml code
of
> > > mine, and I noticed something.  The construct:
> > > if (x < m) <> (y < m) then
> > > ...
> > >
> > > when the compiler knows that x, y, and m are all ints, it calls an
> > > external C routine to compare the two booleans.  But the construct:
> > >
> > > if (x < m) != (y < m) then
> > > ...
> > >
> > > does not.  Now, this isn't a big deal- I just replaced <> with != and
no
> > > problem.  But I was kind of interested in why the compiler didn't
catch
> > > and optimize this.  Is there some sort of subtle semantic difference
I'm
> > > too dense to see?
> >
> > Well, <> is a polymorphic value comparison.
> > Whereas != is a physical inequality comparison.
>
> Yes indeed.
> But the compiler is clever enough to use specific comparison functions
> when the type is known to be int or float.
> Since bool looks like a subset of int, one might expect it to be
> optimised also. However, bool is just a normal sum type, and since
> some sum types have non-constant constructors, in general sum types
> require a recursive comparison operation.
> For types where constructors are constant, this might be optimised...

You mean that actually comparisons on type t = A | B | C are using
polymorphic recursive C function ?
That's not nice, especially when working with lexers that generate this kind
of tokens. I would expect that such enumerations should be as fast as in C.
If someone hasn't posted yet a feature request for improving that, I'll do.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Stupid question

[Hendrik Tews]

Brian Hurt writes:
   
   OK.  This makes more sense.  Well, except for the nitpicking detail that 
   true and false are not valid variant type identifiers, they should be True 
   and False.
   
There is a special exception: true, false, [], (), and :: are
constructor names, see 6.3 Naming objects. One can ideed write 

# type x = true of int | () of string | :: of float

only [] do not work as (not ;-)) expected: 

# type x = [] of int;;
Syntax error


(I think I filed a bug report about [], but the ocaml web pages
are just not reachable, so I can't give a reference.)

Bye,

Hendrik

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Stupid question

[Frederic van der Plancke]

Hendrik Tews wrote:
> 
> Brian Hurt writes:
> 
>    OK.  This makes more sense.  Well, except for the nitpicking detail that
>    true and false are not valid variant type identifiers, they should be True
>    and False.
> 
> There is a special exception: true, false, [], (), and :: are
> constructor names, see 6.3 Naming objects. One can ideed write
> 
> # type x = true of int | () of string | :: of float

But you better have a pair of types after '::' ;-)

# let x = true 123;;
val x : x = true 123
# let y = () "eh eh";;
val y : x = () "eh eh"
# let z = :: 1.5;;
Toplevel input:
# let z = :: 1.5;;
          ^^
Syntax error
# let z = 1.5 ::;;
Toplevel input:
# let z = 1.5 ::;;
                ^^
Syntax error
# let z = 1.5 :: 1.5;;
Toplevel input:
# let z = 1.5 :: 1.5;;
          ^^^^^^^^^^
This expression has type float * float but is here used with type float

Frédéric vdP

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Stupid question

[Alex Baretta]

Frederic van der Plancke wrote:
> 
> Hendrik Tews wrote:
>
>>There is a special exception: true, false, [], (), and :: are
>>constructor names, see 6.3 Naming objects. One can ideed write
>>
>># type x = true of int | () of string | :: of float
> 
> 
> But you better have a pair of types after '::' ;-)

You'd also better make sure that the the type definition is 
right-recursive through :: , or you won't be able to type-check

let fuz = foo :: bar :: buz

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners