gnuplot-beta — Developers and beta testers of new gnuplot code

Re: various observations (added to list)

[Ethan A M. <merritt@u.washington.edu>]

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

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

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

Re: fit_control and splot_overview

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> Do "fit_control" and "splot_overview" really need to be subtopics of=20
>> "commands"?  Can't these just reside under the help for "fit" and=20
>> "splot"?
>=20
>=20
> On what platform, i.e. in which help format?  We have about half a=20
> dozen, you know...

I didn't know there was such variation.  Linux (Fedora 3).

Perhaps this was just an oversight (see patch) when someone cleaned up th=
e documentation.  (However, having an splot_overview as a subcategory of =
splot, as the patch changes to, doesn't make much sense.)

Dan

Re: various observations (added to list)

[<br...@ph...>]

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.

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

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

Re: fit_control and splot_overview

[<br...@ph...>]

Daniel J Sebald wrote:
> Do "fit_control" and "splot_overview" really need to be subtopics of 
> "commands"?  Can't these just reside under the help for "fit" and "splot"?

On what platform, i.e. in which help format?  We have about half a 
dozen, you know...

Re: various observations (added to list)

[<br...@ph...>]

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.

fit_control and splot_overview

[Daniel J S. <dan...@ie...>]

Do "fit_control" and "splot_overview" really need to be subtopics of "commands"?  Can't these just reside under the help for "fit" and "splot"?

Dan

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

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'.

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>>Were you instead attempting to take the executed result of 
>>/bin/true (a 1) and place it in the input stream 100 times?
> 
> 
> Yes, and you are correct that the piped command I gave
> doesn't really do that.  So my piped command was garbage.
> But hey, it worked anyhow.  I really did test it; I just
> didn't spend enough time thinking about *why* it worked.
> OK, scratch that kludge. My overly-hasty mistake.

That magic happens some time.  Perhaps your /bin/true is a script file and doesn't have any non-ascii values.  Not important.

> 
> I think the idea of an in-line "isosamples NEWVAL" in the
> plot command is reasonable, but hardly a high priority item.
> I'd rather focus on bug-fixes.

I agree, the file-based kludge I can live with since there are several demos using rand() based off a file.

What would give the in-line isosamples more weight would be placing it in a larger context, not just for the purpose of solving this problem, which would be to have two surfaces with different grid sampling.  Now is that something worthwhile?  The choice of isosamples has something to do with the spatial frequency content of the plot.  A planar surface doesn't need a large number of isosamples, whereas other surfaces might.  So perhaps having multiple surfaces would warrant that (e.g., a plane cutting through another surface).

However, would two meshes of differing isosamples be a bad visual effect?

The latest attached patch is what I will offer up for now.  Rather than put the rand(0) in the plot command, I've used the datafile approach.  I acknowledge regenerating new data with the replot command is cool, but the reason to go with the former for now is that technically there is nothing wrong with the "put data in file then use that data in file" approach in principle (other than Notice: cannot contour non grid data!).  I've isolated the egregious method with comment, i.e.:

# A somewhat inelegant way of generating N random data points.  A future
# non-pressing plot-command feature addition may address this issue.
set parametric
set samples nsamp
set format "%8.5g"
set table "temp.dat"
plot invnorm(rand(0)),(1.0*scale/nsamp)
unset table
unset format
#


Dan

Re: various observations (added to list)

[Ethan M. <merritt@u.washington.edu>]

On Thursday 11 May 2006 10:47 am, you wrote:
> Ethan Merritt wrote:
> > On Thursday 11 May 2006 09:37 am, Daniel J Sebald wrote:
> >>Neither "<head -100 /bin/true" nor the above work.
> >
> > Works for me.  I tried it out before suggesting it.
>
> Were you instead attempting to take the executed result of 
> /bin/true (a 1) and place it in the input stream 100 times?

Yes, and you are correct that the piped command I gave
doesn't really do that.  So my piped command was garbage.
But hey, it worked anyhow.  I really did test it; I just
didn't spend enough time thinking about *why* it worked.
OK, scratch that kludge. My overly-hasty mistake.

I think the idea of an in-line "isosamples NEWVAL" in the
plot command is reasonable, but hardly a high priority item.
I'd rather focus on bug-fixes.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Thursday 11 May 2006 09:37 am, Daniel J Sebald wrote:
> 
>>Neither "<head -100 /bin/true" nor the above work.
> 
> 
> Works for me.  I tried it out before suggesting it.

I'm not a unix guru.  What is this pipe command attempting to do?  The "head" command displays the first hunk of a file.  So this attempts to print the first hunk of the file /bin/true?  (I don't see an option for head of "-#".)  That doesn't make sense.  Were you instead attempting to take the executed result of /bin/true (a 1) and place it in the input stream 100 times?

