Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Versions 5.1.1 and 5.2 of IDL have a bug in the RANDOMU (and RANDOMN) function such that the SEED variable is initialized to the same value at the start of each session, rather than being intialized by the system clock (see example below). I believe that so long as one as one stays within one IDL session that this causes no problems, but if one is, say, combining Monte Carlo simulations from different IDL sessions, then the results will be decidedly unrandom. RSI knows about this problem and say that they are giving it very high priority for a fix. On another subject, does anyone know if there is a HTML help distribution for IDL V5.2, like there was for IDL V5.1? I couldn't find one on the CD-Rom distribution. --Wayne Landsman landsman@mpb.gsfc.nasa.gov mpb{landsman}102: idl IDL> print,!VERSION { sparc sunos unix 5.2 Oct 30 1998} IDL> print,randomu(seed) 0.415999 IDL> print,randomu(seed) 0.0919649 IDL> exit mpb{landsman}102: idl IDL Version 5.2 (sunos sparc). Research Systems, Inc. IDL> print,randomu(seed) 0.415999 IDL> print,randomu(seed) 0.0919649
In article <7ascms$kin$1@nnrp1.dejanews.com>, ajschmitt@my-dejanews.com writes... > This is not the worst of it. For some of us, it is important to be able > to have the same seed so that the same "random" sequence is produced. > However, RSI quietly changed the manner in which the SEED variable > interacts with the RANDOM functions between version 5.0 & 5.1. > > 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 What exact version and machine are you using? On Solaris under IDL V5.2, RANDOMU works as described above for V5.0.3. I suppose that those of us who use the RANDOMU function will have explicitly watch for specific IDL versions and machines (like we used to have to do for BYTEORDER). Sigh... IDL> print,!VERSION { sparc sunos unix 5.2 Oct 30 1998} 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 --Wayne Landsman landsman@mpb.gsfc.nasa.gov
Andy Schmitt (ajschmitt@my-dejanews.com) writes: > This is not the worst of it. For some of us, it is important to be able > to have the same seed so that the same "random" sequence is produced. > However, RSI quietly changed the manner in which the SEED variable > interacts with the RANDOM functions between version 5.0 & 5.1. > > 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 For what it is worth, this line produces the very same result over and over again in my Windows NT IDL 5.2a version: 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> 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 Perhaps it is fixed in IDL 5.2? When you say "IDL v5.1 & later" did you test it in IDL 5.2? I've been having my own problems with unannounced changes in the way !D.N_Colors works from IDL 5.0 to 5.1 to 5.2. :-( Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438 E-Mail: davidf@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
In article <21FEB199900213357@stars.gsfc.nasa.gov>, landsman@stars.gsfc.nasa.gov (Wayne Landsman) wrote: > Versions 5.1.1 and 5.2 of IDL have a bug in the RANDOMU (and RANDOMN) function > such that the SEED variable is initialized to the same value at the start of > each session, rather than being intialized by the system clock (see example > below). I believe that so long as one as one stays within one IDL session > that this causes no problems, but if one is, say, combining Monte Carlo > simulations from different IDL sessions, then the results will be decidedly > unrandom. > > RSI knows about this problem and say that they are giving it very high > priority for a fix. > This is not the worst of it. For some of us, it is important to be able to have the same seed so that the same "random" sequence is produced. However, RSI quietly changed the manner in which the SEED variable interacts with the RANDOM functions between version 5.0 & 5.1. 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 I assume that RSI knows about this (since it's documented in the new online help file), but they didn't see fit to mention it in the release notes accompanying version 5.1. Whatever reason they may have had for changing this behavior (which has been working the previous way since IDL version 1.0 at least 14 years ago) I cannot fathom. (Is there some reason someone would bother to set the seed only to have it be ignored by the random functions???) This new "feature" caused one of my coworkers to waste more than a day of his time tracking down the poorly documented change. Needless to say, we are not very satisfied with RSI about this. -Andy Schmitt -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
In article <21FEB199900213357@stars.gsfc.nasa.gov>, landsman@stars.gsfc.nasa.gov (Wayne Landsman) writes: > > On another subject, does anyone know if there is a HTML help > distribution for IDL V5.2, like there was for IDL V5.1? > I couldn't find one on the CD-Rom > distribution. From a message I received from RSI regarding IDL HTML help: "The IDL html help files were removed from the IDL 5.2 distribution as a space-saving measure. They are considered to be redundant." It looks like we are stuck with the painfully slow "hyperhelp".
ajschmitt@my-dejanews.com writes: > In article <21FEB199900213357@stars.gsfc.nasa.gov>, > landsman@stars.gsfc.nasa.gov (Wayne Landsman) wrote: >> Versions 5.1.1 and 5.2 of IDL have a bug in the RANDOMU (and RANDOMN) function >> such that the SEED variable is initialized to the same value at the start of >> each session, rather than being intialized by the system clock (see example >> below). I believe that so long as one as one stays within one IDL session >> that this causes no problems, but if one is, say, combining Monte Carlo >> simulations from different IDL sessions, then the results will be decidedly >> unrandom. >> >> RSI knows about this problem and say that they are giving it very high >> priority for a fix. >> > This is not the worst of it. For some of us, it is important to be able > to have the same seed so that the same "random" sequence is produced. > However, RSI quietly changed the manner in which the SEED variable > interacts with the RANDOM functions between version 5.0 & 5.1. > 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? 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. IDL> print,randomu(seed2,3) 0.671149 0.383416 0.631635 I don't know if this is properly speaking a bug or not, but it's certainly weird. As far as I can tell, this behavior is seen in all versions of IDL. Bill Thompson
In article <7arrcv$a7$1@hammer.msfc.nasa.gov>, mallors@msfc.nasa.gov (Robert S. Mallozzi) writes... > From a message I received from RSI regarding IDL HTML help: > > "The IDL html help files were removed from the IDL 5.2 > distribution as a space-saving measure. They are considered > to be redundant." > > It looks like we are stuck with the painfully slow "hyperhelp". Under Solaris, the hyperhelp also has the occasional habit of crashing the system. Another advantage of the html help files is that html is the easiest method of creating help files for user written procedures. Thus one can create links between the documentation for intrinsic and user-written procedures, or create a search page that includes both intrinsic and user-written procedures. (I have a simple interface for the latter at http://idlastro.gsfc.nasa.gov/cgi-bin/search_idl.cgi) Finally html has the advantage of being a familiar interface (e.g. Netscape or Explorer) across all systems, whereas I often find myself reading the help on how to use the IDL hyperhelp. --Wayne Landsman landsman@mpb.gsfc.nasa.gov
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
William Thompson wrote: > 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. > > IDL> print,randomu(seed2,3) > 0.671149 0.383416 0.631635 > > I don't know if this is properly speaking a bug or not, but it's certainly > weird. As far as I can tell, this behavior is seen in all versions of IDL. > > Bill Thompson On my Linux box i get exactely the same thing although I don't have to use a new variable for the seed. IDL> print, !version { x86 linux unix 5.2 Oct 30 1998} IDL> print,randomu(seed,3) 0.272710 0.897656 0.274907 IDL> delvar,seed & print,randomu(seed,3) no output IDL> print,randomu(seed,3) 0.00769819 0.365339 0.266145 this works too IDL> delvar, seed IDL> print,randomu(seed,3) 0.986642 0.277082 0.629543 Ivan Zimine
Bill Thompson wrote: > 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. > > IDL> print,randomu(seed2,3) > 0.671149 0.383416 0.631635 > > I don't know if this is properly speaking a bug or not, but it's certainly > weird. As far as I can tell, this behavior is seen in all versions of IDL. At first, I didn't understand what you were saying here - what could you mean by "I don't get any random numbers at all"? Was it the same number over and over again, or what? (In retrospect, I see that this is an incorrect interpretation of the sentence..) Then I tried it myself: IDL> delvar,seed & print,randomu(seed,3) - and *no* output (hence "no random numbers at all")! Seems like the guy who wrote the DELVAR command did something quite bizarre: IDL> delvar,seed & print,"HI" - *still* no output! Luckily, DELVAR cannot be used in programs! Regards, Stein Vidar