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

Re: wxWidgets terminal commited

[Lars H. <lhe...@us...>]

Timoth=E9e Lecomte writes:
> Dear gnuplot developpers,
>=20
> After 11 months of development, the wxWidgets has landed to the CVS ! (=
I
> hope I did not make any mistake by the way)
=20
 Timoth=E9e,

 I'm trying to repair the build system after this commit. There are two
 issues:

| dnl Check for object files creation, needed to build these object files=
 in subdirs
| AM_PROG_CC_C_O

 This is not what AM_PROG_CC_C_O does. It is a wrapper for AC_PROG_CC_C_O=
:

|     If the C compiler does not accept the `-c' and `-o' options
|     simultaneously, define `NO_MINUS_C_MINUS_O'.  This macro actually
|     tests both the compiler found by `AC_PROG_CC', and, if different,
|     the first `cc' in the path.  The test fails if one fails.  This
|     macro was created for GNU Make to choose the default C compilation
|     rule.

 It's not needed. Can I remove it?

 Number two: if no wxWidgets are installed, the result for $WX_CONFIG is =
"no",
 and configure then tries to run the command "no". I have changed the log=
ic.

 if test $WX_CONFIG
 ...
 fi
 if expr 2.3.3 \> `${WX_CONFIG} --version`
 fi

 to

 if test $WX_CONFIG
 ...
 else
   if expr 2.3.3 \> `${WX_CONFIG} --version`
   fi
 fi

 Ok?

Re: Information about SF CVS services

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

On Wednesday 17 May 2006 01:57 pm, Hans-Bernhard Br=F6ker wrote:
> Lars Hecking wrote:
> >
> >  I keep getting regular "connection refused" message when I try to
> > do cvs operations.
>
> See their 'Site Status'.  They've apparently had a CVS server crash,
> again.

Heh.  I'm having the opposite set of problems.
I can see and use the cvs server just fine.
It's the web site (including the status page) that is
non-responsive.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: Information about SF CVS services

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

Lars Hecking wrote:
>> Yep.  They're basically taking back the change from virtual hosts per 
>> project to a single host they did a while ago.  So we now have a 
>> per-project host name again.
>  
>  I keep getting regular "connection refused" message when I try to do cvs
>  operations. 

See their 'Site Status'.  They've apparently had a CVS server crash, again.

Re: GPGET('terminal')

[Petr M. <mi...@ph...>]

> %%%%%%% Something wrong in save/load code %%%%%%%%%%%%%%%%%
> gnuplot> save 'yyy'
>
> gnuplot>  GPVAL_TERM_OPTIONS = "something or other"
>  Cannot set internal variable GPVAL_*

Both implemented, also for the MOUSE_ variables.


>   SHOW_ALL_NL;
>-    fputs("\n\tVariables:\n", stderr);
>+    int show_gpval = 0;

Fixed.

---
PM

Re: Information about SF CVS services

[Lars H. <lhe...@us...>]

> Same for me now.
 
 Good. Then it's not our IT department doing stupid things ...

Re: Information about SF CVS services

[Petr M. <mi...@ph...>]

> I keep getting regular "connection refused" message when I try to do cvs
> operations. Couldn't get it to work at all yesterday, and this morning I
> managed to check out the tree with the new root. However, it's back to
> "connection refused" now. Is anyone else seeing this?

Same for me now.

---
PM

Re: Information about SF CVS services

[Lars H. <lhe...@us...>]

> Yep.  They're basically taking back the change from virtual hosts per 
> project to a single host they did a while ago.  So we now have a 
> per-project host name again.
 
 I keep getting regular "connection refused" message when I try to do cvs
 operations. Couldn't get it to work at all yesterday, and this morning I
 managed to check out the tree with the new root. However, it's back to
 "connection refused" now. Is anyone else seeing this?

stat.inc

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

I wanted to make use of some functions in 'stat.inc'.  Looking through the file I see there are a few distributions in which p.d.f. and c.d.f. technically should be defined to have a value of zero for negative x.  For example, exponential r.v.s, Weibull r.v.s and Rayleigh r.v.s have a support which is only the non-negative portion of the x-axis.

The way to address this would be to define

#
#define unit step function
#
u_step(x) = x<0 ? 0 : 1

then multiply all the pertinent density/distribution functions by the unit step.

Should I put together a patch for this?

Dan

Re: GPGET('terminal')

[Petr M. <mi...@ph...>]

>> I have implemented it as you've proposed, see SF patch
>>  	1488448  User-available GPVAL_ variables
>
> It looks basically reasonable to me.
> There are some rough edges though:
>
> %%%%%%% How to handle time data on axes? %%%%%%%%%%%%%%%%%%
>
>  set xdata time
>  set xrange [ "01/06/93\t0000" : "01/11/93\t0000" ] noreverse nowriteback
>
> gnuplot> print GPVAL_X_MIN
> -207792000.0
> gnuplot> print GPVAL_X_MAX
> -194572800.0

Sorry, I have no idea about time values, I have never dealt with them.


> %%%%%%% Something wrong in save/load code %%%%%%%%%%%%%%%%%
>
> Terminal type set to 'wxt'
> gnuplot> save 'yyy'
> gnuplot> load 'yyy'
> Segmentation fault
>
> I think these special variables should not be user-writable.
> That is, I think we want to return an error message like
>
> But this means it makes no sense to save these variables in
> the `save` command, because it will not be possible to read
> them back in on `load`.

Yes, it is reasonable not to 'save' them, I will add this.

> gnuplot>  GPVAL_TERM_OPTIONS = "something or other"
>  Cannot set internal variable GPVAL_*

Do you know where is code with the variable assignment?

---
PM

Re: GPGET('terminal')

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

On Sunday 14 May 2006 01:10 pm, Petr Mikulik wrote:
>
> I have implemented it as you've proposed, see SF patch
>  	1488448  User-available GPVAL_ variables
>
> Type
>      show var all
> to display those variables related to the last plot.

It looks basically reasonable to me.
There are some rough edges though:

%%%%%%% How to handle time data on axes? %%%%%%%%%%%%%%%%%%

Terminal type set to 'wxt'
gnuplot> load 'timedat.dem'
Hit return to continue
gnuplot> show xrange

  set xdata time
  set xrange [ "01/06/93\t0000" : "01/11/93\t0000" ] noreverse nowriteback

gnuplot> print GPVAL_X_MIN
-207792000.0
gnuplot> print GPVAL_X_MAX
-194572800.0

%%%%%%% Something wrong in save/load code %%%%%%%%%%%%%%%%%

Terminal type set to 'wxt'
gnuplot> save 'yyy'
gnuplot> load 'yyy'
Segmentation fault


I think these special variables should not be user-writable.
That is, I think we want to return an error message like

gnuplot>  GPVAL_TERM_OPTIONS = "something or other"
  Cannot set internal variable GPVAL_*

But this means it makes no sense to save these variables in
the `save` command, because it will not be possible to read
them back in on `load`.



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

Re: z_floor and z_ceiling (was Re: various observations)

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>
>> Please explain more.  Are you simply saying there is no need for two=20
>> values in the xyplane array because the value is set, by requirement,=20
>> for both "set xyplane #" and "set xyplane at #"?  That's true.
>=20
>=20
> Yes.  And once that's cleaned up, the code using those variables, *and*=
=20
> the documentation, will quite likely end up being simpler than both the=
=20
> current code or your proposed patch.

Oh, I see what you are saying.  I can fix the patch up for that fairly ea=
sily I think; tomorrow or the next day.


>=20
>> Right, I see that now.  I was not think of this correctly.  My idea of=
=20
>> the "anchor" point was not zmin.  Perhaps wording the doc and the=20
>> following rewriting of the formula would help:
>>
>> pos =3D zmin + <frac> (zmin - zmax)
>=20
>=20
> Actually, the simplest explanation is probably the best here:  just=20
> state that ticlevels 0 and -1 correspond to the bottom and top of the z=
=20
> axis (_not_ the min and max, actually --- z axis can be reversed!),

Aye!  Yes, well then:

"The position on the z_axis is then

pos =3D z_bottom + <frac> (z_bottom - z_top)

where z_bottom may be a positive or negative value."

I just did the math quickly here and I think that still works out.  Notin=
g the 0, -1 relationship would be nice to.  Please make it 1 though!  "0 =
is the bottom, -1 is the top" just throws my world all topsy turvy.  :-) =
 Seriously, what I meant by confusion is that ticslevel having the negati=
ve value and xyplane the positive value would be the confusion... confusi=
on I could live with.


>> (In the remainder of that text I had written about a proposal for=20
>> segments of the border; you'll notice that the vertical lines were=20
>> treated as two segments, one part above the plotted surface, one part=20
>> below the plotted surface, attempting to be similar to the way the=20
>> ticslevel works.)
>=20
>=20
> The interpretation of the vertical line aspect of 'set border' in 3D=20
> plots is admittedly quite crazy.  You get some verticals you can contro=
l=20
> through 'set border', and others you can't (those from the base to the=20
> uppermost corner points, which only get drawn if a data point actually=20
> sits exactly in the corner).  If control for these is provided as yet=20
> another new feature,  it might be better suited as part of 'set=20
> xyplane', rather than 4 more bits to contrl by 'set border' --- that=20
> one's cramped enough as it is.

Well, the thing is it would be a more natural fit what I proposed: 16 seg=
ments, 16 bits.  But the big gain I think is the ability to use short abb=
reviations like "blf" for "bottom/left/front" representing these bits.  "=
blf+tlf" has a better chance of being remembered than the numerical equiv=
alents.  Also the conflicting contex, e.g., 2 means top in 2D and bottom =
in 3D, was a bad oversight.

Dan

Re: z_floor and z_ceiling (was Re: various observations)

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

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:

>> And there are *two* float variables, only one of which is controllable 
>> by the user, at any given time, but both have effect on the result. 
>> That's clearly wrong.  The patch is wrong because it doctors symtoms 
>> of this bug, instead of fighting the disease.

> Please explain more.  Are you simply saying there is no need for two 
> values in the xyplane array because the value is set, by requirement, 
> for both "set xyplane #" and "set xyplane at #"?  That's true.

Yes.  And once that's cleaned up, the code using those variables, *and* 
the documentation, will quite likely end up being simpler than both the 
current code or your proposed patch.

> Right, I see that now.  I was not think of this correctly.  My idea of 
> the "anchor" point was not zmin.  Perhaps wording the doc and the 
> following rewriting of the formula would help:
> 
> pos = zmin + <frac> (zmin - zmax)

Actually, the simplest explanation is probably the best here:  just 
state that ticlevels 0 and -1 correspond to the bottom and top of the z 
axis (_not_ the min and max, actually --- z axis can be reversed!), and 
that the coordinate moves linearly.

> At this point though, changing the polarity might just confuse matters.

This is not a question of what "might" happen.  The polarity in the 'set 
ticslevel' parameter will not change, period.  I won't have script 
compatibility compromised.  What can be discussed is whether we should 
split up the old 'set ticslevel' and its alias, 'set xyplane <level>'. 
These two could have different scales.

> (In the remainder of that text I had written about a proposal for 
> segments of the border; you'll notice that the vertical lines were 
> treated as two segments, one part above the plotted surface, one part 
> below the plotted surface, attempting to be similar to the way the 
> ticslevel works.)

The interpretation of the vertical line aspect of 'set border' in 3D 
plots is admittedly quite crazy.  You get some verticals you can control 
through 'set border', and others you can't (those from the base to the 
uppermost corner points, which only get drawn if a data point actually 
sits exactly in the corner).  If control for these is provided as yet 
another new feature,  it might be better suited as part of 'set 
xyplane', rather than 4 more bits to contrl by 'set border' --- that 
one's cramped enough as it is.



> 
> Dan
> 

Re: z_floor and z_ceiling (was Re: various observations)

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> Hans-Bernhard Br=F6ker wrote:
>>
>>> Daniel J Sebald wrote:
>=20
>=20
> [...]
>=20
>> The patch sort of makes sense.  THere is a variable for controlling=20
>> whether the xyplane is "absolute" or not. =20
>=20
>=20
> And there are *two* float variables, only one of which is controllable=20
> by the user, at any given time, but both have effect on the result.=20
> That's clearly wrong.  The patch is wrong because it doctors symtoms of=
=20
> this bug, instead of fighting the disease.

Please explain more.  Are you simply saying there is no need for two valu=
es in the xyplane array because the value is set, by requirement, for bot=
h "set xyplane #" and "set xyplane at #"?  That's true.


> Yes, the coordinate direction for "ticslevel" is -z, not +z --- but tha=
t=20
> shouldn't be too hard to grasp for anyone brave enough to touch the=20
> insides of a program doing 3D computer graphics ;-)

"brave"?  Are you using that in the euphemistic sense?  (I'll take it.)


>> puts the xyplane in the positive z hemisphere.  I would think that=20
>> having it the other way around (with -0.5 as the default) would be a=20
>> better memory aid.
>=20
>=20
> Maybe.  But we're limited by backwards compatibility here.  The=20
> coordinate system for 'set xyplane <level>' is open for discussion, but=
=20
> that for the original command 'set ticslevel' is not.
>=20
>> I may not be thinking of this correctly, but I'd say that the above=20
>> two examples are not consistent.  Should the "set xyplane -1" also=20
>> have a big blank area past the *positive* extreme of the z-axis now?
>=20
>=20
> No, because 'ticslevel -1' is just the upper end of the actual z range,=
=20
> i.e. it makes base_z =3D ceiling_z.

Right, I see that now.  I was not think of this correctly.  My idea of th=
e "anchor" point was not zmin.  Perhaps wording the doc and the following=
 rewriting of the formula would help:

pos =3D zmin + <frac> (zmin - zmax)

Yes, I think I'd have prefered the polarity of the fraction be switched a=
round, i.e.,

pos =3D zmin + <frac> (zmax - zmin).

At this point though, changing the polarity might just confuse matters.


> But 'set xyplane -2' should.

Yup.  Thanks.


>> and I then imagine what it would look like to have *both* of those=20
>> planes present, i.e., all the axes/borders of a box.
>=20
>=20
> Not quite.  That's what the implementation of 'set {x|y}tics mirror'=20
> and/or secondary x and y axes in an splot will be about --- if somebody=
=20
> ever writes one.

OK, that would be another valid way to do that.

(In the remainder of that text I had written about a proposal for segment=
s of the border; you'll notice that the vertical lines were treated as tw=
o segments, one part above the plotted surface, one part below the plotte=
d surface, attempting to be similar to the way the ticslevel works.)

Dan

Re: z_floor and z_ceiling (was Re: various observations)

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

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:
>> Daniel J Sebald wrote:

[...]
> The patch sort of makes sense.  THere is a variable for controlling 
> whether the xyplane is "absolute" or not.  

And there are *two* float variables, only one of which is controllable 
by the user, at any given time, but both have effect on the result. 
That's clearly wrong.  The patch is wrong because it doctors symtoms of 
this bug, instead of fighting the disease.

> xyplane far off of the plot with the "ticslevel %" approach.  I couldn't 
> exactly understand the difference for values alpha > 1 and values 0 < 
> alpha < 1.  

Actually, the three important classes for the ticslevel parameter are:

1) [0:*] --> baseplane below the graph quboid.
2) [-1:0] --> baseplane inside the quboid
2> [*:-1] --> baseplane on top of the quboid --- this may well fail 
completely.

Yes, the coordinate direction for "ticslevel" is -z, not +z --- but that 
shouldn't be too hard to grasp for anyone brave enough to touch the 
insides of a program doing 3D computer graphics ;-)

> Now that I reread the documentation, I guess I agree with you that the 
> documentation is a not good.

And the reason for that is that the behaviour of the code makes no 
sense.  Writing correct docs for crazy code would be pointless.

> puts the xyplane in the positive z hemisphere.  I would think that 
> having it the other way around (with -0.5 as the default) would be a 
> better memory aid.

Maybe.  But we're limited by backwards compatibility here.  The 
coordinate system for 'set xyplane <level>' is open for discussion, but 
that for the original command 'set ticslevel' is not.

> I may not be thinking of this correctly, but I'd say that the above two 
> examples are not consistent.  Should the "set xyplane -1" also have a 
> big blank area past the *positive* extreme of the z-axis now?

No, because 'ticslevel -1' is just the upper end of the actual z range, 
i.e. it makes base_z = ceiling_z.

But 'set xyplane -2' should.

> set xyplane at -20
> splot x+y
> 
> set xyplane at 20
> splot x+y
> 
> and I then imagine what it would look like to have *both* of those 
> planes present, i.e., all the axes/borders of a box.

Not quite.  That's what the implementation of 'set {x|y}tics mirror' 
and/or secondary x and y axes in an splot will be about --- if somebody 
ever writes one.

Re: GPGET('terminal')

[Petr M. <mi...@ph...>]

>> a = GPGET("terminal")   =>  return "x11"
>> a = GPGET("termoptions")   =>  return "enhanced noraise"
>> xmin = GPGET("xmin")    =>  return min of xrange of the last plot
>> ... GPGET("xmax"), "y2min", "cbmin", etc.
>
>> Only few variables, the most important, should be availabe now -- others
>> could be added on user's request any later, without poluting the user
>> space with new var/funcs.
>
> I'm not convinced that polluting the name space is a problem.
> We could simply agree to use only variables beginning with
> MOUSE_ or GPVAL_ or FIT_ or whatever, and document that users should
> avoid creating private variables starting with these character strings.
>
> Exporting a new internal variable as a user-visible one requires only
> 3 lines of code. Parsing for your proposed GPGET option would be more
> cumbersome, I think, and would require making all exportable variables
> global.

I have implemented it as you've proposed, see SF patch
 	1488448  User-available GPVAL_ variables

This patch implements user-available GPVAL_ variables, like GPVAL_X_MIN, 
GPVAL_X_MAX, GPVAL_Y_MIN, ...

Type
     show var all
to display those variables related to the last plot.

---
PM

Re: z_floor and z_ceiling (was Re: various observations)

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

Daniel J Sebald wrote:
 (They probably 
> wouldn't be the same numbers as the current assignment, because I think 
> there are some conflicts there.  E.g.,
> 
> 4   top         bottom right front
> 
> means "top" in one context, "bottom" in another.  But the two syntaxes 
> could still exist if we simply write the 1, 2, 4, 8, 16, etc. as strings 
> with an associated number as well.)

On second thought, that wouldn't work because we need to allow for the number to be anything, e.g., 3...  Oh, it could still be done fairly easily.

Dan

Re: z_floor and z_ceiling (was Re: various observations)

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> I put a bug report and patch on S.F. for this.  Try
>>
>>  set xyplane at -20
>>  splot x+y
>>
>> before and after patch.
>=20
>=20
> There's a bug there alright, but I don't think the patch is going in th=
e=20
> right direction.  The real problem is the mismatch between the user=20
> interface presented by set.c:set_ticslevel() and the actual internal=20
> data structure t_xyplane.

The patch sort of makes sense.  THere is a variable for controlling wheth=
er the xyplane is "absolute" or not.  If absolute, then it is the min(pla=
neval,ZAXIS.min), if not it is related to the % value.

>=20
>> (I see HBB sort of nearby this stuff, with dates from way back.)
>=20
>=20
> Not really to be wondered about.  I put such comments in the source=20
> wherever I see something dubious going on, or where the intent of a=20
> piece of code isn't immediately clear, and I initial them to make sure=20
> people know who to get back to about them.  I don't see any of those=20
> particularly close to the xyplane stuff, though, and none of them=20
> relating to it.

Well, it's near the point where the lines are actually drawn, so one degr=
ee of indirection I guess.

Anyway, I sat thinking about the documentation for the ticslevel/xyplane =
stuff for the longest time.  First, I somehow accomplished to get the xyp=
lane far off of the plot with the "ticslevel %" approach.  I couldn't exa=
ctly understand the difference for values alpha > 1 and values 0 < alpha =
< 1.  Then the "xyplane at #" approach resulted in this bug you see.  Tha=
t is why I initially wrote to the list to inquire about whether this was =
a bug a bug or not.  (Then there was the "drop down lines" sometimes draw=
ing, sometimes not problem.  I see a new CHangeLog entry by Ethan for som=
ething related to that.)

Now that I reread the documentation, I guess I agree with you that the do=
cumentation is a not good.

First, I find the +/- convention to be a possible source of confusion.  T=
hat is,

set xyplane +#

puts the xyplane in the negative z hemisphere

set xyplane -#

puts the xyplane in the positive z hemisphere.  I would think that having=
 it the other way around (with -0.5 as the default) would be a better mem=
ory aid.

Go back to the original unpatched version and try

set term x11 1
set xyplane +1
splot x+y

set term x11 2
set xyplane -1
splot x+y

I may not be thinking of this correctly, but I'd say that the above two e=
xamples are not consistent.  Should the "set xyplane -1" also have a big =
blank area past the *positive* extreme of the z-axis now?

And this comment in the doc:

 To place the xy-plane at a position 'pos' on the z-axis, `ticslevel` may
 be set equal to  (pos - zmin) / (zmin - zmax).  However, this position w=
ill
 change if the z range is changed.

Scratch that.  It may be true, but there is an "at #" version of the comm=
and.  Don't encourage people to use a linear translation.  If someone wan=
ts to go through that extra work, let them devise the translation on thei=
r own.

Lastly, let's go to the wishlist realm.  I see what the plot looks like w=
ith

set xyplane at -20
splot x+y

set xyplane at 20
splot x+y

and I then imagine what it would look like to have *both* of those planes=
 present, i.e., all the axes/borders of a box.

Now, this may be possible to do with "set border".  However, this documen=
tation doesn't give the right answer:

 Draw a complete box around a `splot`:
       set border 4095

That doesn't seem to work.  And one last off-hand smarmy comment:

 Draw a topless box around a `splot`, omitting the front vertical:
       set border 127+256+512 # or set border 1023-128

Eeeww!  Here is the syntax:

             Bit     plot        splot
               1   bottom      bottom left front
               2   left        bottom left back
               4   top         bottom right front
               8   right       bottom right back
              16   no effect   left vertical
              32   no effect   back vertical
              64   no effect   right vertical
             128   no effect   front vertical
             256   no effect   top left back
             512   no effect   top right back
            1024   no effect   top left front
            2048   no effect   top right front


In hindsight, it would have been nice to have the following:

            plot             splot
syntax     meaning          meaning
------     -------          -------
blf      bottom/left    bottom left front
blk      bottom/left    bottom left back
brf      bottom/right   bottom right front
brk      bottom/right   bottom right back
tlf      top/left       top left front
tlk      top/left       top left back
trf      top/right      top right front
trk      top/back       top right back
lb       bottom/left    left bottom vertical
lt       top/left       left top vertical
rb       bottom/right   right bottom vertical
rt       top/right      right top vertical
fb       bottom         front bottom vertical
ft       top            front top vertical
kb       bottom         back bottom vertical
kt       top            back top vertical

bl       bottom/left    blf+blk
br       bottom/right   brf+brk
bf       bottom         blf+brf
bk       bottom         blk+brk
tl       top/left       tlf+tlk
tr       top/right      trf+trk
tf       top            tlf+trf
tk       top            tlk+trk

b        bottom         blf+blk+brf+brk
t        top            tlf+tlk+trf+trk
l        left           lb+lt  (left vertical)
r        right          rb+rt  (right vertical)
f        *              fb+ft  (front vertical)
k        *              kb+kt  (back vertical)

bottom   b              b
top      t              t
left     l              l
right    r              r
front    f              f
back     b              b

btlr     b+t+l+r        b+t+l+r  (memory aid "butler")
all      btlr           btlr

The above still represents 16 line segments, so the above strings could b=
e stored as a table with an associated 16 bit number.  (They probably wou=
ldn't be the same numbers as the current assignment, because I think ther=
e are some conflicts there.  E.g.,

4   top         bottom right front

means "top" in one context, "bottom" in another.  But the two syntaxes co=
uld still exist if we simply write the 1, 2, 4, 8, 16, etc. as strings wi=
th an associated number as well.)

Dan

Re: z_floor and z_ceiling (was Re: various observations)

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

Daniel J Sebald wrote:
> I put a bug report and patch on S.F. for this.  Try
> 
>  set xyplane at -20
>  splot x+y
> 
> before and after patch.

There's a bug there alright, but I don't think the patch is going in the 
right direction.  The real problem is the mismatch between the user 
interface presented by set.c:set_ticslevel() and the actual internal 
data structure t_xyplane.

> (I see HBB sort of nearby this stuff, with dates from way back.)

Not really to be wondered about.  I put such comments in the source 
wherever I see something dubious going on, or where the intent of a 
piece of code isn't immediately clear, and I initial them to make sure 
people know who to get back to about them.  I don't see any of those 
particularly close to the xyplane stuff, though, and none of them 
relating to it.

z_floor and z_ceiling (was Re: various observations)

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

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

I put a bug report and patch on S.F. for this.  Try

  set xyplane at -20
  splot x+y

before and after patch.

(I see HBB sort of nearby this stuff, with dates from way back.)

Dan

Re: Information about SF CVS services

[Petr M. <mi...@ph...>]

> All documentation and web pagess need to be updated - CVSROOT is changing
> for general access

I've updated gnuplot.sf.net; www.gnuplot.info should be mirrored soon.

---
PM

Re: Information about SF CVS services

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

Lars Hecking wrote:
>  All documentation and web pagess need to be updated - CVSROOT is changing
>  for general access (but not developer cvs access, if I interpret this
>  correctly - pserver vs. ext).

Yep.  They're basically taking back the change from virtual hosts per 
project to a single host they did a while ago.  So we now have a 
per-project host name again.

We'll also all have to update our working directories to reflect this, 
again.  SF only mentions  scrapping your working copy and checking out 
fresh.  You may want to give the cvsutils package a try instead.  It 
contains a nifty little tool "cvschroot" to do this. Or, if you're more 
adventurous, just edit the CVS/Root files manually.

Information about SF CVS services

[Lars H. <lhe...@us...>]

 All documentation and web pagess need to be updated - CVSROOT is changing
 for general access (but not developer cvs access, if I interpret this
 correctly - pserver vs. ext).

----- Forwarded message from "SourceForge.net Team" <no...@so...> -----

From: "SourceForge.net Team" <no...@so...>
Subject: SUBJECT: SourceForge.net: CVS service offering changes 
Date: Thu, 11 May 2006 16:18:29 -0700 (PDT)

Greetings,

You are receiving this mail because you are a project admin for
a SourceForge.net-hosted project. One of our primary services,
CVS, suffered a series of interrelated, critical hardware failures
in recent weeks. We understand how frustrating this CVS outage
must be to you and your users; however, our top priority remains
preservation of the integrity of your data.

The series of CVS hardware failures prompted us to expedite the
deployment of planed improvements to our CVS infrastructure,
drawing upon much of the knowledge that we gained from our
Subversion deployment. Our improved CVS service architecture,
which we plan to deploy tomorrow afternoon (2006-05-12), will
offer greater performance and stability and will eliminate several
single points of failure.

The Site Status page (https://www.sf.net/docs/A04) will be
updated as soon as the new infrastructure is rolled out. In the
interim, please read the important information provided below
to learn about how these changes will affect your project.


Summary of changes, effective 2006-05-12:


1. Hostname for CVS service

Old: cvs.sourceforge.net

New: PROJECT_UNIX_NAME.cvs.sourceforge.net

This change will require new working copies to be checked out of all
repositories (so control files in the working copy will point to the
right place). We will be updating the instructions we supply, but
instructions that your team has written within documentation, etc. will
need to be updated.

cvs -d:pserver:ano...@cv...:/cvsroot/gaim co gaim

would be changed to

cvs -d:pserver:ano...@ga...:/cvsroot/gaim co gaim



2. ViewCVS

We are moving from ViewCVS to its successor, ViewVC. ViewVC is
currently in use for our Subversion service.



3. Sync delay

Old: CVS pserver, tarballs and ViewCVS provided against a separate
server which is a minimum of three hours behind developer CVS.

New: ViewVC will be provided against developer CVS (it will be current).
CVS pserver will be provided against a secondary server (not developer
server) with a maximum expected delay of two hours.

Follow-up work is planned (this infrastructure takes us 80% of the way)
to essentially eliminate the sync delay.



4. Read-only rsync service

As a new service offering, we are now providing read-only rsync access
against developer CVS. This allows projects to efficiently make
on-demand backups of their entire CVS repository.

All projects should be making regular backups of their CVS repository
contents using this service.



5. Nightly tarball service

Nightly tarball service is being dropped in lieu of read-only rsync
service. Projects which currently depend on nightly tarballs for
repository backups will need to begin using rsync to make a backup copy
of their repository contents.

We see this as a major functional improvement. For a number of reasons,
tarballs have fallen out of sync with the data in the repository at
times in the past few years. Tarballs required a substantial amount of
additional disk, and I/O to generate. The move to read-only rsync
allows backups to be produced on-demand, with an update frequency chosen
by the project.



6. Points of failure

In the past, developer CVS service for all projects was provided from a
single host. CVS pserver service was provided from individual backend
heads based on a split of the data.

Under our new design, developer CVS and most of our CVS-related services
are provided from one of ten CVS hosts (count subject to increase with
growth). Each host is independent, and makes a backup copy of the
repository data of another host (which is used to provide the pserver
CVS service).

Failure of a single host will impact only the availability of data on
that host. Since the data is split among a larger number of hosts, the
size of data impacted by an individual host outage is substantially
smaller, and the time required for us to restore service will be
substantially shorter.

This rapid architecture change has been made possible specifically using
the research we performed for our recent launch of Subversion service.
We've applied our best practices, produced a substantial amount of
internal documentation, and kept an eye toward maintainability.
This effort has allowed us to deploy this new architecture quickly
once hardware was received, and will permit us to quickly scale
this service horizontally as growth and demand requires. 



Many other minor improvements have also been made to improve the service
offering and make it less trouble-prone. The most important of which are
listed above. For a full description of the new service offering, and
for information on how to use the services described above, please refer
to the site documentation for the CVS service after the service has been
launched: https://www.sf.net/docs/E04


Thank you,

The SourceForge.net Team 

.

----- End forwarded message -----

Re: various observations (added to list)

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

Daniel J Sebald wrote:

> 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*.  
> Is that how C64 and IBM BASIC worked?  I.e.,

I just looked up BASIC (if this is different from IBM BASIC, I'm not sure):

http://www.leinweb.com/basic/manual/man1/rnd.func.htm
http://msdn2.microsoft.com/en-us/library/f7s023d2.aspx

Which has the ability to set the seed using randomize:

http://www.leinweb.com/basic/manual/man1/randomize.stmt.htm
http://msdn2.microsoft.com/en-us/library/8zedbtdt.aspx

So BASIC is a case where one can set the seed with randomiz() and not draw a sample immediately.  Similar to Octave.  Similar to C.

But looking closer at the "rnd" routine of BASIC, oddly there is also a way to set the seed using the single argument.  (Did this "randomize" come later or something?)  So BASIC does this < 0, > 0, = 0 skullduggery as well.  But it isn't exactly the same as gnuplot.  For < 0, BASIC generates a value from the seed.  (But it says nothing about advancing the generator.)  For > 0, the result is next pseudo r.n. in sequence.  For = 0, the result is the most recently generated value.  (Again, it says nothing about advancing the generator.)

So what happens in BASIC with

rnd(-1)
rnd(0)
rnd(0)

?  Same value for first two uses of rnd(), then a different value for the third use of rnd()?

Well, is gnuplot in the tradition of BASIC?  Sort of.  I'd bow to someone knowledgable in PRNG who could say gnuplot should behave as such and explain why, but I don't see the consistency with most conventional PRNGs on the matter.

I don't know.  Put me in the

  unset seed
  set seed #
  set seed #,#
  show seed

camp, for what it's worth.

Dan

Re: various observations (added to list)

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

Ethan A Merritt wrote:
> 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?

Sort of.  But not too much, so long as someone tested it.

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

From doc:

 `rand(x)`  for x>0 sets both seeds to a value based on the value of x.

> But since the documentation does not say what those
> two internal seeds will be used for, the reader is really no wiser than before.

:-)  Come on, this is getting to be semantics now.  Perhaps the documentation should be one of the following two to get rid of the confusion.

1)  rand({x,y})` for x>0 sets seed1 to x and seed2 to y, then generates a random number (which you can't really make much use of in a data stream) so that seed1 and seed2 become some other values.

This one can stay as it makes no promises in its wording:

 `rand(x)`  for x>0 sets both seeds to a value based on the value of x.

"a value based on" is sort of like "some people believe" (i.e., "this may not be factual").  So it is implying that seed1 = seed2 = x should be the result, but sure it could be interpreted as "it is whatever it is".  Which leads to...

2) `rand(x)`  for x>0 puts the PRNG in a known state
   `rand({x,y})` for x>0 puts the PRNG in a known state

Why go through the trouble of pointing out "seed1", "seed2" or "both seeds" in the documentation if it isn't accurate?

Dan

Re: fit_control and splot_overview

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

On Thursday 11 May 2006 07:55 pm, Daniel J Sebald wrote:
> Perhaps this was just an oversight (see patch) when someone cleaned up the documentation.

Could you please submit patches via the SourceForge site?

It's bad enough having to track those, without also having to track 
patches lost somewhere in my 3500+ message gnuplot mail folder.


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