Re: various observations (added to list)

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

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