Re: various observations

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

Ethan Merritt wrote:
 
>>The x-y plane position seems slightly limited.  
> 
> 
> Works fine for me.
> 
> 
>>The axes would remain the same and the x-y plane would extend off the plot, 
>>which just seemed silly.     


Somehow I generated an x-y plane which landed outside the plot area.  Can't seem to reproduce that now.

> 
> 
> ???
> I don't understand.  You set the intersection of the plane with
> the Z axis at -0.2, and that's where it is drawn.  What did you expect?

No, initially I tried something like "set xyplane 0.7" or something.

> 
> 
>>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?)
> 
> 
> Um. I don't know. For me the z-axis extends to span the range
> currently set by "set zrange".  That has nothing in particular
> to do with where the xyplane is currently set.

Well, that seems to work as expected, i.e., the range as described by the little tic marks.  It's that "x-y plane drop down line", and oddly only for the one on the z-axis.  The other three are the correct length.

> 
>>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).
> 
> 
> User error.  
> If you want to know what the png symbols look like, 
> test them with the png driver.
> 
> 
>>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").
> 
> 
> That's just because of the limited resolution.
> I don't think we can do anything about that.

Oy, this is a PNG thing.  Take a look at the difference between these plots.

set term png
set output 'plot.png'
plot x**2 with points pointtype 7 linecolor rgb "black"
set output 'plot2.png'
plot x**2 with points pointtype 7
set output

When PNG has a dot as the same color as a line or point it lands on, the dot is drawn hollow.  Not sure how that helps the visual effect.

>>Also, is it OK to use "linecolor rgb "black" to control symbol color as I did?
> 
> Sure, if you want.  Or "lt -1".

Actually, lt -1 is a black line with a thickness greater than usual.  The surface plots look bad with such a thick line.

> 
> 
>>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.  
> 
> 
> Yes it is. You just have to specify a specific color (lc rgb "blue")
> rather than a linetype.  If you give a linetype, it autoincrements
> as it draws each contour.

I can't seem to do this.  I see in "show cntrparam" that

        contour line types are varied & labeled with format '%8.3g'

suggesting that line types can be controlled.  But the documentation doesn't show how to set this.  Hmm, this seems to fall under "clabel".  Why would color be under that?  Anyway, the documentation says

 The first contour linetype, or only contour linetype when clabel is off, is
 the surface linetype +1; contour points are the same style as surface points.

but again no indication of how to change that behavior.  Would it be either of these:

set cntrparam linear lc rgb "black"
set clabel '' lc rgb "black"

This might be a good thing to add to "contours.dem".

> 
> 
>>5)  In the example, I really only want about 25 samples.  
>>IS THERE SOME WAY TO CONTROL THIS?
> 
> 
> set isosamples 25, 25

This causes a surface with isolines of 25 by 25.  Well, I meant that I want to have the higher resolution isolines (60), but only 25 outcomes of a multivariate Gaussian.  But I gather that this works by generating a random value for every point in the grid, i.e., 25 x 25 points.  Now, that behavior is one I would say makes the rand function (at least on its own) really only good for demos...  Oh, hold on here...

OK, it can be done.  The "table" method will allow first creating the random data in a file than reading it back.  This just about does it:

set hidden3d
set contour
set view 68, 28, 1, 1
unset key
unset title
set cntrparam levels discrete 0.1 lc rgb "black"
set style line 1 linecolor rgb "black"
set term x11 2
set parametric
set xrange [-4:4]
set yrange [-4:4]
set zrange [-0.2:0.2]
set urange [-4:4]
set vrange [-4:4]
set xyplane 0
set isosamples 5,5
set table "temp.dat"
splot sqrt(-2*log(rand(0)))*cos(2*pi*rand(0)),sqrt(-2*log(rand(0)))*sin(2*pi*rand(0)),-0.2
unset table
set isosamples 60
splot u,v,( 1/(2*pi) * exp(-0.5 * (u**2 + v**2)) ) with line ls 1, \
   "temp.dat" with points pointtype 7 linecolor rgb "black"

> 
> 
>>6)  Would anyone object to a patch for a math function "randn()" 
>>generating unit variance normal distribution random values using 
>>the Box-Mueller method?  
> 
> 
> Other than generating demo plots, is there really a need?

Sure.  I want to generate a plot illustrating a Gaussian mixture model, which means a lengthy polar transform equation for each of the components of the mixture.  It's far fetched that someone would use gnuplot for simulations.  But for quickly generating little illustrations in physics, communications, stats, etc. Gaussian distributions pop up fairly often.

Dan