[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] rand(3) in avr-libc
From: |
Joerg Wunsch |
Subject: |
Re: [avr-libc-dev] rand(3) in avr-libc |
Date: |
Wed, 16 Oct 2002 17:59:15 +0200 |
User-agent: |
Mutt/1.2.5i |
This discusion happened a while ago. I just noticed that the
uncommitted changes were still lingering around here.
As E. Weddington wrote:
> > It fixes the remaining problems with using long constants in the
> > source code (that silently got truncated to 16 bits before), it uses
> > the newer algorithm by default to produce better randomness, and IMHO
> > we also need to pass an unsigned long * (as opposed to an unsigned *)
> > in rand_r() since we'd otherwise truncate the temporary storage which
> > defeats the entire algorithm. Even the old algorigthm (that's used if
> > USE_WEAK_SEEDING is defined) required a `long' for temporary storage.
All fixed now.
> > As for supplying an additional set of functions returning long instead
> > of the standards-mandated int, there are two options i would see:
> >
> > 1 We copy over the existing rand.c into a random.c, and just replace
> > the result type (and the type passed to srandom()) from `int' to
> > `long', including of course using RANDOM_MAX == 0x7fffffff for
> > limiting the result. The advantage is that the resulting file will
> > still be relatively small (~ 300 bytes of ROM).
I did just that.
> > 2 We port over the full-fledged random.c from BSD. This would offer a
> > more sophisticated pseudo-random number generator that while using
> > the same algorithm that's now in the proposed rand.c file, can use a
> > lot more of temporary storage for state information (up to 256
> > bytes) to increase the period. To quote the BSD man page:
> >
> > With 256 bytes of state information, the period of the random
> > number generator is greater than 2**69 which should be sufficient
> > for most purposes.
That remains as an exercise for the user should anyone really pop up,
and actually need it. I once did it, it's not all that much work to
port the BSD file over to the AVR (just replace a few "int" by "long"
etc.), but right now and given its relatively high costs, i don't see
there's much demand for it.
Should we ever want to import that into avr-libc, however we need to
decide about the naming, since random()/srandom() are now taken. If
someone's going to do this inside an application, there's not much
collision with the version in avr-libc: the function prototypes for
random() and srandom() are identical between our new 32-bit version
and the BSD version, and supplying a user implementation file will
always take precedence over the library.
--
J"org Wunsch Unix support engineer
address@hidden http://www.interface-systems.de/~j/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [avr-libc-dev] rand(3) in avr-libc,
Joerg Wunsch <=