From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <oleg@okmij.org>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by sympa.inria.fr (Postfix) with ESMTPS id B89F97EE51
	for <caml-list@sympa.inria.fr>; Tue, 16 Apr 2013 08:01:05 +0200 (CEST)
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  oleg@okmij.org) identity=pra; client-ip=66.39.3.115;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org";
  x-conformance=sidf_compatible
Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of
  oleg@okmij.org designates 66.39.3.115 as permitted sender)
  identity=mailfrom; client-ip=66.39.3.115;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org";
  x-conformance=sidf_compatible; x-record-type="v=spf1"
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@www1.g3.pair.com) identity=helo;
  client-ip=66.39.3.115;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="oleg@okmij.org";
  x-sender="postmaster@www1.g3.pair.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AucCAFjobFFCJwNzemdsb2JhbABQgzyvGZFsgRwOAQELBw0JPIIfAQEEegVKfR+HdAa8No8XHYMrA5M5A4NIAYEhkns8
X-IPAS-Result: AucCAFjobFFCJwNzemdsb2JhbABQgzyvGZFsgRwOAQELBw0JPIIfAQEEegVKfR+HdAa8No8XHYMrA5M5A4NIAYEhkns8
X-IronPort-AV: E=Sophos;i="4.87,483,1363129200"; 
   d="scan'208";a="11088457"
Received: from www1.g3.pair.com ([66.39.3.115])
  by mail3-smtp-sop.national.inria.fr with SMTP; 16 Apr 2013 08:01:04 +0200
Received: (qmail 68445 invoked by uid 9370); 16 Apr 2013 06:01:03 -0000
Date: 16 Apr 2013 06:01:02 -0000
Message-ID: <20130416060102.68444.qmail@www1.g3.pair.com>
From: oleg@okmij.org
To: paulfsnively@gmail.com
CC: caml-list@inria.fr
X-Validation-by: oleg@okmij.org
Subject: [Caml-list] Delimcc.0 OPAM Package Difficulty on Mac OS X


> ./test_samplingM
> rejection_sample: done 100 worlds
> Fatal error: exception Assert_failure("samplingM.ml", 16, 9)

Luckily, the assertion failure is harmless. Here is the complete code
where the failure occurs:

let tflip2_shared () =   (* sharing of flips *)
  let v = flip 0.5 in
  v && v;;
let () = assert (
  sample_rejection (random_selector 1) 100 tflip2_shared
    = [(0.48, V true); (0.52, V false)]);;

Essentially, we flip a coin 100 times and see how many times it comes
out head. The `random source' (random_selector 1) seeds the random
generator with a fixed value -- 1 in this case. Therefore, re-running
the code should give the same results. Alas, the implementation of
random number generator may change -- and it did between OCaml 3.11
and OCaml 3.12. Therefore, given the same seed, the sequence of
produced numbers can be different. Also, the behavior of the random
number generator may be platform-specific.

So, the good news is that the failure is harmless. The bad news is that
the change in the random number generator or the platform has
invalidated the regression tests. To see that Hansei functions
properly, one has to check the results manually. For example, 

  sample_rejection (random_selector 1) 100 tflip2_shared

may now produce  [(0.49, V true); (0.51, V false)]) or
[(0.52, V true); (0.48, V false)], etc.


> this is a little disturbing: I got almost-correct output with -O0 and
> -DDEBUG=1, but there was still a message about "can't happen" at the
> very end, still using Apple's GCC 4.2.1 for Mac OS X 10.6.8.  I got
> similarly incorrect results using the current release, 3.2, of clang.
> I then remembered that, some time ago, I'd installed a binary of a
> much more recent GCC 4.6.2 that I could optionally use. Using it, I
> get correct results from testd0opt, even without using -O0!
Very interesting! I do use GCC 4.2.1 but on FreeBSD. I guess the
problem is platform-specific (or GCC-backend specific). It could
happen that GCC 4.2.1 over-optimized on MacOS, and the later versions
of GCC have corrected the problem. Thank you for the investigation!