[Caml-list] Int64 comparison
Do the polymorphic ordering functions -- (<), (>), etc. -- correspond to the numerical ordering for Int64s and Int32s? I assume so, but I didn't see this specified anywhere. If the answer is 'yes', is there a reason I should prefer Int64.compare n1 n2 < 0 to n1 < n2 ? If there's no specific reason the first is better (and I don't see why it would be), I definitely prefer the second. -Elnatan ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Representation of different polymorphic variants guaranteed to be different?
On Wed, 2009-07-08 at 14:54 -0400, Eric Cooper wrote: > On Wed, Jul 08, 2009 at 08:35:27PM +0200, Bruno Daniel wrote: > > How is it ensured that I get a <> b for a and b created as > > polymorphic variants from two different identifiers? Will pattern > > matching give wrong results if I accidentally choose two different > > identifiers translated to the same internal representation? > > See this thread: > > http://caml.inria.fr/pub/ml-archives/caml-list/2005/03/544288096a47d82ec870d01c8396f5fe.fr.html > > > Short answer: collisions could theoretically occur, but are detected > at link time. That thread actually concludes that the check is at compile-time: http://caml.inria.fr/pub/ml-archives/caml- list/2005/03/7965b012288982e74718b2ae769dc189.fr.html ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Physical counterpart to Pervasives.compare?
Is there something that can complete this analogy: (=) is to (==) as Pervasives.compare is to ___? That is, is there a polymorphic total ordering with respect to *physical* entities, rather than to their structure? I'm afraid of getting into trouble with Obj.magic, but what would this do: let f (x:'a) (y:'a) = compare (Obj.magic x) (Obj.magic y) ? Or would annotations make any difference: let f (x:'a) (y:'a) = compare (Obj.magic x : int) (Obj.magic y : int) -Elnatan ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions
Continuing this conversation about equality...
On Aug 9, 2009, at 9:20 AM, David Allsopp wrote:
Ivan Chollet wrote:
I would have thought physical equality implies structural equality,
but it
doesn't seem like it.
Can you please explain to me what’s wrong there?
"It does" - but only with the given caveat that comparison of cyclic
structures may not terminate. Pervasives.compare has a similar
restriction,
although note that [compare q q] in your example does return 0
(which is
lucky or it would be a bug as the docs for Pervasives.(==) state
that [x ==
y] => [compare x y = 0]).
Let me start with a few pedantic comments about the documentation of
(==):
First, what David says isn't *quite* what the documentation says. The
documentation only says this is [x==y] implies [compare x y = 0] for
non-mutable structures. And in fact, what the documentation says is
surprisingly weak: an implementation could define (==) as *always
false* for non-mutable structures and yet satisfy the documentation.
I'm not sure of the right way to reword it, but this loophole in the
specification seems undesirable.
My other issue is that the description of (==) for mutable structures
doesn't specify that it is symmetric; reading the documentation
literally only implies that e1 is a substructure of e2. Even just
adding 'and vice versa' might clean this up:
e1 == e2 is true if and only if physical modification of e1 also
affects e2 and vice versa
Okay, now for more substantive questions:
The notes in http://caml.inria.fr/mantis/view.php?id=3322 may be of
interest
too...
I hadn't paid attention to the distinction drawn between 'may not
terminate' and 'does not terminate' until I read the discussion at
that link, but it's relevant to my question below...
On Aug 9, 2009, at 9:55 AM, Alain Frisch wrote:
On 8/9/2009 2:06 PM, ivan chollet wrote:
I would have thought physical equality implies structural equality,
but
it doesn’t seem like it.
Can you please explain to me what’s wrong there?
There are two modes for the generic comparison. The total mode
(Pervasives.compare) creates a total ordering between values (except
for functional values and custom blocks with no comparison function)
and uses physical equality as a shortcut to cut the recursive
traversal of sub-values. The non-total mode (used by the operators =
< > <= >=) has a different behavior for NaN values ([nan <= x], [x
<= nan], and [nan = x] all return false, including when x is nan)
and does not use the physical equality shortcut (so that [let x =
(nan, nan) in x = x] returns false).
In terms of 'may not' versus 'does not' terminate, I just noticed that
the current documentation for (=) says 'may not terminate' while the
documentation for (>=) says 'does not terminate'. However, the example
cited in the link above:
type t = { a : t };;
let rec x = { a = x } in x = x
doesn't terminate in OCaml 3.11. This seems to be about as simple a
cyclic structure as there is, so shouldn't (=)'s documentation say
'Equality between cyclic structures does not terminate.'?
Also, the documentation for Pervasives.compare says 'may not
terminate'. Is this supposed to imply that it uses the shortcut Alain
mentions (because if it did not use physical equality as a shortcut
then it would say 'does not terminate')? Or is this shortcutting meant
to be undocumented?
And is there any reason, aside from NaN values, that (=) does *not*
use physical equality as a shortcut? The only other reason I can think
of is that, in cases where things are in fact *not* physically equal,
checking physical equality would introduce a small overhead.
In any case, if I have a data structure which I know does not contain
any NaNs (for example, maybe it doesn't contain any floats
whatsoever), is there ever a reason I should prefer (=) to (compare x
y = 0)? It sounds to me like compare is preferable because of its
shortcutting behavior.
-Elnatan___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions
On Sun, 2009-08-09 at 21:09 +0200, Alain Frisch wrote: > On 8/9/2009 8:56 PM, Elnatan Reisner wrote: > > My other issue is that the description of (==) for mutable structures > > doesn't specify that it is symmetric; reading the documentation > > literally only implies that e1 is a substructure of e2. Even just adding > > 'and vice versa' might clean this up: > > |e1 == e2| is true if and only if physical modification of |e1| also > > affects |e2 and vice versa| > > It depends on what 'physical modification' and 'affect' mean. Clearly, > the documentation means toplevel modifications of the values (i.e. > modifying fields for record values, or elements for arrays or strings). > If one includes deep modifications, then your extended criterion does > not work either (think about two mutually recursive records). You're right; thanks for pointing this out. But what does this mean for physical equality? What does it really mean? Does [e1 == e2] mean e1 and e2 are the same entity in memory---i.e., they are equal as C pointers? > Note that (=) sometimes terminates for cylic values. > > # type t = A of t | B of t;; > type t = A of t | B of t > # (let rec x = A x in x) = (let rec x = B x in x);; > - : bool = false Again, thanks for pointing this out. But can (=) ever evaluate to true on cyclic structures? -Elnatan ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions
On Mon, 2009-08-10 at 15:36 +0200, Martin Jambon wrote: > Elnatan Reisner wrote: > > On Sun, 2009-08-09 at 21:09 +0200, Alain Frisch wrote: > >> Note that (=) sometimes terminates for cylic values. > >> > >> # type t = A of t | B of t;; > >> type t = A of t | B of t > >> # (let rec x = A x in x) = (let rec x = B x in x);; > >> - : bool = false > > > > Again, thanks for pointing this out. But can (=) ever evaluate to true > > on cyclic structures? > > Yes: > > let rec x = `A x;; > let o = object val x = x end;; > o = o;; > > -> true Okay, give me one more try: Can (=) evaluate to true on cyclic structures that are not objects? (My understanding is that objects are compared---by both Pervasives.compare and by (=)---using only their object ids, so [obj1 = obj2] is always just an comparison of two ints, regardless of the contents of the objects. Is this correct?) Also, I just tested out (>=), which the documentation says 'does not terminate on cyclic structures': # (let rec x = `A x in x) >= (let rec x = `B x in x);; - : bool = false So maybe my question went the wrong way: apparently the documentation of (>=) should say 'may not terminate'. Also, if I may, let me add two additional questions: - Do (=), (<>), (<), (>), (<=), and (>=) all terminate on exactly the same operands? - Does Pervasives.compare terminate strictly more often, or are there cases when the comparisons terminate but [compare x y] does not? -Elnatan ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Looking for C preprocessing language parser with OCAML interface
On Oct 21, 2009, at 8:29 AM, Yoonseok Ko wrote: I'm looking for a C preprocessing language parser with OCAML interface. I was recently looking for such a tool myself, and I came across the link below mentioning Yacfe, from about a year ago. Unfortunately, it seems that the link provided there isn't working. http://www.mail-archive.com/caml-list@yquem.inria.fr/msg01850.html However, the project from which Yacfe was extracted, http://coccinelle.lip6.fr/ , is accessible. There might be something useful there. -Elnatan ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] 2147483648l < 2147483647l
On Jan 19, 2010, at 1:28 PM, David Allsopp wrote: Goswin von Brederlow wrote: # 2147483648l;; - : int32 = -2147483648l Isn't that documented properly? I think in the docs I saw at least that ocaml will silently overflow ints. Arithmetic operations are allowed to overflow silently but at no point do you end up with an illegal constant which is the bug here. i.e. Int32.add 2147483647l 1l correctly evaluates to -2147483648l but -2147483648l is a valid int32. The evaluation of a constant by the compiler in your ML source is supposed to follow the same rules as Int32.of_string (which would raise an exception if given "-2147483648l") hence 2147483648l which is not a valid int32 should be a "syntax" error. As a point of clarification, the top level and the to_string functions do have the same behavior; none of them raise an exception when given a literal representing max_int+1 or min_int. It doesn't matter whether this is done with ints, Int32s, or Int64s. (I am using OCaml 3.11.1 on a 32-bit machine.) # 1073741824,-1073741824;; - : int * int = (-1073741824, -1073741824) # int_of_string "1073741824",int_of_string "-1073741824";; - : int * int = (-1073741824, -1073741824) # 2147483648l,-2147483648l;; - : int32 * int32 = (-2147483648l, -2147483648l) # Int32.of_string "2147483648",Int32.of_string "-2147483648";; - : int32 * int32 = (-2147483648l, -2147483648l) # 9223372036854775808L,-9223372036854775808L;; - : int64 * int64 = (-9223372036854775808L, -9223372036854775808L) # Int64.of_string "9223372036854775808",Int64.of_string "-9223372036854775808";; - : int64 * int64 = (-9223372036854775808L, -9223372036854775808L) -Elnatan___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Re: interfacing Ocaml with Mathematica
On Sep 7, 2010, at 6:00 AM, caml-list-requ...@yquem.inria.fr wrote: Date: Tue, 7 Sep 2010 06:36:35 +0200 From: Basile Starynkevitch Subject: Re: [Caml-list] interfacing Ocaml with Mathematica To: zaid al-zobaidi Cc: caml-list@yquem.inria.fr Message-ID: <20100907063635.f2e4de47.bas...@starynkevitch.net> Content-Type: text/plain; charset=US-ASCII On Fri, 03 Sep 2010 16:49:38 +0100 zaid al-zobaidi wrote: Dear members I am writing an Ocaml code and part of it I need to do the following job: * I want to find out if two arithmetic or logical expressions are equal like "a + b" and "2 * a + b - a" or "a and b or a" and "a", and Ocaml So you want a formal tool working on formal expression trees [you don't want to work on strings]. I believe there are several of these. And there exist a limitation on them. IIRC, one of Robinson's theorems states that under suitable & reasonable hypothesis the formal equality problem is undecidable (perhaps: equality of functions expressed with an expression made from an unknown x, constants, four usual operations + - * /, square roots, trigonometric, logarithmic, exponential, ... is undecidable) On the other hand, rewriting such a simplification tool by yourself is a very interesting exercise. it is unlikely to achieve my target, therefore I checked the available packages and tools that can do the job and I found "Mathematica". I would appreciate if someone could guide me on how to interface (if possible)to mathematica from Ocaml programme. I would choose another tool than Mathematica. I would choose a free (as in speech) software. Very probably, Coq could be used that way (Coq is coded in & interfaced with Ocaml). But I don't know it well enough. Coq is a world by itself. Another possible route, although it might be overkill for your specific goal, would be to use an SMT solver. Two popular ones are Z3 [1] and Yices [2], and both have OCaml APIs. CVC3 [3] is another one, this one open-source, with an old OCaml API [4], but I have no idea if it works---you'd have to try it or ask the author. (Maybe there's a newer OCaml API that I'm unaware of; I just found this with a quick Google.) Elnatan [1] http://research.microsoft.com/en-us/um/redmond/projects/z3/ [2] http://yices.csl.sri.com/ [3] http://cs.nyu.edu/acsys/cvc3/ [4] https://code.launchpad.net/~cconway/+junk/cvc3-ocaml ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Pervasives.compare != Pervasives.compare
I was surprised when I noticed the following behavior: Objective Caml version 3.11.2 # compare == compare;; - : bool = false # let f = compare;; val f : 'a -> 'a -> int = # f == compare;; - : bool = false # f == f;; - : bool = true # let g = compare;; val g : 'a -> 'a -> int = # f == g;; - : bool = false Playing around a bit more, I seemed to find that every time you access an 'external' function, you get a distinct reference (is there a better term?) to it. This seems a bit odd to me. Can someone explain? Thanks, Elnatan ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