Dan

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:

> The 'natural' way of doing this plot would be something like
>=20
> set parametric
> plot u,v,norm2d(u,v) filter contour(levels=3D5) with lines, \
>      invnorm(rand(0)),invnorm(rand(0)),-0.2 isosamples 5000,1 w p
>=20
> We're erecting quite a pile of kluges and tricks to emulate this=20
> non-existing command.

Call it sifting and winnowing... or better yet, the scientific process.

So isosamples embedded in the command is the new concept here.  I could l=
ive with that.

Dan

Re: various observations (added to list)

[Ethan M. <merritt@u.washington.edu>]

On Thursday 11 May 2006 09:37 am, Daniel J Sebald wrote:
>
> Neither "<head -100 /bin/true" nor the above work.

Works for me.  I tried it out before suggesting it.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: various observations (added to list)

[<br...@ph...>]

Daniel J Sebald wrote:

>> Second because I see no sane reason why, to achieve a per-dataset 
>> choice of sampling rate for *function* plots, we should be mucking 
>> around with *data* file handling like that.

> Good thing to consider, but the idea is to keep the two independent.  

So let's not make data file handling any stranger just to add a feature 
found missing in function plotting.

> The 1D/2D p.d.f. is the function plot, the random points to plot are a 
> "data file".  

Only because treating them as function wouldn't work in this particular 
case.

They're a data file only because plotting the parametric function 
(rand(), rand(), -0.2) doesn't give you the right number of samples in a 
combined plot with some other function.

The 'natural' way of doing this plot would be something like

set parametric
plot u,v,norm2d(u,v) filter contour(levels=5) with lines, \
      invnorm(rand(0)),invnorm(rand(0)),-0.2 isosamples 5000,1 w p

We're erecting quite a pile of kluges and tricks to emulate this 
non-existing command.

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> Perhaps we could dream up a syntax for controlling the number of=20
>> points without an obvious kluge or limitation to the number of grid=20
>> points.  How about a "phantom" points idea as follows:
>>
>> plot '-#' ...
>>
>> where # is replaced by an integer? =20
>=20
>=20
> No. First because this is unnecessary, at least on pipe-capable platfor=
ms:
>=20
>     plot "< head -5000 /dev/zero" u {rand(0)):(rand(0))

Neither "head -100 /bin/true" nor the above work.  /bin/true spits out a =
bunch of binary data that gnuplot can't interpret.  /dev/zero creates an =
empty file.


>     plot "< seq 5000" u (rand(0)):(rand(0))

