Re: Not intended for use in medical,

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <EAA6so.JAz@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

  > As Robert said: Try to write the code using only portable features -- I
  > think you'll find that there's nowhere to put the Generator data, except
  > in the heap.  (Actually, I suppose I should say "a heap" -- you could
  > create your own data structure that acts as a heap.)

  Yep.  I pointed out to Robert Dewer in a back-channel discussion,
but a point which definitely belongs here, that the real problem comes
from the implicit assumption that programs that create lots of
generators are somehow "normal."  One generator is very normal, two or
three is even understandable but, there is not enough entropy in the
environment to make dozens of PRNGs meaningful absent access to a
source of true random bits.

  In point of fact for most RNGs, creating more than, say, a dozen
generators will make your results very suspect.  For the generator in
GNAT, you can create a set of thousands of independent generators
using the standard interface.  But it ain't easy.

  If you need to do it.  Create a random integer from a source of
entropy outside the program, or just use a default generator and reset
it using the clock.  Now use a sequence of integers to seed your
generators:

   Seed: Integer := ...;
   Generators: array (Integer range 1..10000) of
           Ada.Numerics.Float_Random.Generator;
   ...

   if Seed > Integer'Last - Generators'Last
   then Seed = Seed + Integer'First; end if;
   --technically this introduces a bias but a very slight one...

   for I in Generators'Range loop
     Reset(Generators(I),Seed + I);
   end loop;

   Okay, now you can generate away knowing that no two of your
generators will create a correlated sequence, or a sequence that
correlates with a lead or lag.  (Unless you use tens of millions of
values from each generator.)

  > No fair using Unchecked_Conversion to convert an Address (or an
  > access-to-constant) to an access-to-variable type -- you could do
  > it that way on some compilers, but it's not formally portable.

  Having gone through the why, it is perfectly reasonable to make the
Generator parameter an index into a small set of actual generators in
the body of the generator package.  (Use index mod N for some small N
if you don't want to worry people whose programs are junk.  However,
you had better make those generators protected objects in a tasking
environment.)

  > Actually, the semantics of GNAT's 'Unrestricted_Access are defined
  > as Unch_Conv of a 'Address -- which of course doesn't really
  > "define" the semantics at all, since the semantics of such an
  > unchecked conversion is not defined.

  > An 'in' parameter is a constant.  If you succeed in modifying one, you
  > are necessarily doing something undefined!

  Worse than that.  Since you are actually accessing the Generator
through two different paths (an in parameter and an access type), this
is formally a bounded error. see 6.2(12).  Of course it is harmless in
this case--the compiler vendor provides the package and knows what the
behavior is.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...