Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2006-06-13 17:39:51
|
Seeing Ethan's email reminded me that an email I sent a while back didn't= get through the list: Timoth=E9e Lecomte wrote: > Here is a message from the octave mailing list kindly asking for a=20 > gnuplot release mainly for the image code. > Any update on the remaining work, compared to Ethan's previous review ?= =20 > Any domain where I could help, apart from stabilizing the wxWidgets=20 > terminal ? Pick a bug in the list, I guess. They seem to be coming in at a higher r= ate lately... probably reflects increased usage. Should keep a list of things to do on the gnuplot.info page. In any case= I'll lobby for the following before a 4.2 release: 1) BUG 1488168 z_floor and z_ceiling based on xyplane.absolute There is a patch there to fix that one. After applying this patch I sugg= est also a change to the mouse behavior for the scale. Have the xyplane = move in the direction the mouse moves (i.e., invert the scale movement) a= nd also have the motion be linear and not tend to zero as the xyplane nea= rs zero. If Ethan doesn't have time to change that and thinks it is wort= h changing, I can modify that. 2) BUG 1503114 FIX: 1107709 plot [-1:1] x is plotted with asymmetric= y-axis I picked a bug in the list and fixed it. It is a short little patch that= puts a 0.01 tolerance in computation of the tics before doing ceil() or = floor(). That means an overrun of 1/100 of a tic will be ignored. Not a= problem in most cases and if the user is concerned or even notices, manu= al ranging can be done. [I changed this recently from 1/100 of a tic to something like 1/200 of t= he overall range in the "rounded outward" dimension. This could use some= discussion on the list. The concept is that in order to compensate for = rounding errors--e.g., the tic interval is computed as 0.999999 and then = after being used as the divisor causes ceil to grossly round upward---the= patch is ignoring 1/200 of the overall range. It helps in cases of obvi= ous mistakes, several of which appear in all.dem; much nicer. The proble= m might be for users whose data goes from, say, -2.0 to 2.001 or somethin= g. Gnuplot will then default to -2.0 to 2.0. There are alternate ways t= o address this I guess... Maybe rounding the tic interval computation fi= rst before using it in the division is the correct thing to do.] 3) PATCH 1494573 check number of variables for u.d. functions This is a really nice patch that will verify that the number of variables= supplied to a defined function matches the number of variables when defi= ned. Pretty straightforward patch; it simply adds a record to the struct= ure of the number of variables. [I'd like to see this one in before 4.2 because it promotes good programm= ing practice. There are one or two subtle behavioral things that develop= ers might not agree with, but it does wait until the stage of evaluating = to complain.] 4) PATCH 1499728 revamped stat.inc Crosses the t's and dots the i's on the p.d.f./c.d.f. definitions in stat= .inc. Also adds a bit of variety to 'prob.dem' making it more tutorial i= n fashion. 5) PATCH 1027032 Connect gnuplot_x11 to exterior application window This one is of no urgency to me, but someone at some point requested it. = We're close on this one, and there was some detail left uncovered I can'= t recall right now. But it would be nice to add this one just to get it = out of the patch list. Dan |
|
From: <br...@ph...> - 2006-06-15 11:08:15
|
Daniel J Sebald wrote: > 2) BUG 1503114 FIX: 1107709 plot [-1:1] x is plotted with > asymmetric y-axis I'm still just as opposed to this fix as I was when I first commented on the bug report. It's an attempt at fixing symptoms, and does so in the wrong place. > I picked a bug in the list and fixed it. Not really. You just hid it in a spot where it's harder to trigger. Floating-point rounding is tricky stuff. It's completely inevitable that sometimes, results will surprise people. All this patch does is move the surprise from a seemingly obvious place to a less obvious one. An axis ending at 2.0000001 has no more business being artificially cut down to 2.0 than one ending at 2.001. The current behaviour may not be free from surprises, but at least it's correct: an autoscaled axis always contains all its inputs. I find that rule much more important than trying to avoid surprise when users get an axis extended a little more than they believed it had to be. This patch breaks good rules to match ill-founded expectations. |
|
From: <br...@ph...> - 2006-06-20 23:14:15
|
Daniel J Sebald wrote: > There are only two valid concepts in my mind. > > 1) What I just described, which is ignore anything within (or beyond, > whatever your viewpoint) a small fraction of the total range. Likely > something so small it can't be resolved. And the trouble with that is that "can't be resolved" is a criterion that by its very definition depends on information that the autoscaling algorithm can't have. The actual resolution of the eventual output device of a plot may not even be known at 'plot' time, much less can autoscaling be allowed to depend on it. BTW: gnuplot has a parameter like your proposed "tolerance": set zero. But it's being used less and less in the actual code, and I think that's a good thing. > 2) Ignore anything within the machine resolution (i.e., epsilon) or > some small multiple of machine resolution, what Petr pointed out. Machine resolution is quite certainly the wrong way of doing this. That's the smallest value for your "TOL" parameter that's distinguishable from zero at all, effectively --- the only useful application of it would be sanity-check a 'set tolerance'. I still hold that 3) zero tolerance --- keep it small and simple is the right way to go. > Going back to your original point. The jump tells someone their data > extends beyond a tic, but in a perhaps imperceptable way. (We could do > some examples to test this.) ... and if that really bothers some user, he can always easily fix that range manually (or, if he dislikes this jumpiness altogether, put 'set autoscale xfix' in his ~/.gnuplot). > I don't know what the preference would be, honestly. Let me put it this way: that behaviour, and those demos, have been around for years, some of them decades. IIRC, we've had a total of about one complaint about that, in all that time. |
|
From: Daniel J S. <dan...@ie...> - 2006-06-20 23:47:08
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >=20 >>There are only two valid concepts in my mind. >> >>1) What I just described, which is ignore anything within (or beyond,=20 >>whatever your viewpoint) a small fraction of the total range. Likely=20 >>something so small it can't be resolved. >=20 >=20 > And the trouble with that is that "can't be resolved" is a criterion=20 > that by its very definition depends on information that the autoscaling= =20 > algorithm can't have. The actual resolution of the eventual output=20 > device of a plot may not even be known at 'plot' time, much less can=20 > autoscaling be allowed to depend on it. Well, I'm not sure on that. Set the resolution to 20000 by 20000. Then = a ticmark will be 1/20000? If so, that is not viewable. You'd have to f= orce a tic mark to be five or more pixels. I mean, sure perhaps there is= a reason for such a high resolution, say a person wants to create a conf= erence poster and be able to resolve something in a little corner of the = plot. My point here is that I think there is an inherent amount of visual plott= ing information that a person can view. I'm confortable with the idea of= limits on resolution. > BTW: gnuplot has a parameter like your proposed "tolerance": set zero. > But it's being used less and less in the actual code, and I think that'= s=20 > a good thing. >=20 >=20 >>2) Ignore anything within the machine resolution (i.e., epsilon) or=20 >>some small multiple of machine resolution, what Petr pointed out. >=20 >=20 > Machine resolution is quite certainly the wrong way of doing this.=20 > That's the smallest value for your "TOL" parameter that's=20 > distinguishable from zero at all, effectively --- the only useful=20 > application of it would be sanity-check a 'set tolerance'. The idea would be to reasonably catch the situation where the tic interva= l is computed as 1/3 =3D 0.33333333333 and then the round outward test do= es something (after arithmetic) like deciding 0.999999999999 < 1.0 becau= se of rounding. > I still hold that >=20 > 3) zero tolerance --- keep it small and simple >=20 > is the right way to go. >=20 >=20 >>Going back to your original point. The jump tells someone their data=20 >>extends beyond a tic, but in a perhaps imperceptable way. (We could do= =20 >>some examples to test this.) >=20 >=20 > ... and if that really bothers some user, he can always easily fix that= =20 > range manually (or, if he dislikes this jumpiness altogether, put 'set=20 > autoscale xfix' in his ~/.gnuplot). I know. >>I don't know what the preference would be, honestly. =20 >=20 >=20 > Let me put it this way: that behaviour, and those demos, have been=20 > around for years, some of them decades. IIRC, we've had a total of=20 > about one complaint about that, in all that time. OK. Did you want to change the demos and set the ranges in a few cases? = I mean, I have wondered in the past why some of the pm3d demos have a wh= ite area near the bottom of them. They do look better without the gap in= this case. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-06-15 15:00:19
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> 2) BUG 1503114 FIX: 1107709 plot [-1:1] x is plotted with >> asymmetric y-axis >=20 >=20 > I'm still just as opposed to this fix as I was when I first commented o= n=20 > the bug report. It's an attempt at fixing symptoms, and does so in the= =20 > wrong place. >=20 >> I picked a bug in the list and fixed it. =20 >=20 >=20 > Not really. You just hid it in a spot where it's harder to trigger. I'm still debating with myself if this is the case. >=20 > Floating-point rounding is tricky stuff. It's completely inevitable=20 > that sometimes, results will surprise people. All this patch does is=20 > move the surprise from a seemingly obvious place to a less obvious one.= =20 > An axis ending at 2.0000001 has no more business being artificially cu= t=20 > down to 2.0 than one ending at 2.001. I think it does in some cases, and depends on the range. I'll illustrate= with two ranges determined by the data input. 1) [1.9999999 : 2.0000001] 2) [-2.0 : 2.0000001] In the first case, yes definitely, the limits have no business being arti= ficially shrunk. However, in the second case I'm saying that cutting the upper limit inwar= d to 2.0 rather than rounding outward to 2.5 is not egregious because its= effect is beyond the resolution of the plot. That is the key point. Th= ere is enough slop in gnuplot's tic marks and line placement that 1e-6 is= irrelevant with respect to 0.5e0. (Just take a look at some of gnuplot'= s outputs for all.dem. Some times pm3d surfaces slightly overlap a line,= sometimes not, the thickness of a line may be several orders of magnitud= e than what would be discarded by rounding inward, etc.) One might claim that it is possible to zoom in on plots and hence we shou= ld retain [1.9999999 : 2.0000001]. But I think that isn't reliable. Som= e examples. If I zoom into a plot using gv, really zoom in, the thing sl= ows way down and may become unreliable because of arithmetic issues. We = also had a discussion once on X11 zooming. I thought one could zoom by c= hanging the scaling factor in the X11 window. This worked, but I then ag= reed with you that it is a fairly useless thing without a fresh, nicer re= plot with scale readjustment. >=20 > The current behaviour may not be free from surprises, but at least it's > correct: an autoscaled axis always contains all its inputs. Define correct when we are talking that scale of things. I think that is= the issue here. Do we expand the scale outward, perhaps further comprom= ising resolution? Or feel free to toss out something that is beyond the = resolution of any reasonable plotting device that can be viewed by the hu= man eye? In some sense related, I just put a patch on S.F. to illustrate some prob= lems with the function integration demo in bivariat.dem. There are some = noticeable effects overlooked there, one of them being consideration for = sample points not being exactly zero for a test x>=3D0. Yes, dealing with machine precision may not be a joy, but it probably sho= uld be done. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-06-15 16:42:54
|
Daniel J Sebald wrote: > One might claim that it is possible to zoom in on plots and hence we should retain [1.9999999 : 2.0000001]. I intended to say "retain [-2.0 : 2.0000001]" |
|
From: Petr M. <mi...@ph...> - 2006-06-16 12:57:17
|
>>> 2) BUG 1503114 FIX: 1107709 plot [-1:1] x is plotted with >>> asymmetric y-axis >> >> Floating-point rounding is tricky stuff. It's completely inevitable >> that sometimes, results will surprise people. All this patch does is >> move the surprise from a seemingly obvious place to a less obvious one. >> An axis ending at 2.0000001 has no more business being artificially cut >> down to 2.0 than one ending at 2.001. > > I think it does in some cases, and depends on the range. I'll illustrate > with two ranges determined by the data input. > > 2) [-2.0 : 2.0000001] > > In the first case, yes definitely, the limits have no business being artificially shrunk. What about rounding range limits to the nearest "nice value" in a range of 100*MachineEpsilon? --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-06-17 04:03:49
|
Petr Mikulik wrote: >>>> 2) BUG 1503114 FIX: 1107709 plot [-1:1] x is plotted with >>>> asymmetric y-axis >>> >>> >>> Floating-point rounding is tricky stuff. It's completely inevitable >>> that sometimes, results will surprise people. All this patch does is >>> move the surprise from a seemingly obvious place to a less obvious one. >>> An axis ending at 2.0000001 has no more business being artificially cut >>> down to 2.0 than one ending at 2.001. >> >> >> I think it does in some cases, and depends on the range. I'll >> illustrate with two ranges determined by the data input. >> >> 2) [-2.0 : 2.0000001] >> >> In the first case, yes definitely, the limits have no business being >> artificially shrunk. > > > What about rounding range limits to the nearest "nice value" in a range of > 100*MachineEpsilon? Well, yes that is an alternative. And it accounts, I think, for most of the problems that would likely arise because of some arithmatic error. I wouldn't mind seeing a formal use of "MachinePrecision". There is the definition "DBL_EPSILON". And it would be nice to have some form of epsilon defined, just like pi is defined, so that user can utilize it in function definitions. However, I still think that rounding to within 1/500 or 1/1000 the axis range--whatever might be beyond the resolution of the display--is a plausible strategy. Could even have a definable variable, visual_precision (default 0.001), meaning to round outward to within abs(max - min)*visual_precision. The user could then turn of the effect by setting visual_precision equal to 0. Anyway, range rounding should be a topic in the documentation and/or part of the "xrange" documentation somewhere. Dan |
|
From: <br...@ph...> - 2006-06-20 21:40:59
|
Daniel J Sebald wrote: >> Not really. You just hid it in a spot where it's harder to trigger. > > I'm still debating with myself if this is the case. Just think of it this way: at some point, the actual endpoint of the range *will* jump from 2.0 to, e.g., 2.5. With the existing code this happens exactly if the end of the data range is larger than 2.0. That's by far the clearest and most simple way of doing it. With the proposed modifications the jump would be elsewhere --- and with all the different suggestions being made, it's by now entirely unclear where that is. So the jump won't magically go away --- it just moves to a different position on the input axis. I refuse to see that as an improvement. Especially not if we can't even explain it clearly to each other, much less to unsuspecting users, where that new position is actually supposed to be, and why it should be exactly there. >> Floating-point rounding is tricky stuff. It's completely inevitable >> that sometimes, results will surprise people. All this patch does is >> move the surprise from a seemingly obvious place to a less obvious >> one. An axis ending at 2.0000001 has no more business being >> artificially cut down to 2.0 than one ending at 2.001. > > I think it does in some cases, and depends on the range. It depends on entirely too much, IMHO. > 1) [1.9999999 : 2.0000001] > > 2) [-2.0 : 2.0000001] > > In the first case, yes definitely, the limits have no business being > artificially shrunk. > > However, in the second case I'm saying that cutting the upper limit > inward to 2.0 rather than rounding outward to 2.5 is not egregious > because its effect is beyond the resolution of the plot. Maybe. But as I said, that just moves the problem elsewhere. There *will* be some threshold for which a data range of [-2.0: 2.0+delta] jumps from an auto-extended axis range of [-2:2.0] to [-2:2.5]. You say that delta=1e-7 should be below the threshold --- but that wilfully turns a perfectly valid data point into an out-of-bounds one. And at some point between delta=1e-7 and, say, delta=1e-2, the output range *will* jump to 2.5. Maybe that jump is at delta=1e-3 or at 1e-5, it doesn't really matter. It's still a jump, and somebody will have to explain to himself or a puzzled user why that range endpoint made such a huge jump. As is, that explanation is simple: the actual range was larger than 2.0, so gnuplot made room for that. Now you explain why your threshold is exactly where it ends up to be --- and why the same data, with the same settings, yield a different range endpoint on different terminal drivers. >> The current behaviour may not be free from surprises, but at least it's >> correct: an autoscaled axis always contains all its inputs. > > Define correct when we are talking that scale of things. We're talking about a plotting program. It's job is to put data onto the plot. Not outside of it. Not even by a small margin of error --- at least not on purpose. The whole job of autoscaling is to determine an axis range that contains all the input data points. Your proposed changes effectively break the single promise 'set autoscale' exists for. |
|
From: Daniel J S. <dan...@ie...> - 2006-06-20 22:36:41
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >>> Not really. You just hid it in a spot where it's harder to trigger. >> >> >> I'm still debating with myself if this is the case. >=20 >=20 > Just think of it this way: at some point, the actual endpoint of the=20 > range *will* jump from 2.0 to, e.g., 2.5. With the existing code this=20 > happens exactly if the end of the data range is larger than 2.0. That'= s=20 > by far the clearest and most simple way of doing it. With the proposed= =20 > modifications the jump would be elsewhere --- and with all the differen= t=20 > suggestions being made, it's by now entirely unclear where that is. >=20 > So the jump won't magically go away --- it just moves to a different=20 > position on the input axis. I refuse to see that as an improvement.=20 > Especially not if we can't even explain it clearly to each other, much=20 > less to unsuspecting users, where that new position is actually suppose= d=20 > to be, and why it should be exactly there. >=20 >>> Floating-point rounding is tricky stuff. It's completely inevitable=20 >>> that sometimes, results will surprise people. All this patch does is= =20 >>> move the surprise from a seemingly obvious place to a less obvious=20 >>> one. An axis ending at 2.0000001 has no more business being=20 >>> artificially cut down to 2.0 than one ending at 2.001. >> >> >> I think it does in some cases, and depends on the range. =20 >=20 >=20 > It depends on entirely too much, IMHO. >=20 >> 1) [1.9999999 : 2.0000001] >> >> 2) [-2.0 : 2.0000001] >> >> In the first case, yes definitely, the limits have no business being=20 >> artificially shrunk. >> >> However, in the second case I'm saying that cutting the upper limit=20 >> inward to 2.0 rather than rounding outward to 2.5 is not egregious=20 >> because its effect is beyond the resolution of the plot. =20 >=20 >=20 > Maybe. But as I said, that just moves the problem elsewhere. There=20 > *will* be some threshold for which a data range of >=20 > [-2.0: 2.0+delta] >=20 > jumps from an auto-extended axis range of [-2:2.0] to [-2:2.5]. You sa= y=20 > that delta=3D1e-7 should be below the threshold --- but that wilfully=20 > turns a perfectly valid data point into an out-of-bounds one. And at=20 > some point between delta=3D1e-7 and, say, delta=3D1e-2, the output rang= e=20 > *will* jump to 2.5. Maybe that jump is at delta=3D1e-3 or at 1e-5, it=20 > doesn't really matter. It's still a jump, and somebody will have to=20 > explain to himself or a puzzled user why that range endpoint made such = a=20 > huge jump. As is, that explanation is simple: the actual range was=20 > larger than 2.0, so gnuplot made room for that. Now you explain why=20 > your threshold is exactly where it ends up to be --- and why the same=20 > data, with the same settings, yield a different range endpoint on=20 > different terminal drivers. You are making a good point. Currently, the user sees the big jump and k= nows right away that his or her data goes beyond the range they may have = thought. Even thought they may not be able to see it. Very predictable = behavior. Just to clarify, I'm saying that delta is not chosen as a fixed value. I= 'm trying to relate that delta to the range. For example, let's choose T= OL to be tolerance and set that at 1/1000. Now, the formula would be delta =3D TOL * abs(xmax - xmin) and in this case would be delta =3D abs(2 - (-2)) * 1/500 =3D 0.004. So = if the value to be rounded outward is within -2.004 but not above the nex= t highest tic mark, the value is rounded to -2. Likewise, the same thing= that within 2.004 is rounded down to 2.0. Now, pick a range like [-1.9999:2.0001]. From the formula above, epsilon= now is 2e-7. There are only two valid concepts in my mind. 1) What I just described, which is ignore anything within (or beyond, wh= atever your viewpoint) a small fraction of the total range. Likely somet= hing so small it can't be resolved. 2) Ignore anything within the machine resolution (i.e., epsilon) or some= small multiple of machine resolution, what Petr pointed out. I'm fairly certain case 1 will catch any machine arithmetic rounding prob= lems. Case 2? Probably, but not as assured for some reason. Case 2 is predictable in the sense all it will catch is some rounding iss= ues. Case 1 *is* less predictable, but I think the concept is understand= able. Going back to your original point. The jump tells someone their data ext= ends beyond a tic, but in a perhaps imperceptable way. (We could do some= examples to test this.) I don't know what the preference would be, honestly. But there is a conc= ept or two there that seems not so confusing. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-20 23:12:41
|
May I propose that we just drop this patch [*], and put the
effort into discussion of more serious issues?
At a minimum, we need to resolve:
- Reconciling the docs and the code with regard to the various
flavors of missing/undefined data points
- Does Windows truly require the PostScript prolog files to
be moved back into the driver source?
- Finalize and include the "user-available GPVAL_*" patch,
#1488448, which I think is waiting on Hans-Bernhard's offer
to identify the appropriate variables for export from=20
fitting.
- The Makefiles and config files for the non-autobuild
platforms need to be checked for correctness and inclusion
of the newer configuration options.
And then there's the nuts-and-bolts requirement to go over the
full manual and make sure it is up to date in referring to=20
version numbers, available features, syntax examples, and so on.
It would also be nice if someone familiar with the fitting code
would comment on #1445064 "Gnuplot fitting improvements".
The description sounds reasonable, but I have not looked at
the patch itself, and I am not at all familiar with that part
of the code base.
Ethan
[*] The truth is, I already dropped it last week on the basis of=20
unfavorable comments on the mailing list.
Ethan
On Tuesday 20 June 2006 03:45 pm, Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
> > Daniel J Sebald wrote:
> >>> Not really. You just hid it in a spot where it's harder to
> >>> trigger.
> >>
> >> I'm still debating with myself if this is the case.
> >
> > Just think of it this way: at some point, the actual endpoint of
> > the range *will* jump from 2.0 to, e.g., 2.5. With the existing
> > code this happens exactly if the end of the data range is larger
> > than 2.0. That's by far the clearest and most simple way of doing
> > it. With the proposed modifications the jump would be elsewhere
> > --- and with all the different suggestions being made, it's by now
> > entirely unclear where that is.
> >
> > So the jump won't magically go away --- it just moves to a
> > different position on the input axis. I refuse to see that as an
> > improvement. Especially not if we can't even explain it clearly to
> > each other, much less to unsuspecting users, where that new
> > position is actually supposed to be, and why it should be exactly
> > there.
> >
> >>> Floating-point rounding is tricky stuff. It's completely
> >>> inevitable that sometimes, results will surprise people. All
> >>> this patch does is move the surprise from a seemingly obvious
> >>> place to a less obvious one. An axis ending at 2.0000001 has no
> >>> more business being artificially cut down to 2.0 than one ending
> >>> at 2.001.
> >>
> >> I think it does in some cases, and depends on the range.
> >
> > It depends on entirely too much, IMHO.
> >
> >> 1) [1.9999999 : 2.0000001]
> >>
> >> 2) [-2.0 : 2.0000001]
> >>
> >> In the first case, yes definitely, the limits have no business
> >> being artificially shrunk.
> >>
> >> However, in the second case I'm saying that cutting the upper
> >> limit inward to 2.0 rather than rounding outward to 2.5 is not
> >> egregious because its effect is beyond the resolution of the plot.
> >
> > Maybe. But as I said, that just moves the problem elsewhere.=20
> > There *will* be some threshold for which a data range of
> >
> > [-2.0: 2.0+delta]
> >
> > jumps from an auto-extended axis range of [-2:2.0] to [-2:2.5].=20
> > You say that delta=3D1e-7 should be below the threshold --- but that
> > wilfully turns a perfectly valid data point into an out-of-bounds
> > one. And at some point between delta=3D1e-7 and, say, delta=3D1e-2,
> > the output range *will* jump to 2.5. Maybe that jump is at
> > delta=3D1e-3 or at 1e-5, it doesn't really matter. It's still a
> > jump, and somebody will have to explain to himself or a puzzled
> > user why that range endpoint made such a huge jump. As is, that
> > explanation is simple: the actual range was larger than 2.0, so
> > gnuplot made room for that. Now you explain why your threshold is
> > exactly where it ends up to be --- and why the same data, with the
> > same settings, yield a different range endpoint on different
> > terminal drivers.
>
> You are making a good point. Currently, the user sees the big jump
> and knows right away that his or her data goes beyond the range they
> may have thought. Even thought they may not be able to see it. Very
> predictable behavior.
>
> Just to clarify, I'm saying that delta is not chosen as a fixed
> value. I'm trying to relate that delta to the range. For example,
> let's choose TOL to be tolerance and set that at 1/1000. Now, the
> formula would be
>
> delta =3D TOL * abs(xmax - xmin)
>
> and in this case would be delta =3D abs(2 - (-2)) * 1/500 =3D 0.004. So
> if the value to be rounded outward is within -2.004 but not above the
> next highest tic mark, the value is rounded to -2. Likewise, the
> same thing that within 2.004 is rounded down to 2.0.
>
> Now, pick a range like [-1.9999:2.0001]. From the formula above,
> epsilon now is 2e-7.
>
> There are only two valid concepts in my mind.
>
> 1) What I just described, which is ignore anything within (or
> beyond, whatever your viewpoint) a small fraction of the total range.
> Likely something so small it can't be resolved.
>
> 2) Ignore anything within the machine resolution (i.e., epsilon) or
> some small multiple of machine resolution, what Petr pointed out.
>
> I'm fairly certain case 1 will catch any machine arithmetic rounding
> problems. Case 2? Probably, but not as assured for some reason.
>
> Case 2 is predictable in the sense all it will catch is some rounding
> issues. Case 1 *is* less predictable, but I think the concept is
> understandable.
>
> Going back to your original point. The jump tells someone their data
> extends beyond a tic, but in a perhaps imperceptable way. (We could
> do some examples to test this.)
>
> I don't know what the preference would be, honestly. But there is a
> concept or two there that seems not so confusing.
>
> Dan
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Daniel J S. <dan...@ie...> - 2006-06-21 00:07:03
|
Ethan Merritt wrote: > May I propose that we just drop this patch [*], and put the > effort into discussion of more serious issues? > > At a minimum, we need to resolve: > > - Reconciling the docs and the code with regard to the various > flavors of missing/undefined data points It sounds as though we're willing to redefine behavior slightly on this, right? There is a more straightforward way of doing this and fairly easy fix. In fact, I'd propose that so long as we are going to fix this, go with multiple definitions set undefined "Inf" "-Inf" set missing "N/A" ?? set notnumber "NaN" right away. I think there is some utility to that. Controllable behavior of plotting based upon point class could be for the future. > - Does Windows truly require the PostScript prolog files to > be moved back into the driver source? Well, maybe not. But if there is any chance of too much confusion with the patch because of something we haven't tested much yet, perhaps move the code back into post.trm and immediately move it back out after 4.2. What is the amount of confidence at this point regarding the possibility of a lot of bug reports "postscript not viewable"? ... And how about bug [ 1488168 ]? Hans, I think that one is ready to go. Ethan and I can discuss and change mouse behavior after that (probably a simple change), or just leave it as is for 4.2. Dan |
|
From: <tim...@en...> - 2006-06-21 00:21:04
|
Daniel J Sebald wrote:
> Ethan Merritt wrote:
> =20
>
>> - Does Windows truly require the PostScript prolog files to
>> be moved back into the driver source?
>> =20
>
> Well, maybe not. But if there is any chance of too much confusion with=
the patch because of something we haven't tested much yet, perhaps move =
the code back into post.trm and immediately move it back out after 4.2.
>
> What is the amount of confidence at this point regarding the possibilit=
y of a lot of bug reports "postscript not viewable"?
> =20
With the current code, 99% of chance of getting the error "Can't find=20
PostScript prologue file" out-of-the-box when using the postscript=20
terminal on Windows and other non-Unix platforms.
Two alternatives :
1- Move them back to the source file (the GNUPLOT_PS_DIR environment=20
variable can be conserved for flexibility)
2- Use a platform-specific strategy :
* UNIX : let the code as it is now
* Windows : look for those files in share/Postscript/ relatively to=20
the executable path using getModuleFilename()
* others : include them in the source file at compile time
Timoth=E9e
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-06-21 01:50:54
|
On Tuesday 20 June 2006 07:21 pm, Timoth=E9e Lecomte wrote: > > =20 > With the current code, 99% of chance of getting the error "Can't find=20 > PostScript prologue file" out-of-the-box when using the postscript=20 > terminal on Windows=20 Is that because there is not an appropriate README file? How about if we change the message to: "Please copy your PostScript prolog files to <somewhere Windowish>" After all, it doesn't work "out of the box" on unix either.=20 You still have to set up your font paths and add environmental variables to your locally customized initialization files. > and other non-Unix platforms.=20 Do you mean because of the trailing '/' on the directory name? Other than that I don't see much difference. But yes, I should add conditional code for VMS that adds ':' rather than '/'. Does windows or os2 need it changed to '\'? > Two alternatives : > 1- Move them back to the source file (the GNUPLOT_PS_DIR environment=20 > variable can be conserved for flexibility) Huh? What does the environmental variable do, if the prolog is in the driver? > * others : include them in the source file at compile time I think you are over-generalizing. Why assume that it is an=20 issue for all non-unix systems? I'll report back on VMS, but I don't see why there should be a problem. And I doubt we=20 support anything less unix-like than VMS. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <br...@ph...> - 2006-06-21 20:26:22
|
Ethan A Merritt wrote: > On Tuesday 20 June 2006 07:21 pm, Timoth=E9e Lecomte wrote: >> With the current code, 99% of chance of getting the error "Can't f= ind=20 >> PostScript prologue file" out-of-the-box when using the postscript= =20 >> terminal on Windows=20 I wouldn't put the number as high as 99%, but yes, it's high. > Is that because there is not an appropriate README file? Not really. We do have one, and the information and techniques=20 described in it should suffice, if people actually used it (and gnupl= ot=20 was extended to use it in the relevant places). The key problem is a design decision made for wgnuplot ages ago, whic= h=20 is rather unusual for the Windows world: that we don't have a setup= =20 program. There has never been much of a need for such a thing before= ,=20 because gnuplot consisted of only two files (.exe and .hlp), and the = OS=20 provides the necessary link between those for us. But as soon as there are many files, it has to be ensured that the= =20 executable can find all the others. So far, gnuplot made do with= =20 environment variables, and it didn't strictly need any of them. > How about if we change the message to: >=20 > "Please copy your PostScript prolog files to <somewhere Windowish>" The problem is not that the files aren't in that <somewhere Windowish= >=20 place --- the problem is such a place to store files in doesn't exist= . The only central, truly "Windowsish" place to store anything is the= =20 Registry, and it can't hold files. It only contains strings, like th= e=20 Unix environment does, but it hides them in a file-system like hierar= chy=20 (the master copy of the environment itself is stored in the registry,= =20 too, these days) Windows program installations differ fundamentally from Unix in sever= al=20 ways. There is no "Windowish" place to install extra files private t= o a=20 program. Packages have to pick all such places themselves, and they= =20 have to store the information needed to find those places in the=20 registry. The usual layout is to put all files (including the=20 executable) below a single directory that is in a place choosable by = the=20 user at install time (defaulting to "c:\program files\[program name]"= ). |
|
From: <tim...@en...> - 2006-06-21 07:01:15
|
Ethan A Merritt wrote: > On Tuesday 20 June 2006 07:21 pm, Timoth=E9e Lecomte wrote: > =20 >>> =20 >>> =20 >> With the current code, 99% of chance of getting the error "Can't find=20 >> PostScript prologue file" out-of-the-box when using the postscript=20 >> terminal on Windows=20 >> =20 > > Is that because there is not an appropriate README file? > How about if we change the message to: > > "Please copy your PostScript prolog files to <somewhere Windowish>" > =20 The problem is this "somewhere". What would it be ? On Windows, it=20 should be a path relatively to the executable, and the code to retrieve=20 the absolute path from the path of the executable has yet to be written. > After all, it doesn't work "out of the box" on unix either.=20 > You still have to set up your font paths and add environmental > variables to your locally customized initialization files. > =20 Well, you do './configure - make - make install' and it works, "out of=20 the box", in my opinion. Then, you can customize, but that's optional. >> and other non-Unix platforms.=20 >> =20 > > Do you mean because of the trailing '/' on the directory name? > Other than that I don't see much difference. But yes, I should > add conditional code for VMS that adds ':' rather than '/'. > Does windows or os2 need it changed to '\'? > =20 I have not even thought about that. I just wanted to distinguish=20 platforms where absolute paths can be determined at compile time, and=20 platforms where it is not possible, such as Windows. I just assume there=20 are others of this type. >> Two alternatives : >> 1- Move them back to the source file (the GNUPLOT_PS_DIR environment=20 >> variable can be conserved for flexibility) >> =20 > > Huh? What does the environmental variable do, if the prolog > is in the driver? > =20 Maybe to use custom prologs that you have modified from the originals=20 and installed by hand (so that you know where they are). What was your=20 first intention ? Reduce executable size ? Make post.trm easier to read ? >> * others : include them in the source file at compile time >> =20 > I think you are over-generalizing. Why assume that it is an=20 > issue for all non-unix systems? I'll report back on VMS, but > I don't see why there should be a problem. And I doubt we=20 > support anything less unix-like than VMS Maybe I am. I think it is probably the first place in gnuplot where external files=20 are needed _on all platforms_. This issue has never happened on Windows (some needed files are just=20 placed in the directory of the . On OS/2, pm.trm looks for gnupmdrv.exe Where the X11 terminal is available, x11.trm looks for gnuplot_x11. Nowhere we have a code that has been written for all platforms. Timoth=E9e |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-21 17:18:17
|
On Wednesday 21 June 2006 02:01 am, Timoth=E9e Lecomte wrote: > Ethan A Merritt wrote: > > How about if we change the message to: > > > > "Please copy your PostScript prolog files to <somewhere Windowish>" > > The problem is this "somewhere". What would it be ? On Windows, it > should be a path relatively to the executable, and the code to > retrieve the absolute path from the path of the executable has yet to > be written. (Please forgive my total inexperience with Windows. I'm working off what I know from running MSOffice under Wine) Why should it be a path relative to the executable? Can't it go in C:\Applications\gnuplot\ or something to that effect? =20 I was under the impression that all Windows systems had a conventional set of directory trees under C: =46ailing that, isn't the point of the registry file that you can register where individual programs keep their data files?=20 Is there not a "register <prog-name> <directory-tree>" command of some sort that enters this information in the registry? =46or instance, in the dummied-up Windows registry file that Wine uses, I see these entries for Acrobat: [Software\\Adobe\\CommonFiles] 1080673271 "AdobeHome"=3D"C:;" I have no idea what the magic number means, but it seems clear that the "AdobeHome" entry tells the Adobe programs where to base their data files. Can't we add an entry something like:=20 [Software\\Gnuplot\\CommonFiles] <magic-number-foo> "PS_DIRECTORY"=3D"C:Gnuplot\;" I would imagine that this is basically what an installer does, but we might not need the whole installer. =20 > I think it is probably the first place in gnuplot where external > files are needed _on all platforms_. > This issue has never happened on Windows (some needed files are just > placed in the directory of the . > On OS/2, pm.trm looks for gnupmdrv.exe > Where the X11 terminal is available, x11.trm looks for gnuplot_x11. > Nowhere we have a code that has been written for all platforms. I hate to use it as an example, since I've been complaining about it for other reasons (need to install at least part of TeX), but.... It seems from the code that the "kpsextend" path searching is used by all platforms to find the location of fonts. =20 Could it also be used for this purpose? That is, put the prolog files in the same directory as the PostScript fonts (since we're going to need them anyhow) and use "kpsextend" to find them? That puts us right back in the midst of the argument about whether it is reasonable to require TeX in order to install gnuplot, but it does seem to be a platform-independent solution. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <br...@ph...> - 2006-06-21 19:41:05
|
Daniel J Sebald wrote: > Hans-Bernhard Br=F6ker wrote: >> Daniel J Sebald wrote: > My point here is that I think there is an inherent amount of visual= =20 > plotting information that a person can view. I'm confortable with = the=20 > idea of limits on resolution. The idea of such limits is obviously correct. The problems start whe= n=20 you try to fix those limits to an actual value, and use it. The choi= ce=20 is so hard because there is no single such limit --- its choice is= =20 arbitrary. > The idea would be to reasonably catch the situation where the tic= =20 > interval is computed as 1/3 =3D 0.33333333333 and then the round ou= tward=20 > test does something (after arithmetic) like deciding 0.99999999999= 9 <=20 > 1.0 because of rounding. That is a non-issue, because autoscaling never picks a tick interval = of=20 1/3. It picks power-of-ten multiples of 1, 2 or 5. > OK. Did you want to change the demos and set the ranges in a few= =20 > cases? =20 I'm not even convinced that any change is necessary for this at all. A few tweaks to the demos would be about the maximum I would see as= =20 useful here. |
|
From: Daniel J S. <dan...@ie...> - 2006-06-21 20:09:53
Attachments:
pm3dexample.png
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> Hans-Bernhard Br=F6ker wrote: >> >>> Daniel J Sebald wrote: >=20 >=20 >> My point here is that I think there is an inherent amount of visual=20 >> plotting information that a person can view. I'm confortable with the= =20 >> idea of limits on resolution. >=20 >=20 > The idea of such limits is obviously correct. The problems start when=20 > you try to fix those limits to an actual value, and use it. The choice= =20 > is so hard because there is no single such limit --- its choice is=20 > arbitrary. I suppose. There is a typical visual resolution, but nothing to cover al= l resolutions. >> The idea would be to reasonably catch the situation where the tic=20 >> interval is computed as 1/3 =3D 0.33333333333 and then the round outwa= rd=20 >> test does something (after arithmetic) like deciding 0.999999999999 <= =20 >> 1.0 because of rounding. >=20 >=20 > That is a non-issue, because autoscaling never picks a tick interval of= =20 > 1/3. It picks power-of-ten multiples of 1, 2 or 5. >=20 >> OK. Did you want to change the demos and set the ranges in a few case= s? =20 >=20 >=20 > I'm not even convinced that any change is necessary for this at all. > A few tweaks to the demos would be about the maximum I would see as=20 > useful here. That is what I'm suggesting. Below is an example of something for the lo= ngest time I couldn't understand, i.e., why the yrang here is as it is. = The y range could be forced to make it look better. However, if what you say above is true, something seems odd. This should= be a clear case where autoranging on y comes out as [1:2]. The tic inte= rvals are 0.2. (I would think, anyway, given that (2-1)/5 =3D 0.2. No a= rithmetic problems there.) And the data in the file is exactly on (0,1) = (1,1) and (2,1). What is happening there? PM3D.DEM CODE reset set title "Demo for clipping of 2 rectangles comes now. The xrange is [0:= 2]..." set pm3d; set palette set pm3d map set xrange [0:2] splot 'clip14in.dat' CLIP14IN.DAT # demo for set pm3d [clip1in | clip4in] 0 1 1 1 1 2 2 1 3 0 2 1 1 2 2 2 2 3 |
|
From: <br...@ph...> - 2006-06-21 20:41:51
|
Ethan Merritt wrote: > Why should it be a path relative to the executable? > Can't it go in C:\Applications\gnuplot\ > or something to that effect? No. It has to be in some place chosen by the user, at installation time. > I was under the impression that all Windows systems had a > conventional set of directory trees under C: Yes. But that's all they are: "conventional". There's exactly nothing special about them. > Failing that, isn't the point of the registry file that you can > register where individual programs keep their data files? Yes, but automatically writing into that is what Windows programs need those pesky "installers" for. gnuplot never had any so far. > Is there not a "register <prog-name> <directory-tree>" command of > some sort that enters this information in the registry? No. The minimum you need is a .reg file, and the contents of that file have to be edited before it can be merged into the main registry. |
|
From: <br...@ph...> - 2006-06-21 21:16:16
|
Daniel J Sebald wrote: > That is what I'm suggesting. Below is an example of something for the > longest time I couldn't understand, i.e., why the yrang here is as it > is. The y range could be forced to make it look better. Well, guess what: I just tried that example myself (OpenWatcom build for MS Windows, terminal windows), and got nothing like what you got in that PNG. The yrange I got was [1:2], exactly as expected. > What is happening there? Whatever it is --- it's not happening here where I sit and type this ;-) You'll have to debug that yourself, I think. |
|
From: Daniel J S. <dan...@ie...> - 2006-06-21 22:17:56
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> That is what I'm suggesting. Below is an example of something for the= =20 >> longest time I couldn't understand, i.e., why the yrang here is as it=20 >> is. The y range could be forced to make it look better. >=20 >=20 > Well, guess what: I just tried that example myself (OpenWatcom build fo= r=20 > MS Windows, terminal windows), and got nothing like what you got in > that PNG. The yrange I got was [1:2], exactly as expected. >=20 >> What is happening there? >=20 >=20 > Whatever it is --- it's not happening here where I sit and type this ;-= ) Good grief. I just looked at the "reference", i.e., http://gnuplot.sourceforge.net/demo_4.1/pm3d.html and that too looks correct. (However, the 3D example right after those, = with the title "pm3d explicit mode" doesn't have the range [-3:3] [-3:3] = as I think it should.) I've seen this on my machine for at least a year, if not years! > You'll have to debug that yourself, I think. Sounds CPU dependent; I'll locate an oscilloscope. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-06-22 05:49:51
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> That is what I'm suggesting. Below is an example of something for the= =20 >> longest time I couldn't understand, i.e., why the yrang here is as it=20 >> is. The y range could be forced to make it look better. >=20 >=20 > Well, guess what: I just tried that example myself (OpenWatcom build fo= r=20 > MS Windows, terminal windows), and got nothing like what you got in > that PNG. The yrange I got was [1:2], exactly as expected. >=20 >> What is happening there? >=20 >=20 > Whatever it is --- it's not happening here where I sit and type this ;-= ) >=20 > You'll have to debug that yourself, I think. I still can't believe what I'm seeing. Coming into the round_outward() f= unction, the following two lines of code: fprintf(stderr, "FLOOR %d\n", (int)floor(input / tic)); fprintf(stderr, "FLOOR %d\n", (int)floor(input / tic)); produce: FLOOR 4 FLOOR 5 I assume most people are using a more recent version of gcc than I am: Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs Configured with: ../configure --prefix=3D/usr --mandir=3D/usr/share/man -= -infodir=3D/usr/share/info --enable-shared --enable-threads=3Dposix --dis= able-checking --wiith-system-zlib --enable-__cxa_atexit --disable-libunwi= nd-exceptions --enable-java-awt=3Dgtk --host=3Di386-redhat-linux Thread model: posix gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-06-22 06:06:21
|
Ethan A Merritt wrote: >>Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs >>gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) > > > Ah, Redhat. They have a very bad track record for shipping > bleeding-edge compiler versions that are, in fact, quite broken. Well, that solves that issue. Really set off a debate, didn't it? Sorry about all that confusion. Dan |
