gnuplot development

On Wed, 28 Sep 2005, Ethan Merritt wrote:

> There are two problems with the "set ticslevel" command.
> 1) It isn't easy to do in a script, since you don't necessarily
> know in advance what are the values of YMIN and YMAX
> 2) It breaks anyhow if you later change zrange.

I suppose the ticslevel command could be "adapted" to take absolute
coordinates. Something like:

set ticslevel relative 0.5  # works as before
set ticslevel absolute 0    # is a z-value for the XY-plane

The relative keyword would of course be optional. "absolute" could be
"zvalue" or simply "z", and "zmin" and "zmax" would be nice shortcuts for 
set ticslevel 0 and set ticslevel 1 (or is it -1?)

It does strike me that the name "ticslevel" is not the most descriptive of
what it does. I think I've had to look it up on more than one occasion and
always start with things like "offset" first.

> I want a new command that does the equivalent of the 8 commands above, 
> except that it bypasses the existing "set ticslevel" mechanism in
> favor of pinning the X/Y plane at Z=0.

you mean a single command that does all of the above? That seems like a
good idea, because that would seem to be a sequence of commands that would
frequently come together. Are there other examples? I guess the 2D
equivalent?

Something like:

set plotstyle axes
set plotstyle bordered

which could be expanded later to include other "popular" styles

set plotstyle excel

maybe?

> It's not clear to me whether this would fit in as a variant of 
> some existing command, or whether it would need a new one of its own.
> Possibilities include
> 
> 	set view axes

doesn't that conflict slightly with the existing use of "view"



This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

On Thursday 29 September 2005 03:00 am, Robert Hart wrote:
> you mean a single command that does all of the above? 

Yes.

> Are there other examples? I guess the 2D equivalent?

"set view map" is an example.
That was why I considered extending it to "set view {map} {axes}".

The v4.0 docs say:
 `set pm3d map` is an abbreviation for 
 `set pm3d at b; set view map; set style data pm3d; set style func pm3d`.
 It is used for backwards compatibility, when `set view map` was not available.


> Something like:
> 
> set plotstyle axes
> set plotstyle bordered

That's a possibility.  Although "plotstyle" is likely to be 
misunderstood as referring to dots/points/lines/boxes/etc

> which could be expanded later to include other "popular" styles
> 
> set plotstyle excel

Do I want to know what this looks like?  I hope you don't mean
little pseudo-3D shaded skyscrapers that stand in for simple
vertical lines or rectangles. But yes, I can imagine defining a
number of common settings for the axes, borders, view angle, and so on.


I'm currently leaning in favor of
	set zeroaxis {only}
or	set zeroaxis {noborder}


-- 
Ethan A Merritt       merritt@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

On Thu, 29 Sep 2005, Ethan Merritt wrote:

> On Thursday 29 September 2005 03:00 am, Robert Hart wrote:
>
> > Something like:
> >
> > set plotstyle axes
> > set plotstyle bordered
>
> That's a possibility.  Although "plotstyle" is likely to be
> misunderstood as referring to dots/points/lines/boxes/etc

I also like this idea. As I am always using the DIN style which plots an
arrow parallel to the axis with the axis label. I could provide this style
as an option.

Other names could be:
set plotlayout
set style plot

> > which could be expanded later to include other "popular" styles
> >
> > set plotstyle excel
>
> Do I want to know what this looks like?  I hope you don't mean
> little pseudo-3D shaded skyscrapers that stand in for simple
> vertical lines or rectangles. But yes, I can imagine defining a
> number of common settings for the axes, borders, view angle, and so on.

No, this means too small fonts, no allowance of math in labels, and a
rescale to the default layout when embedding in other documents without
the possibility to change anything.

> I'm currently leaning in favor of
> 	set zeroaxis {only}
> or	set zeroaxis {noborder}

I would prefer 'set style plot' because it really would open the way to
different layouts, as shown in the attachment. The DIN variant 2 is
strange but defined in the standard. I normally use DIN variant 1 which is
hard to get using current gnuplot because you always have to adapt the
position by hand.

Another thing I have always planned but not programmed is to provide the
position of an axis:

set xzeroaxis at 3.5 # in 2D
set xzeroaxis at 3.5,4.2 # in 3D

This would enable users to use zeroaxis also for plots that have a range
which does not include zero and for log-scale plots.

Best regards
Harald

-- 
Harald Harders
h.harders@...
http://www.harald-harders.de

On Thursday 29 September 2005 12:57 pm, Harald Harders wrote:
> On Thu, 29 Sep 2005, Ethan Merritt wrote:
> 
> > On Thursday 29 September 2005 03:00 am, Robert Hart wrote:
> >
> > > Something like:
> > >
> > > set plotstyle axes
> > > set plotstyle bordered

> I would prefer 'set style plot' because it really would open the way to
> different layouts, as shown in the attachment. The DIN variant 2 is
> strange but defined in the standard. I normally use DIN variant 1 which is
> hard to get using current gnuplot because you always have to adapt the
> position by hand.

You have convinced me. Wow, I had no idea that DIN extended to telling
people how to make their plots. Of the two, I like "set plotstyle" better
than "set style plot".

So the proposal so far is for a command with options

	set style plotlayout {bordered|axes|DIN1|DIN2|...}

The default would be "set plotstyle bordered", which is what we have now.

We could also consider allowing some suboptions to further tune the overall
appearance. I have been keeping a list of requested features that
would be easy to implement but have no obvious place to be specified
in the current command set: 
	{no}colorkeytitles
	{linespacing <n>}
	{background <rgbcolor>}

 
> Another thing I have always planned but not programmed is to provide the
> position of an axis:
> 
> set xzeroaxis at 3.5 # in 2D
> set xzeroaxis at 3.5,4.2 # in 3D
> 
> This would enable users to use zeroaxis also for plots that have a range
> which does not include zero and for log-scale plots.

I like that suggestion also, particularly if it means we can
deprecate "set ticslevel", which no one can ever remember.

-- 
Ethan A Merritt       merritt@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

On Thu, 29 Sep 2005, Ethan Merritt wrote:

> > I would prefer 'set style plot' because it really would open the way to
> > different layouts, as shown in the attachment. The DIN variant 2 is
> > strange but defined in the standard. I normally use DIN variant 1 which is
> > hard to get using current gnuplot because you always have to adapt the
> > position by hand.
>
> You have convinced me. Wow, I had no idea that DIN extended to telling
> people how to make their plots.

They standardise everything. :-)

> So the proposal so far is for a command with options
>
> 	set style plotlayout {bordered|axes|DIN1|DIN2|...}
>
> The default would be "set plotstyle bordered", which is what we have now.

This really sounds good.

> We could also consider allowing some suboptions to further tune the overall
> appearance. I have been keeping a list of requested features that
> would be easy to implement but have no obvious place to be specified
> in the current command set:
> 	{no}colorkeytitles
> 	{linespacing <n>}
> 	{background <rgbcolor>}

The valid suboptions have to be dependent on the chosen plotlayout. For
example, the DIN layouts need offsets, lengths, and styles for the arrows,
while a background seems unlogical for plots without a border.

The question now is if different plotlayouts should use different routines
to parse the command line or if it should be one routine which tests for
every used option if it is valid for this layout (as for example the
postscript-based terminals do).

What do you mean by linespacing?

> > Another thing I have always planned but not programmed is to provide the
> > position of an axis:
> >
> > set xzeroaxis at 3.5 # in 2D
> > set xzeroaxis at 3.5,4.2 # in 3D
> >
> > This would enable users to use zeroaxis also for plots that have a range
> > which does not include zero and for log-scale plots.
>
> I like that suggestion also, particularly if it means we can
> deprecate "set ticslevel", which no one can ever remember.

And we should fix the strange behaviour of zeroaxis when an axis is near
to the range limits, if the border is off. See the attached example.

Now, the question is who programmes what. I volunteer to programme the
DIN 1 style. I think we should just leave out DIN 2 since it really is a
strange thing to replace the last but one tic on an axis by its unit.

Best regards
Harald

-- 
Harald Harders
h.harders@...
http://www.harald-harders.de

On Thursday 29 September 2005 03:20 pm, Harald Harders wrote:
> 
> What do you mean by linespacing?

The routine write_multiline() explicitly places each line of
text based on what it thinks the font size is, always using
a vertical increment of one character height.  This would 
allow you to adjust that spacing, either because it gets the
font size wrong or just because you want a different spacing.


-- 
Ethan A Merritt       merritt@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

On Thursday 29 September 2005 03:20 pm, Harald Harders wrote:
> On Thu, 29 Sep 2005, Ethan Merritt wrote:
> 
> And we should fix the strange behaviour of zeroaxis when an axis is near
> to the range limits, if the border is off. See the attached example.

The patchset I uploaded to start this discussion already does that.
It's not perfect, but it behaves reasonably for a far wider range of
cases than the current code does.



-- 
Ethan A Merritt       merritt@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

On Thursday 29 September 2005 03:20 pm, Harald Harders wrote:
> 
> The valid suboptions have to be dependent on the chosen plotlayout.
> For  example, the DIN layouts need offsets, lengths, and styles for the arrows,
> while a background seems unlogical for plots without a border.

You might want a colored background for the XY plane in a 3D with 
xzeroaxis and yzeroaxis active, particularly if you are also drawing a
curve of some sort onto that plane.  And it is exactly in the case where
there is no border that you would want this the most. Right now you can
turn on the x and y grid lines, which is OK, but if we support backgrounds
at all it would be logical to support it for this purpose also.

But let's defer this until after the basic framework is in place.
 
> The question now is if different plotlayouts should use different routines
> to parse the command line or if it should be one routine which tests for
> every used option if it is valid for this layout (as for example the
> postscript-based terminals do).

If there is little overlap in the legal choice of suboptions, it's probably
better to let each style have its own parser.  In any case, duplicate code
can be merged later.
 
> Now, the question is who programmes what. I volunteer to programme the
> DIN 1 style. I think we should just leave out DIN 2 since it really is a
> strange thing to replace the last but one tic on an axis by its unit.

How about if you write both a type level parsing routine for
	set style plot$layout {border|axes|DIN|<others to be determined later}
and a specific parsing and initialization routine for the "DIN" case.
I'll provide a routine for the "axes" case, and either a suboption or a 
parallel one that handles your example of arrowheads on the axes.

"set style plot bordered" is simple, since it just resets to the current set
of default properties. But I guess we have to agree on exactly what properties
are being affected by these style settings, so we know what to reset.
I think the list so far is
	{xyz}zeroaxis
	{xyz}tics {axis|border}
	border
	arrowstyle for axes   # doesn't currently exist
Possibly also
	default key placement
	offsets for {xyz}label

Does the DIN style specification say anything about 3D plots?

-- 
Ethan A Merritt       merritt@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Timoth=E9e Lecomte wrote:

>Hi !
>
>While working on my wxwidgets terminal, I have found the following
>strange behaviour :
>
>...
>
>However, when I rotate a pm3d plot with the mouse in my wxwidgets
>terminal, and in particular when samples are numerous (tried with set
>isosamples 200; splot x**2*y**2 with pm3d), it seems that _graphics is
>not always called.
>
>...
>
>And, as a consequence, I can see two plots in the window.
>Here is a screenshot to illustrate it : http://tipote.free.fr/wxt10.png
>
>I have digged into the code to see what can trigger such a problem, but
>can't find anything suspect...
>
>...
>
>Timoth=E9e Lecomte
>
Just for reference in the mailing list : I have found the error, in my
code. _graphics() are perfectly consistent !

Thanks to Ethan Merritt for his help on this case.

Timoth=E9e Lecomte

My 2 cents :

    A new release would sure do Gnuplot a lot of good. I absolutely
love the new features of 4.1 (better rgb colors and image support, these
two are enough for me to justify a release).
    It would also be good to get feedback from the users.

    However, I don't really think that I have my word to say, since I
certainly won't be helping much for that release.

--
    Ga=EBl

>> 1) outdated ---> tag as such, and close.
>> 2) keeper --> tag 'release-critical', integrate in good time, then close
>> 3) later --> tag 'later', keep open

I propose that within the following month or so, we should clean up the 
Patches section, and our own bug et al notes, and freeze gnuplot in 
November.

> Passing an X window ID into the program:  I don't think this is in yet. 
> I'm not particularly motivated to include it, but someone else requested 
> that I add it.  It seemed such a small addition that it should be bug 
> free, or easy to fix if a bug does come up.  (Writing the xWidgets program 
> to demo the thing was by far more difficult.)

I vote for this inclusion. Very useful.

> Raise/lower for X windows:  Don't know the status of that one.  May be 
> some group reluctance because other window platforms might not have it. 
> Code wise, no brainer.

I use it for ages and it works OK (for all x11, pm and windows). Should be 
committed.

---
PM

On Wednesday 28 September 2005 11:47 pm, Petr Mikulik wrote:
> 
> > Passing an X window ID into the program:  I don't think this is in yet. 
> > I'm not particularly motivated to include it, but someone else requested 
> > that I add it.  It seemed such a small addition that it should be bug 
> > free, or easy to fix if a bug does come up.  (Writing the xWidgets program 
> > to demo the thing was by far more difficult.)
> 
> I vote for this inclusion. Very useful.

I agreee that it would be useful.
Unfortunately I have never been able to get the current patchset to
work on my machines, so I think it will need either additional 
debugging or additional documentation and demonstratation code
chunks that show how to make it work.


-- 
Ethan A Merritt       merritt@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

> One factor you might want to consider in this regard
> is the increasing use of gnuplot driven by scripts of
> dynamically-typed languages--Python, Perl, Tcl, Ruby,
> PHP... In such cases unexpected results can arise as a
> result of integer division being the default. Perhaps
> adopting a Python-like approach (// for integer
> division) initially driven by a switch (set division
> true|integer) and eventually defaulting to true might
> help.

Python works like gnuplot:

Python 2.3.4 (#1, Feb  7 2005, 15:50:45)
[GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print 5/2
2
>>> print 5//2
2

---
PM

Petr Mikulik wrote:
> Python works like gnuplot:
>
> Python 2.3.4 (#1, Feb  7 2005, 15:50:45)
> [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>
> >>> print 5/2
>
> 2
>
> >>> print 5//2
>
> 2

Yes, but AFAIK this behaviour will change with 3.0.  Try:

>>> from __future__ import division
>>> print 5/2
2.5


Juergen

--- Petr Mikulik <mikulik@...> wrote:
> Python works like gnuplot:
> 
> Python 2.3.4 (#1, Feb  7 2005, 15:50:45)
> [GCC 3.3.4 (pre 3.3.5 20040809)] on linux2
> Type "help", "copyright", "credits" or "license" for
> more information.
> >>> print 5/2
> 2
> >>> print 5//2
> 2

It does now, but look at this:

C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> 5/2
2
>>> 5//2
2
>>> from __future__ import division
>>> 5/2
2.5
>>> 5//2
2
>>>

This behavior will become the default with 3.0.

     jab


John Bollinger, CFA, CMT
 http://www.BollingerBands.com

If you advance far enough, you arrive at the beginning.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Petr Mikulik wrote:

>>>> P.S. : by the way, I realised that the "coords to clipboard with
>>>> 2*<B1>"
>>>> doesn't work with the x11 terminal. Is it normal ?
>>>
>>>
>>> Copying to xterm, nedit, gedit works.
>>>
>>> Copying to anything using Qt (thus, any Qt/KDE application) does not
>>> work.
>>> How can this be allowed?
>>
>>
>> You're right, I was pasting to Konsole... but unfortunately I can't he=
lp
>> you to allow this in Qt. (In my wxwidgets terminal, I use the clipboar=
d
>> object, and it just works)
>
>
> I've just filled in a bug report so that "someone" could search for a
> solution.

"Someone" could look in gtk code, to see where's the trick...

>
> Accidentaly, I've found this amazing feature: having double-clicked
> MB1, sequent MB2 copied the cursor position into gvim, but into
> OpenOffice.org it copied png image of the graph! What's the magics
> behind??
>
> ---
> PM

I also found such a "feature" as I was implementing the same for my
wxwidgets terminal. When I was playing with double-click, the X11 plot
appeared in klipper, the kde clipboard handler ! I think that it's a
feature of the window manager (kwin), but I'm not sure at all...

Timoth=E9e

> I also found such a "feature" as I was implementing the same for my
> wxwidgets terminal. When I was playing with double-click, the X11 plot
> appeared in klipper, the kde clipboard handler ! I think that it's a
> feature of the window manager (kwin), but I'm not sure at all...

I've tried to open Konsole and Kate in Blackbox. It behaves as in KDE.

---
PM