Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2006-05-10 00:56:57
Attachments:
normal.png
|
OK, since SourceForge CVS seems to be working, somewhat, I'm trying the latest software and attempting some plot types I hadn't really used before. Some observations:
1) Is the CVS synched with what developers have checked in? If so, there is still a problem with arrow style parsing, i.e., arrowstyle.dem fails:
turn to continue
plot '1.dat' using 1:2:(+1):(+1) with vectors lt 4 filled title 'filled', '2.dat' using 1:2:(+1):(+1) with vectors lt 1 heads title 'double-headed', '2.dat' using ($1):(2-$2/3):(+1):(+.5) with vectors lt -1 lw 3 nohead title 'no head'
^
"arrowstyle.dem", line 91: ';' expected
2) 3D plot layout is definitely the thing most in need of work post 4.2. The default colorbox seems too big and out of place. The x-y plane position seems slightly limited. Let me give an example to illustrate a few things. The following is meant to show a zero mean, unit variance Gaussian r.v. density. The contour is supposed to represent the variance in some way, and there are supposed to be a set of Gaussian samples with zero mean, unit variance.
set hidden3d
set contour
set isosamples 60
set view 68, 28, 1, 1
unset key
unset title
set cntrparam levels discrete 0.1
set style line 1 linecolor rgb "black"
set term x11 2
set parametric
set xrange [-5:5]
set yrange [-5:5]
set urange [-5:5]
set vrange [-5:5]
set xyplane at -0.2
splot u,v,( 1/(2*pi) * exp(-0.5 * (u**2 + v**2)) ) with line ls 1, \
sqrt(-2*log(rand(0)))*cos(2*pi*rand(0)),sqrt(-2*log(rand(0)))*sin(2*pi*rand(0)),-0.2 with points pointtype 7 linecolor rgb "black"
My intent was to have the points on the x-y plane and drop the x-y plane to leave enough space that the surface plot doesn't obstruct the points. Using the "set xyplane #" just didn't seem to get me there. The axes would remain the same and the x-y plane would extend off the plot, which just seemed silly.
Then "set xyplane at -0.2" and setting the z-value of the points to -0.2 puts the points and x-y plane in the same plane, but notice that the line of the z-axis still extends down to where the xyplane used to be. (That's a bug, isn't it? Or am I missing something?) Consequently, the plot isn't using the space efficiently.
3) It sure is annoying going through the trouble of looking up in "test" (x11) the number of the symbol desired, and then the symbol comes out differently in the output file (png). Regardless of the different symbols from one output terminal to another, I find it so confusing, because looking at "test" as a PNG output the "7" is actually a solid symbol, but not in this example (see attached "normal.png"). Also, is it OK to use "linecolor rgb "black" to control symbol color as I did? Actually, I'd think that the "linecolor", "pointtype" is an extraneous syntax. Couldn't it just be "points type 7 color rgb "black""? Or in the case of lines, "lines type 1"?
4) In a related category would be contours. I wanted to force the contours to be all of the same color, in this case black. That doesn't seem possible.
5) In the example, I really only want about 25 samples. IS THERE SOME WAY TO CONTROL THIS? Setting the samples # doesn't seem to effect this. Ethan has an example where he assigns a dozen or two random numbers but that is based off the number of samples in a data file, i.e., "using 1:2:rand(0)".
6) Would anyone object to a patch for a math function "randn()" generating unit variance normal distribution random values using the Box-Mueller method? The last line of the above example constitutes the polar method; it would just save a lot of typing in generating normal r.v.s.
7) Anyone notice that the above example in the x11 terminal is rather slow refresh (even when the sample points are not included)? I realize that it takes a while to create the rendering of hidden lines with so many iso-lines, but once it is drawn one would think the refresh in gnuplot-x11 would be fairly fresh. Yes, it has a lot of lines; but still, drawing lines shouldn't be so slow.
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-05-10 01:25:45
|
On Tuesday 09 May 2006 06:05 pm, Daniel J Sebald wrote: > OK, since SourceForge CVS seems to be working SourceForge is definitely not recovered yet. Their current status page says that they have not even taken full delivery of the replacement hardware they need, let alone installed and commissioned it. The source files I see on anonymous CVS are 6 weeks out of date. I can't even see the developer CVS files; they've been incommunicado since some time yesterday. It won't let me log in to the shell server either. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From:
<br...@ph...> - 2006-05-10 13:21:12
|
Daniel J Sebald wrote: > 2) 3D plot layout is definitely the thing most in need of work post > 4.2. The default colorbox seems too big and out of place. The x-y > plane position seems slightly limited. Let me give an example to > illustrate a few things. The following is meant to show a zero mean, > unit variance Gaussian r.v. density. The contour is supposed to > represent the variance in some way, and there are supposed to be a set > of Gaussian samples with zero mean, unit variance. > set hidden3d > set contour > set isosamples 60 > set view 68, 28, 1, 1 > unset key > unset title > set cntrparam levels discrete 0.1 > set style line 1 linecolor rgb "black" > set term x11 2 > set parametric > set xrange [-5:5] > set yrange [-5:5] > set urange [-5:5] > set vrange [-5:5] > set xyplane at -0.2 > splot u,v,( 1/(2*pi) * exp(-0.5 * (u**2 + v**2)) ) with line ls 1, \ > sqrt(-2*log(rand(0)))*cos(2*pi*rand(0)),sqrt(-2*log(rand(0)))*sin(2*pi*rand(0)),-0.2 > with points pointtype 7 linecolor rgb "black" > > My intent was to have the points on the x-y plane and drop the x-y plane > to leave enough space that the surface plot doesn't obstruct the > points. Using the "set xyplane #" just didn't seem to get me there. > The axes would remain the same and the x-y plane would extend off the > plot, which just seemed silly. > > Then "set xyplane at -0.2" and setting the z-value of the points to -0.2 > puts the points and x-y plane in the same plane, but notice that the > line of the z-axis still extends down to where the xyplane used to be. > (That's a bug, isn't it? Or am I missing something?) Consequently, the > plot isn't using the space efficiently. > > 3) It sure is annoying going through the trouble of looking up in > "test" (x11) the number of the symbol desired, and then the symbol comes > out differently in the output file (png). Well, then don't. As it's said throughout engineering: test what you fly, not what is easy to test. There's no particularly strong reason not to optimize the plot directly in PNG format. > Actually, I'd think that the "linecolor", "pointtype" is an extraneous > syntax. Couldn't it just be "points type 7 color rgb "black""? No, because that syntax would fail miserably in the case of 'with linespoints': what type does "type" address: that of the points, or that of the lines? > 4) In a related category would be contours. I wanted to force the > contours to be all of the same color, in this case black. That doesn't > seem possible. It is. "help set noclabel" > 5) In the example, I really only want about 25 samples. IS THERE SOME > WAY TO CONTROL THIS? Setting the samples # doesn't seem to effect > this. You'll have to elaborate. Exact input, output, and a description why the output isn't what you wanted, please. > 6) Would anyone object to a patch for a math function "randn()" > generating unit variance normal distribution random values using the > Box-Mueller method? I would: it's not needed. You have rand(), you have invnorm, that's all you need. Also see 'stat.inc'. > 7) Anyone notice that the above example in the x11 terminal is rather > slow refresh (even when the sample points are not included)? I realize > that it takes a while to create the rendering of hidden lines with so > many iso-lines, but once it is drawn one would think the refresh in > gnuplot-x11 would be fairly fresh. An why would one think that? What made you think hidden3d would work faster on replots? > Yes, it has a lot of lines; but still, drawing lines shouldn't be so > slow. Drawing them isn't. Determining those that are not to be drawn is. |
|
From: Petr M. <mi...@ph...> - 2006-05-10 13:43:12
|
>> 4) In a related category would be contours. I wanted to force the >> contours to be all of the same color, in this case black. That doesn't >> seem possible. > > It is. "help set noclabel" Please think how to add this info into gnuplot's help. I've asked the same question some time ago. > I would: it's not needed. You have rand(), you have invnorm, that's all you > need. Also see 'stat.inc'. A candidate for being added into "help rand". --- PM |
|
From:
<br...@ph...> - 2006-05-10 14:23:47
|
Petr Mikulik wrote: >> It is. "help set noclabel" > > Please think how to add this info into gnuplot's help. I've asked the > same question some time ago. It already is. 'help set contour' mentions 'set clabel', and 'help set clabel explains' what it does. >> I would: it's not needed. You have rand(), you have invnorm, that's >> all you need. Also see 'stat.inc'. > A candidate for being added into "help rand". I don't thinks so. There's nothing to be gained from turning the gnuplot help into a generic maths textbook. |
|
From: Petr M. <mi...@ph...> - 2006-05-10 14:33:48
|
>>> It is. "help set noclabel" >> >> Please think how to add this info into gnuplot's help. I've asked the same >> question some time ago. > > It already is. 'help set contour' mentions 'set clabel', and 'help set > clabel explains' what it does. Yes, it mentions ... but that easy solution how to draw all them black is not evident -- then, example will help users a lot! >>> I would: it's not needed. You have rand(), you have invnorm, that's all >>> you need. Also see 'stat.inc'. > >> A candidate for being added into "help rand". > > I don't thinks so. There's nothing to be gained from turning the gnuplot > help into a generic maths textbook. Of course, but why not help users? --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-05-10 16:55:05
|
Petr Mikulik wrote: >>>> It is. "help set noclabel" >>> >>> >>> Please think how to add this info into gnuplot's help. I've asked the >>> same question some time ago. >> >> >> It already is. 'help set contour' mentions 'set clabel', and 'help >> set clabel explains' what it does. > > > Yes, it mentions ... but that easy solution how to draw all them black > is not evident -- then, example will help users a lot! > >>>> I would: it's not needed. You have rand(), you have invnorm, that's >>>> all you need. Also see 'stat.inc'. >> >> >>> A candidate for being added into "help rand". >> >> >> I don't thinks so. There's nothing to be gained from turning the >> gnuplot help into a generic maths textbook. > > > Of course, but why not help users? So long as the documentation is reasonably good (which isn't the case with clabel, I claim) and there are some demos illustrating the method, that is good enough in my mind. The prob3.dem I sent should illustrate both of the above. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-05-10 16:47:37
Attachments:
prob3-djs-10may2006.patch
|
Hans-Bernhard Br=F6ker wrote: >> 3) It sure is annoying going through the trouble of looking up in=20 >> "test" (x11) the number of the symbol desired, and then the symbol=20 >> comes out differently in the output file (png). =20 >=20 >=20 > Well, then don't. As it's said throughout engineering: test what you=20 > fly, not what is easy to test. There's no particularly strong reason=20 > not to optimize the plot directly in PNG format. This was actually some quirkiness in the PNG library, not a problem subst= ituting some symbol for another. Ethan has taken care of this. >=20 >> Actually, I'd think that the "linecolor", "pointtype" is an extraneous= =20 >> syntax. Couldn't it just be "points type 7 color rgb "black""? =20 >=20 >=20 > No, because that syntax would fail miserably in the case of 'with=20 > linespoints': what type does "type" address: that of the points, or tha= t=20 > of the lines? Good point. Couple things, not that it really matters too much. Is the = linespoints a special combination? Or is the combination of two things c= ontrollable independently? If the latter, an "and" would make sense, e.g= ., plot x with lines type 7 color rgb "raspberry" and points type 3 color rg= b "muave" If it is the latter, the parser could be written to recognize "points typ= e 7" as shorthand for "points pt 7"... at which point it is just getting = to be too many abbreviations, etc. So, eh. >=20 >> 4) In a related category would be contours. I wanted to force the=20 >> contours to be all of the same color, in this case black. That=20 >> doesn't seem possible. >=20 >=20 > It is. "help set noclabel" OHHHHHH! "unset clabel"!!! Having turned off the key, I guess it wasn't= that obvious that "clabel" that should be unset. This just isn't very o= bvious. >=20 >> 5) In the example, I really only want about 25 samples. IS THERE=20 >> SOME WAY TO CONTROL THIS? Setting the samples # doesn't seem to=20 >> effect this. =20 >=20 >=20 > You'll have to elaborate. Exact input, output, and a description why=20 > the output isn't what you wanted, please. The "table" option works fairly well. >=20 >> 6) Would anyone object to a patch for a math function "randn()"=20 >> generating unit variance normal distribution random values using the=20 >> Box-Mueller method? =20 >=20 >=20 > I would: it's not needed. You have rand(), you have invnorm, that's al= l=20 > you need. Well, yes that will work. (Should have occurred to me I guess.) How abo= ut including the attached prob3.dem in the demos somewhere. It will give= an example of generating non-uniform r.v.s, (none of the probability or = random demos actually seem to do that). It will also give an example of = monochrome contour lines. It also gives an example of using "table". Interestingly, your pointing this out made me search the web a bit more a= nd I found a discussion by Marsaglia on the Wolfram forums list where he = states some confusion surrounding the specific form of the polar techniqu= e attributed to him. Guess that shows the importance of going back to th= e original article. Anyway... >> Also see 'stat.inc'. Gee, I didn't even know that definition file existed. But what about the= contents of that file has to do with the invnorm() function or generatin= g r.v.s? >=20 >> 7) Anyone notice that the above example in the x11 terminal is rather= =20 >> slow refresh (even when the sample points are not included)? I=20 >> realize that it takes a while to create the rendering of hidden lines=20 >> with so many iso-lines, but once it is drawn one would think the=20 >> refresh in gnuplot-x11 would be fairly fresh. =20 >=20 >=20 > An why would one think that? What made you think hidden3d would work=20 > faster on replots? >=20 >> Yes, it has a lot of lines; but still, drawing lines shouldn't be so >> slow. >=20 >=20 > Drawing them isn't. Determining those that are not to be drawn is. No, not "replot", I used the word "refresh" on purpose implying resizing = the gnuplot-x11 window or anything that redraws it. One would think once= that series of lines are inside of gnuplot-x11's buffer (i.e., the gnupl= ot core has already figured out what lines are hidden, etc.) redrawing th= em shouldn't be too slow. Dan |
|
From:
<br...@ph...> - 2006-05-10 18:27:09
|
Daniel J Sebald wrote: > Hans-Bernhard Bröker wrote: >>> Actually, I'd think that the "linecolor", "pointtype" is an >>> extraneous syntax. Couldn't it just be "points type 7 color rgb >>> "black""? >> No, because that syntax would fail miserably in the case of 'with >> linespoints': what type does "type" address: that of the points, or >> that of the lines? > Good point. Couple things, not that it really matters too much. Is the > linespoints a special combination? It's a special combination. But you have the source, so you might take the exercise of finding that out yourself. Anyway: I seriously doubt that changing these aspects of the syntax now, 15+ years into the history of the program, is an acceptable option. > OHHHHHH! "unset clabel"!!! Having turned off the key, I guess it > wasn't that obvious that "clabel" that should be unset. This just isn't > very obvious. Feel free to suggest better wording for 'help contour', and/or a better alternative name for the option. > How about including the attached prob3.dem in the demos somewhere. It will > give an example of generating non-uniform r.v.s, (none of the > probability or random demos actually seem to do that). It will also > give an example of monochrome contour lines. It also gives an example > of using "table". Well, we have an example of 'table' already (the vectors demo goes through a table file), and 'help table' already points to the example in 'help contour', too. This example could reasonably be attached to random.dem. >>> Also see 'stat.inc'. > Gee, I didn't even know that definition file existed. But what about > the contents of that file has to do with the invnorm() function or > generating r.v.s? Nothing in particular. Just thought you should consider it before reinventing more wheels; and it does deal with normal distributions at least a bit. |
|
From: Daniel J S. <dan...@ie...> - 2006-05-12 00:12:45
|
Another observation: setting the seed of rand() is slightly clumsy, from what I see so far.
Certainly, it doesn't make sense to set the seed, e.g., rand(123), as part of a plot function because it will simply be drawing the same sample time and again. So, it seems that whenever rand() is used to seed the random number generator it should be on its own.
gnuplot doesn't accept "rand()" as a command. (Perhaps it should.) That means we need something like
notusedval = rand(123)
Correct?
Then there is a small technicality here, but it may be important from a community use standpoint. Looking at the code in specfun.c, I notice that ranf() called with a seed will 1) set the seed, then 2) draw a random sample starting from that seed.
So, if I understand this correctly, the command above
notusedval = rand(123)
after it is called will not have a seed of 123, but actually something different. OK, so someone says "Oh, you're using the such and such generator. Set the seed to X then draw 50 samples." But I can't do that. If I have to call rand(123) on its own and it draws a sample, the seed is no longer 123.
Take a look at these commands from Octave:
octave:2> rand(3)
ans =
0.96431 0.15260 0.54168
0.14526 0.66702 0.18013
0.47766 0.35227 0.73535
octave:3> rand("seed",123)
octave:4> rand("seed")
ans = 123.00
octave:5>
I'm not trying to say the Octave/gnuplot generators should be the same, but notice that rand() called when setting the seed apparently doesn't draw any samples and then showing the seed indicates, yes, the seed is currently 123.
Now, back to the syntax. Maybe seeding the generator should be something like
gnuplot> rand(123)
which does not draw a random sample but leaves the seed at 123, and
gnuplot> notusedval = rand(123)
should be an invalid command.
Dan
>> 6) Would anyone object to a patch for a math function "randn()"
>> generating unit variance normal distribution random values using the
>> Box-Mueller method?
>
>
> I would: it's not needed. You have rand(), you have invnorm, that's all
> you need. Also see 'stat.inc'.
|
|
From:
<br...@ph...> - 2006-05-12 01:13:55
|
Daniel J Sebald wrote: > Another observation: setting the seed of rand() is slightly clumsy, > from what I see so far. Not at all, IMHO. It does exactly what it says it does, with semantics following traditions of how rand() functions behave that go back at least to the C64 and the original IBM BASIC. > Certainly, it doesn't make sense to set the seed, e.g., rand(123), as > part of a plot function because it will simply be drawing the same > sample time and again. So, it seems that whenever rand() is used to > seed the random number generator it should be on its own. You can still do it from inside a plot command, because of the old, easily overlooked "inline assignment" feature: splot unused=rand(123), "data", invnorm(rand(0)) > gnuplot doesn't accept "rand()" as a command. (Perhaps it should.) If at all, that command would be "set random [.. some options ...]" > notusedval = rand(123) ... or you could use print rand(123) > after it is called will not have a seed of 123, but actually something > different. Since we make no promises whatsoever about the rand() algorithm, to "have a seed of 123" is quite completely meaningless anyway, so I really can't see what's there to worry about. I, for one, would be quite surprised by a PRNG that returned the seed I set as the next random number, instead of using it to replace the state that the previous call left the PRNG in. rand(123) is a *function*, not a command, and I'm going to have to insist that it stays that way. |
|
From: Daniel J S. <dan...@ie...> - 2006-05-12 02:25:07
|
Hans-Bernhard Br=F6ker wrote:
>> gnuplot doesn't accept "rand()" as a command. (Perhaps it should.) =20
>=20
>=20
> If at all, that command would be "set random [.. some options ...]"
[snip]
> Since we make no promises whatsoever about the rand() algorithm,
Well, it depends. Here is what the gnuplot code says:
This is a transcription from Pascal to Fortran of routine
Uniform_01 from the paper
L'Ecuyer, P. and Cote, S. "Implementing a Random Number Package
with Splitting Facilities." ACM Transactions on Mathematical
Software, 17:98-111 (1991)
Now, as a means of verifying, I would assume the original author tested o=
ut some numbers against what the routine was producing as programmed else=
where, or listed in the paper perhaps.
If the algorithm is as stated in the paper and checks out, why not make t=
he promise, within the limites of GNU/freeware promises, that is?
> to=20
> "have a seed of 123" is quite completely meaningless anyway, so I reall=
y=20
> can't see what's there to worry about.
Setting the seed of a random number generator is meaningless? Then why h=
ave the capability? The obvious use is to verify an algorithm or plot ag=
ainst some other result elsewhere. Researchers do that sort of thing qui=
te a bit, I would think. Cryptography perhaps being an example? Here's =
something going back to the days of Atari about setting the seed the same=
as your friends:
http://www.atarimagazines.com/creative/v9n5/178_Basic_cryptography_SBOEP.=
php
Say we wanted "all.dem" to produce the same exact plots no matter how it =
was run. We might reseed the PRNG at the beginning of the all.dem file.
I, for one, would be quite=20
> surprised by a PRNG that returned the seed I set as the next random=20
> number, instead of using it to replace the state that the previous call=
=20
> left the PRNG in.
No, the seed and what the PRNG return are two different things. My issue=
is that, yes, the gnuplot PRNG is replacing the state of the PRNG but th=
en it immediately generates a random number that *can't be used*. Is tha=
t how C64 and IBM BASIC worked? I.e.,
unused =3D rand(678)
does not set the seed to 678. It sets it to whatever the seed is that fo=
llows 678.
splot unused=3Drand(123), "data", invnorm(rand(0))
doesn't solve that issue.
> rand(123) is a *function*, not a command, and I'm=20
> going to have to insist that it stays that way.
That's fine. The syntax you suggest above would be preferred, i.e., "set=
seed 789765" or something.
Dan
|
|
From:
<br...@ph...> - 2006-05-12 02:39:13
|
Daniel J Sebald wrote: >> Since we make no promises whatsoever about the rand() algorithm, > > Well, it depends. Here is what the gnuplot code says: What the source code says is quite irrelevant. The manual is where the contract with the users is made. As long as the manual doesn't say how rand() works, any assumption users make about that subject are wrong by default. > If the algorithm is as stated in the paper and checks out, why not make > the promise, within the limites of GNU/freeware promises, that is? Because a promise automatically creates a liability to keep that promise forever. One of gnuplot's strongest points has always been script compatibility. Gnuplot-4.0 will still run pretty much any sane plot script that worked for version 3.2, with only very few, *well* motivated exceptions. > Setting the seed of a random number generator is meaningless? No. But what the actual number you specify as the seed will mean, is completely undefined. On purpose. > against some other result elsewhere. Researchers do that sort of thing > quite a bit, I would think. Cryptography perhaps being an example? Nobody in a remotely sane state of mind would use a plain vanilla rand() function like gnuplot's for cryptography. > No, the seed and what the PRNG return are two different things. You did seem to like Octave's behaviour though, which returned the seed as the next random number... > issue is that, yes, the gnuplot PRNG is replacing the state of the PRNG > but then it immediately generates a random number that *can't be used*. That number is just as pseudo-random as any other one coming out of the PRNG. And rand() being a function, it must return some value --- what else should that be? > unused = rand(678) > > does not set the seed to 678. It sets it to whatever the seed is that > follows 678. No. Certainly not in gnuplot, because 678 can never be the output of our rand(), so there's no such thing as "the seed that follows" it. A seed in a PRNG must do exactly one thing: the PRN sequences after seeding it with the same number must be equal. That's *all* you can rely on in a seed. Seed numbers have no meaning --- for all practical mans and purposes, they're no more meaningful than the non-area part of a telephone number. |
|
From: Daniel J S. <dan...@ie...> - 2006-05-12 03:28:46
|
Hans-Bernhard Br=F6ker wrote:
>> against some other result elsewhere. Researchers do that sort of=20
>> thing quite a bit, I would think. Cryptography perhaps being an=20
>> example? =20
>=20
>=20
> Nobody in a remotely sane state of mind would use a plain vanilla rand(=
)=20
> function like gnuplot's for cryptography.
I've seen a lot of insane stuff in my day. :-)
>=20
>> No, the seed and what the PRNG return are two different things. =20
>=20
>=20
> You did seem to like Octave's behaviour though, which returned the seed=
=20
> as the next random number...
No. Here:
octave:1> rand("seed",456)
octave:2> rand(1)
ans =3D 0.39089
octave:3> rand("seed",456)
octave:4> rand("seed")
ans =3D 456.00
octave:5> rand(1)
ans =3D 0.39089
The "seed" just means "show me the seed" in case I run some experiment an=
d want to know what the seed is before I start, in case I want to come ba=
ck to that.
[This is all hindsight. Don't read on if you've had enough.]
You see, the point I'm trying to make is that I've got a feeling that imp=
lementations of random number generators may historically not produce any=
kind of random value related to modifying or showing the seed.
For example, there is the Octave behavior. From some C literature is:
"srand" sets the "seed" for a pseudo-random number generator. Once the se=
ed has been set, you may call "rand" to obtain pseudo-random numbers.
>=20
>> issue is that, yes, the gnuplot PRNG is replacing the state of the=20
>> PRNG but then it immediately generates a random number that *can't be=20
>> used*. =20
>=20
>=20
> That number is just as pseudo-random as any other one coming out of the=
=20
> PRNG. And rand() being a function, it must return some value --- what=20
> else should that be?
rand() being a function as gnuplot defines functions. Mathematically it'=
s not a function. The argument should be meaningless. There should be n=
o rand(-1), rand(x>1), rand({,}) but maybe instead
set seed (standard value)
unset seed (same as set seed)
set seed # (for x>0 sets both seeds to a value based on the value of x=
)
set seed #,# (for x>0 sets seed1 to x and seed2 to y)
>=20
>> unused =3D rand(678)
>>
>> does not set the seed to 678. It sets it to whatever the seed is that=
=20
>> follows 678.
>=20
>=20
> No. Certainly not in gnuplot, because 678 can never be the output of=20
> our rand(),
The seed and the output are two different things.
> so there's no such thing as "the seed that follows" it.
Let n be the index of sequence seed(n) =3D {seed1(n),seed2(n)}. Then in =
code:
/* Generate pseudo random integers */
k =3D seed1 / 53668L;
seed1 =3D Xa1 * (seed1 - k * 53668L) - k * 12211;
if (seed1 < 0)
seed1 +=3D Xm1;
k =3D seed2 / 52774L;
seed2 =3D Xa2 * (seed2 - k * 52774L) - k * 3791;
if (seed2 < 0)
seed2 +=3D Xm2;
which means seed(n+1) =3D f(seed(n)).
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-05-12 03:30:13
|
On Thursday 11 May 2006 07:33 pm, Daniel J Sebald wrote:
>
> Well, it depends. Here is what the gnuplot code says:
>
> This is a transcription from Pascal to Fortran of routine
[...]
The fact that this comment is in a C program doesn't bother you?
> Setting the seed of a random number generator is meaningless?
> Then why have the capability?
So that you can reproduce a previous run, if necessary.
> Say we wanted "all.dem" to produce the same exact plots no matter how it was run.
Then we would not use random numbers.
> No, the seed and what the PRNG return are two different things.
> My issue is that, yes, the gnuplot PRNG is replacing the state of the
> PRNG but then it immediately generates a random number that *can't be used*.
I have no idea what you mean by that. Random number generators oftern
produce intermediate values that are never seen by the caller. So what?
> unused = rand(678)
>
> does not set the seed to 678. It sets it to whatever the seed is that follows 678.
That statement makes no sense at all.
The seed is set to some internal value that is reproducibly generated
by calling rand(678). That's all you need to know. If you call
rand(678) again next week, you will be setting the same seed.
In fact you *can* set the full 64 bits of the seed to something
in particular if you want to. This is even documented:
`rand(0)` returns a pseudo random number in the interval [0:1] generated
from the current value of two internal 32-bit seeds.
`rand({x,y})` for x>0 sets seed1 to x and seed2 to y
Note that rand(678) is not an example of this, since 678 is not a
complex number. But since the documentation does not say what those
two internal seeds will be used for, the reader is really no wiser than before.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2006-05-12 03:56:54
|
Ethan A Merritt wrote:
> On Thursday 11 May 2006 07:33 pm, Daniel J Sebald wrote:
>
>>Well, it depends. Here is what the gnuplot code says:
>>
>> This is a transcription from Pascal to Fortran of routine
>
> [...]
>
> The fact that this comment is in a C program doesn't bother you?
Sort of. But not too much, so long as someone tested it.
> In fact you *can* set the full 64 bits of the seed to something
> in particular if you want to. This is even documented:
>
> `rand(0)` returns a pseudo random number in the interval [0:1] generated
> from the current value of two internal 32-bit seeds.
> `rand({x,y})` for x>0 sets seed1 to x and seed2 to y
>
> Note that rand(678) is not an example of this, since 678 is not a
> complex number.
From doc:
`rand(x)` for x>0 sets both seeds to a value based on the value of x.
> But since the documentation does not say what those
> two internal seeds will be used for, the reader is really no wiser than before.
:-) Come on, this is getting to be semantics now. Perhaps the documentation should be one of the following two to get rid of the confusion.
1) rand({x,y})` for x>0 sets seed1 to x and seed2 to y, then generates a random number (which you can't really make much use of in a data stream) so that seed1 and seed2 become some other values.
This one can stay as it makes no promises in its wording:
`rand(x)` for x>0 sets both seeds to a value based on the value of x.
"a value based on" is sort of like "some people believe" (i.e., "this may not be factual"). So it is implying that seed1 = seed2 = x should be the result, but sure it could be interpreted as "it is whatever it is". Which leads to...
2) `rand(x)` for x>0 puts the PRNG in a known state
`rand({x,y})` for x>0 puts the PRNG in a known state
Why go through the trouble of pointing out "seed1", "seed2" or "both seeds" in the documentation if it isn't accurate?
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-05-12 06:59:03
|
Daniel J Sebald wrote: > No, the seed and what the PRNG return are two different things. My > issue is that, yes, the gnuplot PRNG is replacing the state of the PRNG > but then it immediately generates a random number that *can't be used*. > Is that how C64 and IBM BASIC worked? I.e., I just looked up BASIC (if this is different from IBM BASIC, I'm not sure): http://www.leinweb.com/basic/manual/man1/rnd.func.htm http://msdn2.microsoft.com/en-us/library/f7s023d2.aspx Which has the ability to set the seed using randomize: http://www.leinweb.com/basic/manual/man1/randomize.stmt.htm http://msdn2.microsoft.com/en-us/library/8zedbtdt.aspx So BASIC is a case where one can set the seed with randomiz() and not draw a sample immediately. Similar to Octave. Similar to C. But looking closer at the "rnd" routine of BASIC, oddly there is also a way to set the seed using the single argument. (Did this "randomize" come later or something?) So BASIC does this < 0, > 0, = 0 skullduggery as well. But it isn't exactly the same as gnuplot. For < 0, BASIC generates a value from the seed. (But it says nothing about advancing the generator.) For > 0, the result is next pseudo r.n. in sequence. For = 0, the result is the most recently generated value. (Again, it says nothing about advancing the generator.) So what happens in BASIC with rnd(-1) rnd(0) rnd(0) ? Same value for first two uses of rnd(), then a different value for the third use of rnd()? Well, is gnuplot in the tradition of BASIC? Sort of. I'd bow to someone knowledgable in PRNG who could say gnuplot should behave as such and explain why, but I don't see the consistency with most conventional PRNGs on the matter. I don't know. Put me in the unset seed set seed # set seed #,# show seed camp, for what it's worth. Dan |
|
From:
<br...@ph...> - 2006-05-10 18:37:42
|
Now, as to the proposed prob3.dem itself.
First off, this really should go into random.dem. It doesn't really
need yet another .dem file of its own.
+# demo for showing use of normal random numbers
+
+# Prepared by Dan Sebald
+# History:
+# - 5.10.2006 ds: 1st version
^^^^^^^^^
Your calendar's off ;-)
+set parametric
+set isosamples 25,2
+set samples 25
+set table "temp.dat"
+splot invnorm(rand(0)),invnorm(rand(0)),invnorm(rand(0))
+unset table
Looks like abuse of splot to me. You generate 3 columns, but only use 2
below.
set samples 25
set table 'temp.dat'
plot invnorm(rand(0)), invnorm(rand(0))
unset table
|
|
From: Daniel J S. <dan...@ie...> - 2006-05-10 19:46:04
Attachments:
random-djs-10may2006.patch
|
Hans-Bernhard Br=F6ker wrote:
> Now, as to the proposed prob3.dem itself.
>=20
> First off, this really should go into random.dem. It doesn't really=20
> need yet another .dem file of its own.
I agree. The prob.dem, prob2.dem doesn't really use the random data func=
tion. It's more just plotting distributions and densities. Inside rando=
m.dem would be good.
>=20
> +# demo for showing use of normal random numbers
> +
> +# Prepared by Dan Sebald
> +# History:
> +# - 5.10.2006 ds: 1st version
> ^^^^^^^^^
>=20
> Your calendar's off ;-)
It's always off. :-)
>=20
> +set parametric
> +set isosamples 25,2
> +set samples 25
> +set table "temp.dat"
> +splot invnorm(rand(0)),invnorm(rand(0)),invnorm(rand(0))
> +unset table
>=20
> Looks like abuse of splot to me. You generate 3 columns, but only use =
2=20
> below.
True, but doesn't reall hurt anything. I used
set samples 50
plot invnorm(rand(0)),invnorm(rand(0))
to create just two columns. However, when plotting with splot the follow=
ing notice appears:
Notice: cannot contour non grid data!
It's innocuous, so big deal I guess.
How about the change to:
splot invnorm(rand(0)),invnorm(rand(0)),-0.2
and make use of the third column by ridding the need for "using 1:2:(-0.2=
)"?
I've made that change in the attached version.
Also in the attached file is a histogram binning example for Gaussian dat=
a. Is that one of any use? (I think I sort of understand histeps now.) =
It's basically a generalization of what is already inside "steps.dem". =
Not really anything new I guess.
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-05-10 21:44:12
|
On Wednesday 10 May 2006 12:54 pm, Daniel J Sebald wrote: > Also in the attached file is a histogram binning example for > Gaussian data. Is that one of any use? The plot itself is not explained (no key, no titles, no labels), and to the naive user (me) it looks like the two curves do not match. Plot error? Code error? It doesn't help any that the x-axis tic labels do not line up with the actual tic marks. If I reset and replot at the end of the demo, they seem to sort themselves out, but something in the sequence of demo commands is breaking the axis labeling. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Daniel J S. <dan...@ie...> - 2006-05-11 03:01:08
|
Ethan Merritt wrote: > On Wednesday 10 May 2006 12:54 pm, Daniel J Sebald wrote: > > >>Also in the attached file is a histogram binning example for >>Gaussian data. Is that one of any use? > > > The plot itself is not explained (no key, no titles, no labels), > and to the naive user (me) it looks like the two curves do not > match. Plot error? Code error? Yeah, I suppose this one could use a key. > > It doesn't help any that the x-axis tic labels do not > line up with the actual tic marks. If I reset and replot at > the end of the demo, they seem to sort themselves out, but > something in the sequence of demo commands is breaking the > axis labeling. Oh wow, how did that happen? I didn't even look that closely at the axes. Let me look at this a bit, Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-05-11 04:09:41
Attachments:
random-djs-10may2006-2.patch
|
Ethan Merritt wrote: Updated patch. (Now uses sprintf() for titles... very useful.) > The plot itself is not explained (no key, no titles, no labels), > and to the naive user (me) it looks like the two curves do not > match. Plot error? Code error? In this version I used "steps" as opposed to "histeps" (after looking closely at "steps.dem"). This looks better. I still don't fully grasp the "steps" paradigm, but these three steps examples in steps.dem appear to do a very similar thing, the x-alignment being the apparent difference. Given that, one wishes for a better syntax like "lhist", "chist", "rhist". Anyway... The key strings are "scaled bin frequency" "Gaussian p.d.f." The first string means the random data is binned and the frequency of occurance of the r.v. outcome landing in that bin is scaled in such a way that the histogram should converge to the normal probability distribution function with increasing number of samples used in the simulation. Hey, I noticed something strange, if the line , normal(x) with lines title "Gaussian p.d.f." is instead just , normal(x) title "Gaussian p.d.f." the green line doesn't show up in the key. Is that the way it is supposed to behave? > > It doesn't help any that the x-axis tic labels do not > line up with the actual tic marks. That had to do with the "set format <>". I set set format "%8.5g" in order to get adequate resolution in the data file generated using "table". Having that format still set caused the tick mark text to be a wide string with the value to the far right (and the rest space characters). This could be done better in gnuplot, but I'm not concerned about that right now. I just set the format back to the default before plotting. > If I reset and replot at > the end of the demo, they seem to sort themselves out, but > something in the sequence of demo commands is breaking the > axis labeling. Please check if this behaves better. Dan |
