Re: RANDOMU bug (and HTML help)

[ajschmitt(at)my-dejanews.com]

In article <7avee5$ct8@post.gsfc.nasa.gov>,
  thompson@orpheus.nascom.nasa.gov (William Thompson) wrote:
> ajschmitt@my-dejanews.com writes:


(snip)
.
>
> >Consider the following behavior from IDL v 5..0.3:
> >IDL> seed = 2 & print, randomu(seed, 3)
> >     0.342299     0.402381     0.307838
> >...doing this multiple times will always give the same result.
>
> >However, in IDL v.5..1 & later,. using this several times in a row
> >produces different results each time.:
> >IDL> seed = 2 & print, randomu(seed, 3)
> >    0.0594004     0.982075     0.358593
> >IDL> seed = 2 & print, randomu(seed, 3)
> >     0.831999     0.303037     0.506712
>
> >...etcetera. It turns out that you now have to specify a NEGATIVE seed
> >in order for it to have any influence on the generated sequence:
>
> >seed = -2 & print, randomu(seed, 3)
> >     0.342299     0.402381     0.307838
> >seed = -2 & print, randomu(seed, 3)
> >     0.342299     0.402381     0.307838
>
> 	(rest deleted)
>
> That's interesting.  When I try this in IDL/v5.1.1, I get the same result over
> and over again, even with positive seeds.
>
> IDL> seed = 2 & print,randomu(seed,3)
>      0.342299     0.402381     0.307838
> IDL> seed = 2 & print,randomu(seed,3)
>      0.342299     0.402381     0.307838
> IDL> print,!version
> { alpha OSF unix 5.1.1 Jul 20 1998}
>
> The online help, though, still states that one is supposed to put in a negative
> number to re-use a seed.  In fact, the online help in version 5.1.1 is rather
> misleading in that it implies that the seed is a scalar value, whereas it's
> actually returned as a 36-element array just like in 5.2.  The 5.2 online help
> does away with any mention of needing to put in negative values.
>
> It looks like the business of needing to put in a negative number to force seed
> initialization is restricted to version 5.1.0.  Maybe fixing that problem is
> what introduced the other problem?

I agree, this behavior DOES appear to be restricted to version 5.1.0; here's
the version string from the IDL version I was running when I encountere the
problem:

IDL>print,!version
{ sparc sunos unix 5.1 Apr 13 1998}

I had made the statement that the bug occurred in idl v.5.1 and later, but
hadn't actually tested it in a later version. Silly me, I had assumed that if
RSI had bothered to change the documentation (however quietly), that they had
really changed the behavior of the SEED for good.

>
> Here's another weird behavior of RANDOMU.  If you call IDL with an undefined
> seed, it's supposed to initialize the seed for you.  Thus, when you type in
>
> IDL> print,randomu(seed,3)
>      0.653919    0.0668422     0.722660
>
> before seed is defined to anything, it still works.  Naively, I expected that
> if one deleted the seed variable, that would force IDL to re-initialize the
> seed, based on the system time or whatever.  However, if my next command is
>
> IDL> delvar,seed & print,randomu(seed,3)
>
> I don't get any random numbers at all.  To start getting random numbers again,
> I have to use a completely new variable name for the seed, e.g.
>


Strictly speaking, this isn't a bug, but a documented side effect of DELVAR
(unless they changed that TOO since my last copy of printed documentation):

"Each time DELVAR is called, the main program is erased. Variables that are
not deleted remain unchanged."

Thus, after the use of delvar in the first statement, the second statement is
"erased". Calling the two in sequence SHOULD give the expected result:

IDL> delvar, seed
IDL> print, randomu(seed,3)
     0.860873     0.661931     0.766831

-Andy Schmitt

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own