This works.  (We can't use this in demo scripts.  Right?)

>=20
> Second because I see no sane reason why, to achieve a per-dataset choic=
e=20
> of sampling rate for *function* plots, we should be mucking around with=
=20
> *data* file handling like that.

Good thing to consider, but the idea is to keep the two independent.  The=
 1D/2D p.d.f. is the function plot, the random points to plot are a "data=
 file".  If one changes his or her prespective, we might say that using r=
and(0) tied to the grid sampling is the kluge.  I mean, that isn't exactl=
y a solid concept in terms of application... unless say the way Ethan is =
using it in his variable_rgb.dem example where the random part is actuall=
y another dimension (i.e., dot size and/or color).

Dan

Re: various observations (added to list)

[<br...@ph...>]

Daniel J Sebald wrote:

> Perhaps we could dream up a syntax for controlling the number of points 
> without an obvious kluge or limitation to the number of grid points.  
> How about a "phantom" points idea as follows:
> 
> plot '-#' ...
> 
> where # is replaced by an integer?  

No. First because this is unnecessary, at least on pipe-capable platforms:

	plot "< head -5000 /dev/zero" u {rand(0)):(rand(0))

or

	plot "< seq 5000" u (rand(0)):(rand(0))

Second because I see no sane reason why, to achieve a per-dataset choice 
of sampling rate for *function* plots, we should be mucking around with 
*data* file handling like that.

Re: various observations (added to list)

[Ethan M. <merritt@u.washington.edu>]

On Thursday 11 May 2006 08:54 am, Daniel J Sebald wrote:
> Perhaps we could dream up a syntax for controlling the number of
> points without an obvious kluge or limitation to the number of grid
> points.  How about a "phantom" points idea as follows:
>
> plot '-#' ...
>
> where # is replaced by an integer?

In the "obvious kluge" category:

  plot '< head -100 /bin/true' using (func(0)):(func(0))

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> Ethan A Merritt wrote:
>=20
>=20
>>> Also I think it would neat if you can manage to jam the generation
>>> of the samples into the actual plot command so that "replot" will
>>> resample rather than simply redrawing the previous sampling.
>=20
>=20
> This would of course collide rather badly with the fact that 'contour'=20
> is a modal setting, rather than a per-plot data filter.  So it's hard t=
o=20
> keep 'set contour' from trying to contour the random scatter without an=
=20
> external data file.  One could of course just abuse an existing,=20
> non-gridded data file instead of creating one on-the-fly --- the bigges=
t=20
> eligible one would be world.dat, which contains ~1000 data points.

Eh, part of the purpose of the dem files is to give the user an idea of t=
he proper way to use gnuplot.  Both methods are an abuse; I'd estimate on=
-the-fly to be slightly less abusive.

Perhaps we could dream up a syntax for controlling the number of points w=
ithout an obvious kluge or limitation to the number of grid points.  How =
about a "phantom" points idea as follows:

plot '-#' ...

where # is replaced by an integer?  And if ever there is a problem where =
the using string requires an actual file or manual entry, gnuplot complai=
ns.  For an example,

plot '-5000' using (rand(0)):(rand(0)) ...

would work, but not

plot '-5000' using 1:(rand(0)) ...

at which point gnuplot says "Must have actual data for non-phantom using =
elements" (or something).

One of the examples in random.dem might be:

plot sprintf("-%d",nsamp) using (bin(invnorm(rand(0)))):(1.0*scale/nsamp)=
 smooth frequency with steps title "scaled bin frequency", normal(x) with=
 lines title "Gaussian p.d.f."

(I just verified that sprintf works for the file name part of the command=
.)

Dan

Re: various observations (added to list)

[<br...@ph...>]

Daniel J Sebald wrote:
> Ethan A Merritt wrote:

>> Also I think it would neat if you can manage to jam the generation
>> of the samples into the actual plot command so that "replot" will
>> resample rather than simply redrawing the previous sampling.

This would of course collide rather badly with the fact that 'contour' 
is a modal setting, rather than a per-plot data filter.  So it's hard to 
keep 'set contour' from trying to contour the random scatter without an 
external data file.  One could of course just abuse an existing, 
non-gridded data file instead of creating one on-the-fly --- the biggest 
eligible one would be world.dat, which contains ~1000 data points.

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:
> 
> Ethan A Merritt wrote:
> 
>> Also I think it would neat if you can manage to jam the generation
>> of the samples into the actual plot command so that "replot" will
>> resample rather than simply redrawing the previous sampling.
>> Similar to the plots in rgb_variable.dem. 
> 
> 
> Well, I can.  But I know what Hans will say.  If instead of
> 
>  "temp.dat" with points
> 
> in the splot command, we have
> 
>  "temp.dat" using (invnorm(rand(0))):(invnorm(rand(0))):(-0.2)
> issuing replot will create a new set of outcomes.  In other words, data 
> was put in "temp.dat" for the sole purpose of setting the number of 
> points in the random data set create at the plot command.  The data 
> itself inside "temp.dat" is not used.

Actually, if one does this sort of approach, the generated data could be written in very compact form as:

set format "%0.0f"
set table "temp.dat"
plot 0,0
#plot invnorm(rand(0)),(1.0*scale/nsamp)
unset table
unset format

and every point inside the file looks like:

#Curve 0 of 1, 5000 points
#x y type
0 0  i
0 0  i
...

The data isn't used, but it averages to only a few characters per number, eventually replaced by a random value when read in.  I know, it's a kluge... but I could live with it if others could.

Dan

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

> Also I think it would neat if you can manage to jam the generation
> of the samples into the actual plot command so that "replot" will
> resample rather than simply redrawing the previous sampling.
> Similar to the plots in rgb_variable.dem. 

Well, I can.  But I know what Hans will say.  If instead of

  "temp.dat" with points

in the splot command, we have

  "temp.dat" using (invnorm(rand(0))):(invnorm(rand(0))):(-0.2) 

issuing replot will create a new set of outcomes.  In other words, data was put in "temp.dat" for the sole purpose of setting the number of points in the random data set create at the plot command.  The data itself inside "temp.dat" is not used.

Hans?  :-)


> One an unrelated note - have you noticed that SourceForge has
> now lost the developer cvs setup as well?  Close to total meltdown.

Ouch!  That's not good.  :-(

Dan

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

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

Re: various observations (added to list)

[Daniel J S. <dan...@ie...>]

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

Re: various observations (added to list)

[Ethan M. <merritt@u.washington.edu>]

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