Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random.float #8164

Closed
vicuna opened this issue Jun 6, 2003 · 3 comments
Closed

Random.float #8164

vicuna opened this issue Jun 6, 2003 · 3 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jun 6, 2003

Original bug ID: 1705
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Frank Dellaert
Version: 3.06
OS: Linux
Submission from: user-11fa88c.dsl.mindspring.com (66.245.33.12)

Short version: Random.float is probably broken in byte versions of the code.

Long version: we have been seeing qualitative differences between behavior of
byte vs native code whenever we use Random.float. We use Caml for visual
tracking, robot localization, and other probabilistic inference algorithms, so
that's pretty much all over the place. Finally, today, I replaced all our random
generators with stubs to a numerical recipes random number generator, and the
problem went away: native and byte code now behave the same way, in what seems
to be the correct way (like native code behaved before the patch). I can't say
quite for sure, but I suspect your byte code random number generator is broken.
Why there would be any difference at all stumps me, but you might know ?

I can't stress to you enough how serious this bug is, at least to my group (I
have at least 10 people working in Caml): we write papers with results that
heavily depend on a correct random generator...

Best of luck
Frank Dellaert

@vicuna
Copy link
Author

vicuna commented Jun 10, 2003

Comment author: administrator

Long version: we have been seeing qualitative differences between
behavior of byte vs native code whenever we use Random.float. We use
Caml for visual tracking, robot localization, and other
probabilistic inference algorithms, so that's pretty much all over
the place. Finally, today, I replaced all our random generators with
stubs to a numerical recipes random number generator, and the
problem went away: native and byte code now behave the same way, in
what seems to be the correct way (like native code behaved before
the patch).

On the Pentium processor, it is possible for floating-point code to
behave differently in bytecode and in native. The reason is that the
native code keeps some intermediate results in FP registers, which are
in extended precision (80 bits) on the Pentium, while the bytecode
stores all intermediate results in double precision (64 bits).

In general, the extended precision of native code doesn't hurt (the
results can be "more exact" in the least significant digit), but for
some ill-conditioned algorithms or code that runs into big
cancellation problems, the results may vary a lot.

This said, Random.float doesn't exhibit cancellation problems (it's
just scaled adds), so I'm surprised that you observe significant
differences between bytecode and native just because of Random.float
(and not because of cancellation problems somewhere else in your
code).

Indeed, I just tried the following experiment: generate 10000 random
floats between 0.0 and 1.0, with the same seed. The results in
bytecode and in native-code are identical up to 15 significant digits.

If you have more information that could help us pinpoint the potential
problem with Random.float (e.g. a statistical test that Random.float
fails in bytecode and passes in native-code), please let us know.

Best regards,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jun 15, 2003

Comment author: administrator

Random.float generates exactly the same floats in bytecode and native. The
problem probably comes from ill-conditioned computations elsewhere taht expose
the difference between double-precision computations in bytecode and mixed
extended- and double-precision computation in native on the x86.

@vicuna vicuna closed this as completed Jun 15, 2003
@vicuna
Copy link
Author

vicuna commented Sep 15, 2003

Comment author: administrator

This said, Random.float doesn't exhibit cancellation problems (it's
just scaled adds), so I'm surprised that you observe significant
differences between bytecode and native just because of Random.float
(and not because of cancellation problems somewhere else in your
code).

Indeed, I just tried the following experiment: generate 10000 random
floats between 0.0 and 1.0, with the same seed. The results in
bytecode and in native-code are identical up to 15 significant digits.

If you have more information that could help us pinpoint the potential
problem with Random.float (e.g. a statistical test that Random.float
fails in bytecode and passes in native-code), please let us know.

Well, sorry about the long silence, but it's been extremely busy at our end.
We resolved this problem by coding up a basic random generator in C (from
numerical recipes) and deriving all our random generation from it. I know
this does not help you pinpoint the problem but we have not seen
discrepancies since.

Frank

@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant