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

Re: Bug #1503114

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

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

Re: Bug #1503114

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

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]"

Re: [ 1447277 ] Multiplot/palette/X11/Postcript

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

On Thursday 15 June 2006 12:03 am, Daniel J Sebald wrote:
> 
> I'm thinking maybe we should have a scheme in X11 where each 
> subplot be its own X window having its own colormap.
> So, that would be my proposition for this.  
> Create some kind of gnuplot_x11 pipe command like "layer" that 
> will put another x11 window on top of the base window for each subplot.  


I think it would be more useful if you would pitch in and
help fix the relatively minor glitches holding up a 4.2
release.   Re-designing x11 is way outside the scope of
this, and better left to post-release discussion of
"where do we go next?".

The bottom line seems to be that this bug is not fixable
on a 4.2 timeline. I will mark it as "won't fix".

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

Re: Bug #1503114

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

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

Re: Build problem

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

Juergen Wieferink wrote:
> Hi,
> 
> ./prepare gives me the following error message:
> 
> ============================================================================
> configure.in:243: error: possibly undefined macro: AC_MSG_WARN
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> 
> Some part of the preparation process failed.
> Please refer to INSTALL for details.
> ============================================================================

I don't see that happening here (same versions you used, on Cygwin, with 
freshly cvs-updated sources).  There are some Warnings, but they all 
only concern warnings from Cygwin-installed stuff in /usr/share/aclocal.

This is in a tree that has been built in before, though.  But since the 
problem is in configure.in processing by autoconf, which is done 
unconditionally by 'prepare', that shouldn't make a difference.

> I use autoconf-2.59 and automake-1.9.6, which seem to be the newest
> versions available.  This happens with a freshly checked out local
> copy.  Are there any other autotools which need to be up to date?

I don't think so.

> If I use a .tar.gz from another computer (make dist) on the same
> platform, ./configure and make && make install work fine.

No surprise --- they have nothing to with autoconf failing on configure.in.

Bug #1503114 (was: Re: gnuplot 4.1 and imagesc)

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

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.

Build problem

[Juergen W. <wie...@fr...>]

Hi,

./prepare gives me the following error message:

============================================================================
configure.in:243: error: possibly undefined macro: AC_MSG_WARN
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Some part of the preparation process failed.
Please refer to INSTALL for details.
============================================================================

I use autoconf-2.59 and automake-1.9.6, which seem to be the newest
versions available.  This happens with a freshly checked out local
copy.  Are there any other autotools which need to be up to date?

If I use a .tar.gz from another computer (make dist) on the same
platform, ./configure and make && make install work fine.


Juergen

Re: 4.2 priority & depth patch

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

On Wednesday 14 June 2006 02:29 pm, Petr Mikulik wrote:
> 
> Further, is there a demo?

Demo now up at

    http://gnuplot.sourceforge.net/demo_4.1/hidden2.html


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

Re: palette assignment

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

Ethan Merritt wrote:
> On Wednesday 14 June 2006 02:56 pm, Daniel J Sebald wrote:
> 
>>Ethan Merritt wrote:
>>
>>>On Wednesday 14 June 2006 12:53 pm, you wrote:
>>>
>>>>Oh, it would be nice to speed up the palette assignment.  Something
>>>>just isn't right with those demos that use pm3d; takes forever,
>>>>computer speaking.
>>>
>>>[shrug]  I doubt that it matters for any real-world case.
>>
>>Well, the real issue is the reallocating of the palette
>>unnecessarily.
> 
> 
> I am not following you.  The demo plots that 'take forever' are in
> fact changing the palette with each plot. That is the point of the
> demo, right?  So these palette initializations *are* necessary.

Half of pm3d.dem, yes.  However, there are many plots where the palette is not change from the previous plot.  An especially bad example is the last in pm3d.dem.  In that demo are 8 separate plots, all of which use the same palette.  Hit return on that plot and watch the "allocating colors..." message keep popping up.  I added a few lines of fprintf's to show when PaletteMake is called and when the palette tests out to be the same.  Here is the result for that particular plot:


Plot by pm3d algorithm draws quadrangles filled with color calculated from
the z- or color-value of the surrounding 4 corners. The following demo shows
different color spots for a plot with very small number of quadrangles (here
rectangular pixels). Note that the default option is 'mean'.
make palette
max_colors = 512
SAME PALETTE
make palette
max_colors = 512
SAME PALETTE
make palette
max_colors = 512
SAME PALETTE
make palette
max_colors = 512
SAME PALETTE
make palette
max_colors = 512
SAME PALETTE
make palette
max_colors = 512
SAME PALETTE
make palette
max_colors = 512
SAME PALETTE
Hit return to continuemake palette
max_colors = 512
SAME PALETTE

Re: palette assignment

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

On Wednesday 14 June 2006 02:56 pm, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> > On Wednesday 14 June 2006 12:53 pm, you wrote:
> >>Oh, it would be nice to speed up the palette assignment.  Something
> >>just isn't right with those demos that use pm3d; takes forever,
> >>computer speaking.
> >
> > [shrug]  I doubt that it matters for any real-world case.
>
> Well, the real issue is the reallocating of the palette
> unnecessarily.

I am not following you.  The demo plots that 'take forever' are in
fact changing the palette with each plot. That is the point of the
demo, right?  So these palette initializations *are* necessary.

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

Re: palette assignment

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

Ethan Merritt wrote:
> On Wednesday 14 June 2006 12:53 pm, you wrote:
> 
>>Oh, it would be nice to speed up the palette assignment.  Something
>>just isn't right with those demos that use pm3d; takes forever,
>>computer speaking.
> 
> 
> [shrug]  I doubt that it matters for any real-world case.
> But if you want to figure out where the time is going, I think
> you had best start profiling the executable.

Well, the real issue is the reallocating of the palette unnecessarily.  I think we fixed this for the mouse redraw, but there are some loose ends.

The problem is these make_palette()'s scattered throughout whenever there is a plot element that needs the palette, e.g.

	can_pm3d = is_plot_with_palette() && !make_palette()

   if (make_palette() || !term->set_color) {

All that really should be here is something called "valid_palette()", i.e.,

	can_pm3d = is_plot_with_palette() && valid_palette()

   if (valid_palette() || !term->set_color) {

I still contend that the only time that make_palette() should be done in the core is when

1) a "set palette" is explicitly commanded
2) whenever a "set term" is done (because the palette could have changed a lot while "connected" with a different terminal)

Now, if a "set term x11" is inherent in initialization then there is no need to explicitly initialize the palette.

When "make_palette()" is done, a variable should be set for which

int valid_palette(void)
{
 return palette_set_successfully;
}

can be used.

If a particular terminal needs to keep reissuing the palette (as we've concluded that the PostScript term should do for proper post-usage in viewers) then that is the terminal drivers responsibility.

Dan


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: 4.2 priority & depth patch

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

On Wednesday 14 June 2006 02:29 pm, Petr Mikulik wrote:
>
> There is my comment from 2005-06-21 how to put (at least) its
> cosmetic changes into cvs. Have you commited them at least? It looks
> like you have not pushed this patch too strongly.

Petr:

I've modified the original patchset to use your suggested
'set pm3d de$pthorder'.  The code itself is ready for cvs.

> Further, is there a demo?

The interlocking tori in the last plot of 'surface2.dem'
do nicely as a demo.

But it still needs a section for the docs.

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

Re: 4.2 priority & depth patch

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

> Some reasons why I'd like this beeing raised to priority 1:

you mean 9, the highest?

> 1. works better than existing pm3d methods which assume ordered data,
>   so the depth method is a method which can be turned on by default
>   while the other methods will produce junk for unordered data and
>   also especially for data generated by parametric plots.
>
> 2. another postponement will add more work to include it again and again
>   into current gnuplot versions, therefore makes it more likely that
>   the patch will finally die.
>
> A personal note: actually the absence of this patch in gnuplot is the main
> reason why I don't upgrade gnuplot!

There is my comment from 2005-06-21 how to put (at least) its cosmetic 
changes into cvs. Have you commited them at least? It looks like you have 
not pushed this patch too strongly.

Further, is there a demo?

---
PM

integration approximation demo in bivariat.dem

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

Paging through all.dem, something caught my eye in the bivariat.dem demo.  It's not of critical importance; after all, gnuplot is about plotting not applications.

The first example is of approximating integration of a function.  Unfortunately it appears to be a bad approximation.  Attached is a PNG of the plot.  Note how the integral approximation strangely drifts downward as x tends to +5.  This is an integral of a strictly positive function!

Anyway, given the formula for approximation (i.e., via rectangles), one has to conclude it is a sampling sort of thing.

So

1) I changed the number of samples so that x=0 ends up being one of the samples.  That corrected the slow drift away from the asymptote.

2) ... but introduced a problem where gnuplot's choice of samples and the x<=0 test caused a strange artifact.  To fix that, I used x<=epsilon.

3) ... and there still remained an offset of delta/2 due to the integration process, so I added in the appropriate offset.

See the attached PNG and diff files for an idea of the needed changes.

Anyway, do we want to fix these sorts of things or just live with it?

Dan

Re: 4.2 priority & depth patch

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

On Wednesday 14 June 2006 02:10 am, Dr. Johannes Zellner wrote:
>
> Some reasons why I'd like this beeing raised to priority 1:

It seems my automated scheme to elicit comments is working :-)

OK. This one can go to cvs without further change.
The April version still applies with no error.

As discussed previously, I would still like the option
to sort these pm3d rectangles jointly with labels and arrows.
But that would involve a different code path altogether, and
adding your version now does not preclude offering a variant
triggered by 'set hidden3d' at some later date.

	Ethan


>
> 1. works better than existing pm3d methods which assume ordered data,
>    so the depth method is a method which can be turned on by default
>    while the other methods will produce junk for unordered data and
>    also especially for data generated by parametric plots.
>
> 2. another postponement will add more work to include it again and
> again into current gnuplot versions, therefore makes it more likely
> that the patch will finally die.
>
> A personal note: actually the absence of this patch in gnuplot is the
> main reason why I don't upgrade gnuplot!
>
> Best wishes,

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

Re: the ConTeXt terminal

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

Mojca Miklavec wrote:
> On 6/14/06, Daniel J Sebald wrote:
> 
>> Mojca,
>>
>> Is there a web page for ConTeXt somewhere?
> 
> 
> http://wiki.contextgarden.net

Ah, so it is similar to LaTeX in many ways with perhaps a slight variation in syntax and improved features.  Math formatting looks very similar to LaTeX.  The examples on the Wiki page look good.

What is the approach your are taking?  I see there is a means to import external graphics into ConTeXt.  The power of Xfig and gnuplot, in my mind, is the ability to have combined LaTeX and PostScript, i.e., the math format and font characteristics native to LaTeX typesetting intermixed with the far superior graphical elements of PostScript.  Is that what you are aiming for in ConTeXt as well?

Dan

Re: the ConTeXt terminal

[Mojca M. <moj...@gm...>]

On 6/14/06, Daniel J Sebald wrote:
> Mojca,
>
> Is there a web page for ConTeXt somewhere?

http://wiki.contextgarden.net

> I see the discussion list and a program called PRAGMA that uses ConTeXt.

PRAGMA is the name of the author's company (he develops it for his
company, but helps other users a lot).

> Does ConTeXt have a graphics engine beyond TeX's rather limited graphics capabilities?

Yes and no. It's still based on TeX (going to its limits though and
constantly requesting/developing new functionality of pdfTeX), but it
has a rich set of macros and perl/ruby scripts which do some "magic"
with metapost (extension to metafont).

See http://www.pragma-ade.com/general/manuals/metafun-s.pdf (or any
cover of the manuals listed on http://www.pragma-ade.com/overview.htm)

> I'd like to get a feeling for how ConTeXt fits in with TeX and its related programs.

I would say that it (mis)uses pdfTeX to much greater extent than LaTeX
does, although LaTeX has much more packages and much more text
editors/magazines support/use LaTeX. ConTeXt is a kind of
revolutionair. It goes to the very limits / uses the newest
technologies / might be full of bugs (but once reported they usualy
get fixed within a day) / uses consistent layout / is very centralized
(one mailing list where the author himself is active) / users'
requests are often fullfilled (in LaTeX you depend on yourself: you
can make your own package, but can't add some functionality to the
existing core) / has very bad documentation (even though it's dozens
of megabytes, most things are undocumented: people read sources) / if
Hans quits, ConTeXt might die.

It has both its pros and cons ... so take the above words with a
reserve, since I might have too good opinion about it and it's
author[s].

Mojca

4.2 priority & depth patch

[Dr. J. Z. <joh...@ze...>]

Hello,

[from the sf patches]
> In preparation for a code freeze and the run-up to a release of
> version 4.2, existing bugs and patchsets are being prioritized.
> 
> This patchset is not on my (sfeam) list for inclusion in 4.2 and
> is therefore being marked as priority 2.
> 
> Note that this does not mean it is a bad patch, or that it won't
> be incorporated into cvs after 4.2 is released.  We can
> re-evaluate priorities after 4.2 is out.
> 
> If you want to argue for immediate reconsideration - go right
> ahead; but do so quickly!
> 
>  Ethan Merritt

Some reasons why I'd like this beeing raised to priority 1:

1. works better than existing pm3d methods which assume ordered data,
   so the depth method is a method which can be turned on by default
   while the other methods will produce junk for unordered data and
   also especially for data generated by parametric plots.

2. another postponement will add more work to include it again and again
   into current gnuplot versions, therefore makes it more likely that
   the patch will finally die.

A personal note: actually the absence of this patch in gnuplot is the main
reason why I don't upgrade gnuplot!

Best wishes,

-- 
Johannes

Re: the ConTeXt terminal

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

Mojca,

Is there a web page for ConTeXt somewhere?  I see the discussion list and a program called PRAGMA that uses ConTeXt.

Does ConTeXt have a graphics engine beyond TeX's rather limited graphics capabilities?  I'd like to get a feeling for how ConTeXt fits in with TeX and its related programs.

Thanks,

Dan

the ConTeXt terminal

[Mojca M. <moj...@gm...>]

Hello,

last time when Ethan mentioned the 4.2 release again, I submitted the
code for the ConTeXt terminal to the patches, but as I supposed it's
not that obvious how to test it since one has to install ConTeXt first
(and hope for proper system settings and no bugs in my code or ConTeXt
itself).

If you freeze the code next week, I can't fix everything properly, but
if you plan to release it in a month or so, I can try to finish it by
then if you are ready to take the terminal into account for the
release.

The whole point is that the terminal is pretty independent of Gnuplot
itself (i.e. rendering of graphics is done outside of gnuplot, the
terminal only "[de]optimizes" the code). For example, the linetype
only outputs
    gp_set_linetype($linetype);
the point only outputs
    gp_point($x,$y,$pointtype);
and the rest is taken care of outside of gnuplot and can be modified
rather quickly if a bug is spotted (serious bugs might be such as the
problem with unproperly free-d "header" when I copied the code from
epslatex, or some complex feature like "3D"; other bugs are not
exluded either, but most probably most bugs lie outside of C source
itself)

Many bugs have been fixed in ConTeXt after I complained about
non-working gnuplot module and quite some things are being improved
constantly in both ConTeXt and pdfTeX which will hopefully speed up
everything. (TeX was not made with graphics in mind, so compiling the
output from ConTeXt terminal is currently pretty slow and often runs
out of TeX memmory.) But just today I got a fix from the developer
that speeds up compilation time for approximately 4 times.

I'm not so good in programming, but I tried to do thing as flexible as
possible, so that the terminal depends on the gnuplot binary as little
as possible. Further development and finetuning might be added any
time in ConTeXt itself then.

What I'm ready to do in the pretty near future (ie. things without
which the terminal may not be added to the repository):
- finish implementation of palettes
- [not critical] do some simple "set term context size Xcm,Ycm", most
probably using Ethan's parse_size
- [important, not much work] complete the help and clean the source
- [thinking, not really implementation problem] change the beginning
and end of files, so that I can assure backward-compatibility later
- [important] sligthly patch text labels
- parsing font size for determining HCHAR, VCHAR

Something rather important is also an option to split labels from
graphics for efficiency, but I'll sacrifice that if I run out of time.

Things to be left for later:
- "with image" (I have to wait for a new pdftex primitive or do some
postprocessing if I want to implement it efficiently)
- more robust guessing of label widths and heights
- do something similar as LaTeX+PostScript merge and add option to use
MetaPost or PostScript as background image where only ConTeXt labels
and/or would be used
- ...

Lots of things and improvements are still to be done outside the
binary, but I can do that any time later.

Is adding that terminal stil doable for the 4.2 release?

Thanks a lot,
    Mojca

Re: bin_hook.o and binary.o in makefile.all

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

Timoth=E9e Lecomte wrote:

> You add in configure.in, just after the "if test=20
> "$enable_binary_data_file" =3D yes ... fi" code :
>=20
>   AM_CONDITIONAL(BUILD_BINARY_C, test "$enable_binary_data_file" =3D ye=
s)
>=20
> And in src/Makefile.am, you add :
>=20
>    if BUILD_BINARY_C
>        gnuplot_SOURCES +=3D binary.c
>    endif
> =20
> This is (one of) the standard way(s) to do conditional compilation=20
> according to the autotools doc.

A-ha!  Thank you...

Patch on SourceForge to rid bin_hook.c.

Dan

Re: Arrow color behavior

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

Ethan Merritt wrote:
> On Tuesday 13 June 2006 10:34 am, Daniel J Sebald wrote:
> 
>>Should arrow color behave similar to text color rather than behaving
>>like plot line color?  That is, I'd think that the default arrow
>>color should be black.  
> 
> 
> I get black arrows on my machines.
> I don't know what you've done to get red arrows.
> There may be a bug somewhere, but I'm not sure where to look for it.
> Do you get red arrows for all terminal types?

Yes, red arrows on the terminals I've checked, anyway.  You get black arrows?  I will investigate.

Dan

Re: Arrow color behavior

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

On Tuesday 13 June 2006 10:34 am, Daniel J Sebald wrote:
> Should arrow color behave similar to text color rather than behaving
> like plot line color?  That is, I'd think that the default arrow
> color should be black.  

I get black arrows on my machines.
I don't know what you've done to get red arrows.
There may be a bug somewhere, but I'm not sure where to look for it.
Do you get red arrows for all terminal types?

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

Re: gnuplot 4.1 and imagesc

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

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

Arrow color behavior

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

Should arrow color behave similar to text color rather than behaving like plot line color?  That is, I'd think that the default arrow color should be black.  If I understand arrows correctly, they are mostly for annotation although they can be used for many things like dotted lines to show a boundary, etc.

That would avoid red arrows (when not specifying any "rgb" color) by default.  In working with arrows I noticed that behavior then stepping through all.dem I noticed some other examples I hadn't notice before.  Cases where I think black arrow lines would work better than red arrow lines.

Dan