|
From: Daniel J S. <dan...@ie...> - 2006-05-10 00:56:57
|
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
|