gnuplot-beta

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

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)

[<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...>]

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)

[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)

[<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)

[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:

>> 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:

> 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)

[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)

[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:

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