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

Y2K is long gone. Time to deprecate time.c?

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

A recent report on the newsgroup of gnuplot hanging turns out to be due
to a comedy of coding errors that I won't go into here, but ultimately
the hang is due to the routine ggmtime() in time.c 

ggmtime() stupidly calculates time by incremental subtraction from a target date
given in seconds.  If the target date is large, say 10^12, a single call can take
a minute to return.  If the target date is even larger, say 10^38, it would take
approximately 10^22 years to return from a single date calculation.
And guess what the default initial value is ;-\ ;-\ ;-\

The thing is, the routines in time.c are marked in the header as
being protection against possible Y2K problems in the POSIX time
routines provided by a system library.  Their use is under the control
of USE_SYSTEM_TIME, which currently defaults to being undefined.

Now that Y2K is past and gone, can we define USE_SYSTEM_TIME by default
and go back to using the standard POSIX routines?

If not that, should we put a sanity check in the time routines
limiting the accessible future to, say, the first 1.e10 seconds of the epoch?

-- 
Ethan A Merritt

Re: Display math on labels with epslatex terminal?

[Christoph B. <us...@be...>]

Miguel Rubio Roy schrieb:
> Hi all,
>   Maybe this is documented, but I haven't found it. Sorry in that case.
>   I'm using epslatex termianl and I'd like to use displayed equations
> rather than inline for labels. If I use this stupid (but good for the
> example) command:
> set xlabel '$\unit[\int\frac{\Phi_{\mathrm{CHF}_3}}{\Phi_{\mathrm{CH}_4}+\Phi_{\mathrm{CHF}_3}}]{(\%)}$'
> the integral symbol is too small. I've tryed substituing $ by \[ or \]
> but pdflatex complains about it.


You can use \displaystyle to get bigger fractions and integral signs:

set xlabel '$\displaystyle\int\frac{a}{b}$'

Here, the fraction might be too big, you may also use

set xlabel '${\displaystyle\int}\frac{a}{b}$'


I don't know if there is any way to allow the use of \[ inside the \put 
commands which are used to typeset the labels.


Christoph

Re: gnuplot manual misprint (no.29)

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

On Wednesday 03 June 2009, Shigeharu TAKENO wrote:
> | ----- To here (gd.trm) -----
> 
> I had to explain above. The paragraph for "size" and "color" of 
> gif help mentioned above are duplicated (appeared twice). So the
> part should be removed.


I wonder how that happened?
Applied, thank you.

	Ethan

Re: gnuplot manual misprint (no.29)

[Shigeharu T. <sh...@ie...>]

shige 06/04 2009
----------------

I wrote:
| ----- From here (gd.trm) -----
| --- gd.trm.ORG  2009-06-01 11:51:42.000000000 +0900
| +++ gd.trm      2009-06-01 11:58:31.000000000 +0900
| @@ -2616,16 +2616,6 @@
|  " file than gnuplot's internal optimization mode.",
|  " The default is `nooptimize`.",
|  "",
| -" The size <x,y> is given in pixels---it defaults to 640x480.  The number of",
| -" pixels can be also modified by scaling with the `set size` command.",
| -" `crop` trims blank space from the edges of the completed plot, resulting",
| -" in a smaller final image size. Default is `nocrop`.",
| -"",
| -" Each color must be of the form 'xrrggbb', where x is the literal character",
| -" 'x' and 'rrggbb' are the red, green and blue components in hex.  For example,",
| -" 'x00ff00' is green.  The background color is set first, then the border",
| -" colors, then the X & Y axis colors, then the plotting colors.  The maximum",
| -" number of colors that can be set is 256.",
|  " The output plot size <x,y> is given in pixels---it defaults to 640x480.",
|  " Please see additional information under `canvas` and `set size`.",
|  " Blank space at the edges of the finished plot may be trimmed using the `crop`",
| ----- To here (gd.trm) -----

I had to explain above. The paragraph for "size" and "color" of 
gif help mentioned above are duplicated (appeared twice). So the
part should be removed.

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Adding some new transformations to gnuplot (arctan and power laws)

[James R. V. Z. <jr...@co...>]

I wrote
...
> > monotonic. For example, I'd like to implement f(x)=1/x, so I could
> > label spectra in both energy and wavelength units. However, the range
> > requirement could be either "x>0" or "x<0", and if there are both
> > positive and negative values in the data, the program would be hard
> > pressed to make the right choice.
> 
> Actually, I view this as a "monotone" transformation.  It just happens
> to wrap at zero rather than wrap at +infinity as most monotone
> functions do.  :-)   

Actually it does not satisfy either of the monotonic requirements
   whenever x ≤ y, then f(x) ≥ f(y) 
or else
   whenever x ≤ y, then f(x) ≤ f(y)

> So if you are using the transformed space and
> you have both positive and negative values, the natural graph is to
> put +infinity in the middle of the graph.   No code else where even
> has to know about this weirdness--it just sees a set of points to
> plot.

True.  And sometimes it would make sense - e.g. for the position of a
virtual image.

> I tried implementing this in my version, but there are lots of range
> checking that is done in untransformed coordinates.  This would have
> to be switched to checks done using transformed coordinates.  So my
> implementation just ducked this issue.  But I think the right answer
> is to have a plot with +infinity in the middle.  So the axis would
> look something like:
> 
>  --------+-------+-----+-----+------+-------+---------+--
>          5       10    20  infty   -20     -10       -5

Yes, this could work.  With some manual customization for a particular
transform.  But it would be a challenge to get autoranging to find
this solution for a general user-specified transformation.

BTW I proposed
> We might go through three phases here.  (1) implement only fixed
> transforms for which we have analytic inverses, so the pointer could
> be to a C function.  (2) allow user-defined functions, but demand 
> that the user also supply the inverse function.  Here we would need a
> pointer to a parse table.  (3) Allow the user to
> omit the inverse function, falling back on the rational interpolation.
...
> and for user supplied transformations
> 
>      {un}set user scale {x|y...} func(dummy)  
>      {unscale func2(dummy)}
>      {rangecheck func3(dummy)}

I would like to generalize this to make the forward transform
optional:  

      {un}set user scale {x|y...} {func(dummy)}
      {unscale func2(dummy)}
      {rangecheck func3(dummy)}

where at least one of the forward and reverse transform must be specified.

There are cases where the inverse transform has an analytic form, but
the forward transform does not.  Arguably this is true for the
probability transform, which is defined as

           set user scale x invnorm(x)

The more "natural" way to specify this might be

           set user scale x unscale norm(x)

Likewise if you want the transform for a probability distribution
where you have a function to calculate the CDF, but not its inverse.

      - Jim Van Zandt

Display math on labels with epslatex terminal?

[Miguel R. R. <mru...@gm...>]

Hi all,
  Maybe this is documented, but I haven't found it. Sorry in that case.
  I'm using epslatex termianl and I'd like to use displayed equations
rather than inline for labels. If I use this stupid (but good for the
example) command:
set xlabel '$\unit[\int\frac{\Phi_{\mathrm{CHF}_3}}{\Phi_{\mathrm{CH}_4}+\Phi_{\mathrm{CHF}_3}}]{(\%)}$'
the integral symbol is too small. I've tryed substituing $ by \[ or \]
but pdflatex complains about it.

I'm using gnuplot 4.2.5 and pdfTeXk, Version 3.1415926-1.40.9 (Web2C
7.5.7), both running on Mac OS X 10.5.7

Is there any way of doing this?

Thanks

Miguel

Re: Adding some new transformations to gnuplot (arctan and power laws)

[<pl...@pi...>]

Ethan Merritt wrote:
> On Tuesday 02 June 2009, James R. Van Zandt wrote:
> 
> [snipped most of it]
> 
>> Ethan Merritt wrote:
>>>>  + how to pass the transform to an external helper (gnuplot_x11) or wrap it
>>>>    in the driver output (canvas terminal)?
>> Surely that interface, in both directions, can be in terminal coordinates?
> 
> The issue is clearest for the canvas terminal, where "both directions" does not
> apply.  I want to toggle between linear/logscale or linear/transform in the
> javascript code on the browser.  There is no back-connection to the original
> gnuplot run.  
> 
> I am arguing that it may be preferable to send terminal coordinates corresponding
> to linear scale, plus some clue how they should be transformed by the viewer
> upon request.  
> 
> Right now the output from gnuplot is in terminal coordinates that represent either
> linear or log scale depending upon what was set at the time the plot was created.
> The routine gnuplot_mouse.js knows how to back-transform the stored terminal
> coordinates to give back correct mousing if log-scale was in effect.
> But it doesn't know how to toggle from linear to log display of the coordinates,
> whatever scale they were originally on.  It wouldn't be very hard to add that,
> just tedious. I was putting it off in the hope that we might come up with a general
> plan for toggling transformed data, so that I could write the routines only once
> instead of having to redo them later.
> 
> 
> ------

Hi,

I'm wondering about the rationality of this. "Toggling" log/transform 
scaling is really a euphormism for a total replot it seems. You 
fundementally change the x or y scale transformation and have to do a 
full replot of the data, axes and all.

This is feasible in a live terminal such as wxt since gnuplot is 
available to do the replotting. In the case of write-once interactive 
terminals I see two possibilities:

1/ export two renditions of the graph and a trivial js routine to toggle 
them. This could be similar to the line visibility toggle already 
working for svg but on a larger object. I suspect the coding would be 
trivial and fairly portable.

I doubt that the amount of information that would be common to both 
plots would merit swapping only part of the content. Gnuplot should 
provide complete plots and just let the browser toggle visibility.

This approach should be valid for any arbitary future tranformations.

or

2/ export enough information and js code for the interactive terminal to 
redraw new axes, tic labels , grid, plot lines, axes labels and 
possibily alter the legend. It seems that this close to the entire plot 
job except parsing the input data. It is reproducing most of what 
gnuplot would do. Gnuplot is no longer a plotter but a preprocessor. 
This seems rather off target in terms of what gnuplot should be doing.


/Peter.

Re: Adding some new transformations to gnuplot (arctan and power laws)

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

On Tuesday 02 June 2009, James R. Van Zandt wrote:

[snipped most of it]

> Ethan Merritt wrote:
> > >  + how to pass the transform to an external helper (gnuplot_x11) or wrap it
> > >    in the driver output (canvas terminal)?
> 
> Surely that interface, in both directions, can be in terminal coordinates?

The issue is clearest for the canvas terminal, where "both directions" does not
apply.  I want to toggle between linear/logscale or linear/transform in the
javascript code on the browser.  There is no back-connection to the original
gnuplot run.  

I am arguing that it may be preferable to send terminal coordinates corresponding
to linear scale, plus some clue how they should be transformed by the viewer
upon request.  

Right now the output from gnuplot is in terminal coordinates that represent either
linear or log scale depending upon what was set at the time the plot was created.
The routine gnuplot_mouse.js knows how to back-transform the stored terminal
coordinates to give back correct mousing if log-scale was in effect.
But it doesn't know how to toggle from linear to log display of the coordinates,
whatever scale they were originally on.  It wouldn't be very hard to add that,
just tedious. I was putting it off in the hope that we might come up with a general
plan for toggling transformed data, so that I could write the routines only once
instead of having to redo them later.

Re: Adding some new transformations to gnuplot (arctan and power laws)

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

On Tuesday 02 June 2009 06:26:47 Dean Foster wrote:
> If all calls to points go through the function AXIS_MAP and
> AXIS_UNMAP, then it does seem that we are pretty close to being able
> to do a late change of axis.  

They are currently macros, not functions.
I do think that in order to pursue this we will have to change them
to be functions.

Yes, my earlier email with sample code equivalent to
   xx = (FIRST_X_AXIS.transform) ? (FIRST_X_AXIS.transform)(pos->x) : pos->x;
   *x = AXIS_MAP(FIRST_X_AXIS, xx);
would be further simplified by placing the test for a transform inside
AXIS_MAP() itself.

> I didn't know how to check that these 
> functions were always used.  (I'm mostly a C++ programmer--so my only
> tricks of making things private to find who peeks at data doesn't work
> here.  But I'm sure someone else knows if these functions are always
> used as go-betweens.)  I can try using them for my transformation and
> see if it seems to work.

I grepped for use of ->term_scale as a convenient indicator, and found only
two other place in the core code that would be affected. One is the tic
placement code, which we've already agreed is a special case but maybe not
impossible to clean up. The other is
  graphics.c:  map_position_r()

As already mentioned, the mousing code in various terminals would need to 
revised also, but that will have to be done on a case by case basis.

A few places test for the _sign_ of  (axis)->term_scale,  but so long as
the transform is monotonic that should be OK.  If it isn't monotonic, then
we have other problems starting with there being no 1-to-1 inverse transform.
I'm going to have to think about that, however.  Is it possible that allowing
non-monotonic axis transforms would be another way of generating parametric
plots?

-- 
Ethan A Merritt

Re: epslatex terminal canvas size changed with "set size"

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

On Monday 01 June 2009 09:48:50 Ethan Merritt wrote:
> On Monday 01 June 2009 09:21:07 Miguel Rubio Roy wrote:
> > Hi all,
> >   I'm using epslatex terminal, and as far as I know the way to change the
> > canvas size is using "set term epslatex size 10cm,10cm", for example.
> >   This command works, but when I want to modify the size of the plot inside,
> > if I use "set size 0.8,0.8", for example, the canvas size is also changed,
> > so that I end up with a pdf file of 8x8 cm. Is this the expected behavior?

> The only way I can think of at the moment is to edit the files by hand.

I apologize for my failing memory.  
Of course you can still use the "old" way of reserving a portion of the full
canvas:  wrap it in a 'multiplot' even though there is only one plot.
The "set size" command must be _after_ the "set multiplot" command.

set term epslatex standalone size 10cm,10cm
set output "test2.tex"
set multiplot
  set size 0.8,0.8
  f(x) = sin(x)
  plot f(x)
unset multiplot
unset output



-- 
Ethan A Merritt

Re: epslatex terminal canvas size changed with "set size"

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

On Monday 01 June 2009 09:21:07 Miguel Rubio Roy wrote:
> Hi all,
>   I'm using epslatex terminal, and as far as I know the way to change the
> canvas size is using "set term epslatex size 10cm,10cm", for example.
>   This command works, but when I want to modify the size of the plot inside,
> if I use "set size 0.8,0.8", for example, the canvas size is also changed,
> so that I end up with a pdf file of 8x8 cm. Is this the expected behavior?

From the documentation under "help canvas"

 The major exception to this convention is the PostScript driver, which
 by default continues to act as it has in earlier versions. Be warned that
 the next version of gnuplot may change the default behaviour of the
 PostScript driver as well.

The documentation should probably mention explicitly that the PostScript
driver is also used by epslatex.

So yes, it is expected and documented.  But that doesn't mean it is the
right thing to do.  It's great that you point this out now, because we
have just begun laying out the plan for release of the next gnuplot version,
4.4.  I had forgotten that the issue of PostScript + "set size" needed review,
so it is good that you remind us.

> How do I change the plot size without changing the canvas size.

The only way I can think of at the moment is to edit the files by hand.
In the *.eps file you would be editing the line
  %%BoundingBox: 50 50 276 276
(change 276 to 333)

In the *.tex file you would be editing the line
  \begin{picture}{4534.40,4534.40}%
(change 4534.40 to 5668.00)

Please file a bug report on the project site on SourceForge.
That way it will not be forgotten as we put together the next release.

	Ethan 
 

epslatex terminal canvas size changed with "set size"

[Miguel R. R. <mru...@gm...>]

Hi all,
  I'm using epslatex terminal, and as far as I know the way to change the
canvas size is using "set term epslatex size 10cm,10cm", for example.
  This command works, but when I want to modify the size of the plot inside,
if I use "set size 0.8,0.8", for example, the canvas size is also changed,
so that I end up with a pdf file of 8x8 cm. Is this the expected behavior?
How do I change the plot size without changing the canvas size.

The batch file for gnuplot I use is:

set term epslatex standalone size 10cm,10cm
set size 0.8,0.8
set output "test2.tex"
f(x) = sin(x)
plot f(x)
set output

Later on, I run epstopdf on test2-inc.eps and compile all with pdflatex

I'm using gnuplot 4.2.5 as distribuited with Octave and pdfTeXk, Version
3.1415926-1.40.9 (Web2C 7.5.7), both running on Mac OS X 10.5.7

Thanks!

Miguel

Re: problem: gnuplot with libeditline

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

On Monday 01 June 2009, Ralf Juengling wrote:
> Hi,
> 
> After switching to Ubuntu Jaunty bi-directional
> communication with gnuplot did not work. The Ubuntu
> version is linked to libeditline. I then built gnuplot
> myself and linked against libreadline, and it worked
> (version 4.2.5). That's as far as I tracked it.

Could this be the same problem that we recently learned of -
that editline cannot handle multibyte characters, including UTF-8?
If you still have the Ubuntu binary around, you could try
wrapping it in a a script that sets the locale to C.

problem: gnuplot with libeditline

[Ralf J. <jue...@cs...>]

Hi,

After switching to Ubuntu Jaunty bi-directional
communication with gnuplot did not work. The Ubuntu
version is linked to libeditline. I then built gnuplot
myself and linked against libreadline, and it worked
(version 4.2.5). That's as far as I tracked it.

Ralf

gnuplot manual misprint (no.29)

[Shigeharu T. <sh...@ie...>]

shige 06/01 2009
----------------

In docs/gnuplot.doc of current CVS version

 RCS $Id: gnuplot.doc,v 1.568 2009/05/17 22:31:55 sfeam Exp $

and term/gd.trm

 $Id: gd.trm,v 1.136 2009/05/24 06:12:44 sfeam Exp $

I found some points that seem to be misprints.

I send the unified diff file for them.

----- From here (gnuplot.doc) -----
--- gnuplot.doc.ORG	2009-06-01 11:51:15.000000000 +0900
+++ gnuplot.doc	2009-06-01 11:56:03.000000000 +0900
@@ -1674,7 +1674,7 @@
       set term png tiny
 
  On most systems libgd also provides access to Adobe Type 1 fonts (*.pfa) and
- TrueType fonts (*.ttf). You must give the name of the font file (not the name
+ TrueType fonts (*.ttf). You must give the name of the font file, not the name
  of the font itself, in the form "<face> {,<pointsize>}".
  <face> is either the full pathname to the font file, or the first part of a
  filename in one of the directories listed in the GDFONTPATH environmental
@@ -1685,7 +1685,7 @@
       set term png font "arial"
       set term png font "/usr/local/fonts/ttf/arial.ttf"
       set term png font "Helvetica"
-      set term png font "/usr/local/fonts/Helvetica.pfa"
+      set term png font "/usr/local/fonts/pfa/Helvetica.pfa"
  To request a default font size at the same time:
       set term png font "arial,11"
 
----- To here (gnuplot.doc) -----

----- From here (gd.trm) -----
--- gd.trm.ORG	2009-06-01 11:51:42.000000000 +0900
+++ gd.trm	2009-06-01 11:58:31.000000000 +0900
@@ -2616,16 +2616,6 @@
 " file than gnuplot's internal optimization mode.",
 " The default is `nooptimize`.",
 "",
-" The size <x,y> is given in pixels---it defaults to 640x480.  The number of",
-" pixels can be also modified by scaling with the `set size` command.",
-" `crop` trims blank space from the edges of the completed plot, resulting",
-" in a smaller final image size. Default is `nocrop`.",
-"",
-" Each color must be of the form 'xrrggbb', where x is the literal character",
-" 'x' and 'rrggbb' are the red, green and blue components in hex.  For example,",
-" 'x00ff00' is green.  The background color is set first, then the border",
-" colors, then the X & Y axis colors, then the plotting colors.  The maximum",
-" number of colors that can be set is 256.",
 " The output plot size <x,y> is given in pixels---it defaults to 640x480.",
 " Please see additional information under `canvas` and `set size`.",
 " Blank space at the edges of the finished plot may be trimmed using the `crop`",
----- To here (gd.trm) -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Adding some new transformations to gnuplot (arctan and power laws)

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

On Sunday 31 May 2009, James R. Van Zandt wrote:
> 
> A year ago, Ethan wrote:
> >> I figured to leave the existing log-scale code in place, as you 
> >> suggested above, while adding a new more general mechanism that worked
> >> on the original stored coordinates.  Once the general mechanism was
> >> in place and working, the old log-scale code could be removed without
> >> ever having to modify it to work  with "last-minute" scaling.
>
> Here's my reply.  Do you think this makes sense?
>
> > I think I see how that would work:
> > 
> > Currently:
> > Upon "set log x", all stored x values are transformed and on "unset
> > log x" they are inverse transformed.
> > 
> > Phase 1:
> > Add a scaling "newlog".
> > 
> > Add to AXIS a pointer to a function that transforms the data.  The
> > function takes two parameters: the datum to be transformed, and a
> > double.  For scaling "linear" or "log" the function is a no-op.  For
> > "newlog", the extra parameter is the base of the logs.  Otherwise the
> > extra parameter is ignored.

I have been thinking a bit about this.  I think that the core requirement
is simply to store two function pointers for each axis: the transform and
its inverse.  The forward transform is used [only?] by the routines that
map plot coordinates to terminal coordinates.  It is conceptually easiest
to show for the routine map_position_double():

%%%%%%%%%%%%%%%%%% current code %%%%%%%%%%%%%%%%%%%%%
/*{{{  map_position_double */
static void
map_position_double(
    struct position *pos,
    double *x, double *y,
    const char *what)
{
    switch (pos->scalex) {
    case first_axes:
        {
            double xx = axis_log_value_checked(FIRST_X_AXIS, pos->x, what);
            *x = AXIS_MAP(FIRST_X_AXIS, xx);
            break;
        }
    ...
%%%%%%%%%%%%%%% proposed code %%%%%%%%%%%%%%%%%%%%%%%%%
/*{{{  map_position_double */
static void
map_position_double(
    struct position *pos,
    double *x, double *y,
    const char *what)
{
    switch (pos->scalex) {
    case first_axes:
        {
            double xx = pos->x;
            if (FIRST_X_AXIS.transform)
                xx = (FIRST_X_AXIS.transform)xx;
            *x = AXIS_MAP(FIRST_X_AXIS, xx);
            break;
        }
    ...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The transform is obviously not applied in the case statements handling
screen, character, or graph coordinates.  It only applies to the axial
coordinates. 

Note: this edit by itself doesn't actually do much, because the data points
are usually plotted via a direct calls to the macros map_x() and map_y().
I made a very quick hack to test specifically a log transform on axis y2,
and found that for simple plots it was sufficient to modify the macros
AXIS_MAP(axis, variable) and AXIS_SETSCALE(axis, out_low, out_high)
in axis.h.   I'm sure there will turn out to be other places that need
tweaking as well, but this is looking quite do-able.

The inverse transform is obviously needed for mouse feedback. But it
would also be available for guiding the choice of sampling intervals
and tic placement if needed. 

I am not following you about needing a second parameter for log scale.
The appearance of the plot is independent of the base of the log.
Choosing a different base would introduce a constant scale multiplier,
which is re-scaled out of existence by conversion to terminal coordinates.
 
> > Always do "last-minute" scaling: When plotting a value, call the
> > function via the supplied pointer to transform it.
> > On "set log x" or "unset prob x" etc., update the function pointer.
> > On "(un)set log x", continue to (un)transform the stored data.
> > 
> > Phase 2 (after initial checkout):
> > Rename scaling "log" to "oldlog", and rename "newlog" to "log".

I suggest to introduce a new command
   {un}set transform {x|y|x2|y2|...} func(dummy)

Phase 1 is to start using this command.

Phase 2 is to trap the older command "set log y" and treat it as 
"set transform y log(y)". 


> > Phase 3 (after a major release): 
> > Delete the "oldlog" commands and the code to (un)transform the stored
> > data.
> > 
> > The above only implements standard scalings (linear, log, probability,
> > and maybe weibull).  To accommodate a user-defined scaling function,
> > the scaling step needs to be able to point to an action table.  We
> > could use that mechanism to implement the standard scalings too -
> > building the action tables from static strings like "_linear(x,b)=x"
> > or "_log(x,b)=log(x)/log(b)".  However, I'm worried that would be too
> > slow.  The faster method would be to give the scaling function three
> > parameters (datum, extra, and action table), and let the standard
> > scaling functions ignore the third parameter.

While I understand your concern about speed in evaluating the function,
I point out that we have extensive benchmarks on how much it costs.
Every time you put parentheses in a 'using' statement you  incur the cost
of action table evaluation.
     plot 'foo' using ($1):($2)
is slower than
     plot 'foo' using 1:2
And yes, there have been a small number of complaints about the speed hit,
but it is only noticeable for very large datasets.  A while back I showed
that unexpectedly, at least under linux the largest part of this hit comes
from from enabling/disabling FPE trapping around each point.
But that's a digression.

I suggest that if we implement this, and it works, then we can worry later
about further optimizing the speed.  For some common cases, e.g. log(), we
could store a pointer to the C library function rather than to an action
table.


Summary:

- I could make simple plots work using a last-minute log transform by modifying
  only 2 macros in axis.h.   This is looking quite do-able, although I would
  prefer to turn these macros back into real subroutines for readability if
  nothing else.

- Unresolved issues:
  + how to deal with singularities in the transform?  We won't hit them until
    we are in the middle of plotting.
  + how to pass the transform to an external helper (gnuplot_x11) or wrap it
    in the driver output (canvas terminal)?
  + tic placement (although I can report that my quick hack "just worked" for
    placing logscale tics on simple plots with no change to the tic code at all

			- Ethan

Re: Adding some new transformations to gnuplot (arctan and power laws)

[James R. V. Z. <jr...@co...>]

 Dean Foster <dea...@gm...> wrote:

> You solved the hard problem--namely the tics.
>
> I think there are really 4 different problems to solve here.
>
> (1)  When / where in the code to do the transformation.  (Ideally, as
> late as possible.)
>
> (2) Intelegent tics.
>
> (3) a variety of transformations of the axis itself.
>
> (4) dynamic exploration of transformations. (currently the L command
> is supported in gnuplot.)
>
> I think viewing doing (1) as a blocker for the other 3 doesn't make
> sense.  The other three are ready to be included in the existing code
> base and are all local changes.  I don't think they in any way make
> doing (1) harder.  Since the other 3 all call the same transformation
> functions, they shouldn't actually have to be changed at all if (1)
> were implemented.

As I remember, I had to touch the code in a lot of places to add one
transformation.  Refactoring the code to delay the transformation
would help with that.

A year ago, Ethan wrote:
>> I figured to leave the existing log-scale code in place, as you 
>> suggested above, while adding a new more general mecanism that worked
>> on the original stored coordinates.  Once the general mechanism was
>> in place and working, the old log-scale code could be removed without
>> ever having to modify it to work  with "last-minute" scaling.

Here's my reply.  Do you think this makes sense?
> I think I see how that would work:
> 
> Currently:
> Upon "set log x", all stored x values are transformed and on "unset
> log x" they are inverse transformed.
> 
> Phase 1:
> Add a scaling "newlog".
> 
> Add to AXIS a pointer to a function that transforms the data.  The
> function takes two parameters: the datum to be transformed, and a
> double.  For scaling "linear" or "log" the function is a no-op.  For
> "newlog", the extra parameter is the base of the logs.  Otherwise the
> extra parameter is ignored.
> 
> Always do "last-minute" scaling: When plotting a value, call the
> function via the supplied pointer to transform it.
> On "set log x" or "unset prob x" etc., update the function pointer.
> On "(un)set log x", continue to (un)transform the stored data.
> 
> Phase 2 (after initial checkout):
> Rename scaling "log" to "oldlog", and rename "newlog" to "log".
> 
> Phase 3 (after a major release): 
> Delete the "oldlog" commands and the code to (un)transform the stored
> data.
> 
> The above only implements standard scalings (linear, log, probability,
> and maybe weibull).  To accommodate a user-defined scaling function,
> the scaling step needs to be able to point to an action table.  We
> could use that mechanism to implement the standard scalings too -
> building the action tables from static strings like "_linear(x,b)=x"
> or "_log(x,b)=log(x)/log(b)".  However, I'm worried that would be too
> slow.  The faster method would be to give the scaling function three
> parameters (datum, extra, and action table), and let the standard
> scaling functions ignore the third parameter.


           - Jim

Re: set autoscale fix; set logscale y2

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

On Thursday 28 May 2009, Petr Mikulik wrote:

> Those y2 tics were explicitly set, so "plot ... axes x1y2" should not be 
> required. I use this for x+x2 axes in order to have axes with wavelength and 
> energy, for example.

This is a good example of why we need general axis transforms, not just log scale.
For what it's worth, I handle the energy/wavelength case by leaving both x and x2
in energy space, but mapping the x2tic labels through a transform:

  set xtics nomirror
  set xlabel "eV"
  set xrange [2000:20000]
  set autoscale fix
  set for [wavelength in "1 2 3 5 10"] x2tics (wavelength." Å"  12398./wavelength)

  plot log(x)

Re: set autoscale fix; set logscale y2

[Thomas S. <t.s...@fz...>]

> Those y2 tics were explicitly set, so "plot ... axes x1y2" should not be 
> required. I use this for x+x2 axes in order to have axes with wavelength
> and 
> energy, for example.

right, as long as you don't use autoscaling, it works.

> The bug appears even if "set autoscale fix" appears *before* explicit 
> y2range:

it doesn't matter where you specify "set autoscale fix" because
it is respected 'at the end', i.e. when the 'plot' command is executed,
and then the fixed ranges are forgotten and determined by the
function values.

and if there are no values - like in 'plot 1+x*x' - then y2axis gets its
range from yaxis, with the precaution that yrange is transfered into the
exponent if 'logscale y2' is on.
-- 
View this message in context: http://www.nabble.com/set-autoscale-fix--set-logscale-y2-tp23748542p23759523.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: set autoscale fix; set logscale y2

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

> IMHO gnuplot reacts as it should:
> 
> > reset
> > set ytics nomirror
> > set logscale y
> > set yrange [1:100]
> > 
> > set y2tics nomirror
> > set logscale y2
> > set y2range [1:100]
> > 
> > plot 1+x*x
> 
> everything looks right, the y*ranges are defined,
> so it doesn't matter that the y2axis isn't used.
> 
> > pause -1
> >
> > set autoscale fix
> > replot
> 
> here, the defined y*ranges are forgotten, yrange is
> calculated from the function values and then - because
> y2tics is set - copied to the (not used!) y2axis,
> where, in order to prevent errors (logscale y2 !), the 1 to
> 100 yrange is converted into the 1e1 to 1e100 y2range.
> (if yrange would be [0:100] it wouldn't be possible to
> convert it into a log-range for y2axis, i think that's the
> idea behind this conversion)
> 
> keep in mind, that y2axis is plotted but not used.
> 
> using both yaxes
> 
> plot 1+x*x, 1+x*x axes x1y2
> 
> solves the problem.

Those y2 tics were explicitly set, so "plot ... axes x1y2" should not be 
required. I use this for x+x2 axes in order to have axes with wavelength and 
energy, for example.

The bug appears even if "set autoscale fix" appears *before* explicit 
y2range:


reset

set autoscale fix

set ytics nomirror
set logscale y
set yrange [1:100]

set y2tics nomirror
set logscale y2
set y2range [1:100]

plot 1+x*x

---
PM

Re: set autoscale fix; set logscale y2

[Thomas S. <t.s...@fz...>]

IMHO gnuplot reacts as it should:

> reset
> set ytics nomirror
> set logscale y
> set yrange [1:100]
> 
> set y2tics nomirror
> set logscale y2
> set y2range [1:100]
> 
> plot 1+x*x

everything looks right, the y*ranges are defined,
so it doesn't matter that the y2axis isn't used.

> pause -1
>
> set autoscale fix
> replot

here, the defined y*ranges are forgotten, yrange is
calculated from the function values and then - because
y2tics is set - copied to the (not used!) y2axis,
where, in order to prevent errors (logscale y2 !), the 1 to
100 yrange is converted into the 1e1 to 1e100 y2range.
(if yrange would be [0:100] it wouldn't be possible to
convert it into a log-range for y2axis, i think that's the
idea behind this conversion)

keep in mind, that y2axis is plotted but not used.

using both yaxes

plot 1+x*x, 1+x*x axes x1y2

solves the problem.
-- 
View this message in context: http://www.nabble.com/set-autoscale-fix--set-logscale-y2-tp23748542p23758331.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: set autoscale fix; set logscale y2

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

> I don't see any bug here.
> The resulting plots look correct to me, but I may misunderstand what you are 
> expecting to see.  

I've forgotten to copy "set y2tics". So here it is:

reset
set ytics nomirror
set logscale y
set yrange [1:100]

set y2tics nomirror
set logscale y2
set y2range [1:100]

plot 1+x*x

pause -1

set autoscale fix
replot


Amazingly, replacing
set autoscale fix
  by
set autoscale keepfix
solves the problem. 

But why "autoscale fix" double-exponentiates the y2-tics?

***

reset
set tics out
set ytics nomirro
set y2tics nomirror

set autoscale keep

set logscale y2
# set y2range ...

plot 1+x*x

show log
show y2range

pause -1

set y2range [1:10]
replot
show y2range

***

Solution for Octave:
replace "set autoscale fix" and add the required y2 range:

set autoscale keepfix
set y2range [1:180]

---
PM

Re: set autoscale fix; set logscale y2

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

I don't see any bug here.
The resulting plots look correct to me, but I may misunderstand what you are 
expecting to see.  

Starting with the original query:

John W. Eaton >
> When I execute the following commands in gnuplot, the y2 tick marks appear
> to be linearly spaced and the y2 tick labels do not appear:
> 
>   set logscale y2
>   plot sin (x) axes x1y1, exp (x) axes x1y2

The y2 tick labels do not appear simply because you never turned them on.
Try:
    set y2tics 
    replot

> but after executing
> 
>   set logscale y
>   replot
> they do appear, but then the y1 axis is also log scaled.

I don't see any y2 labels here.  The tick marks on the right side that result
from this sequence of commands are the mirrored y1 ticks, not the y2 ticks.

> Is is possible to set them independently?

Certainly.
   set ytics nomirror
   set y2tics nomirror
   unset log y
   set log y2


On Wednesday 27 May 2009 11:45:56 Petr Mikulik wrote:
> There are wrong tics on the y2 axis if the following is set:
> 	set autoscale fix; set logscale y2

They look correct to me.
But to see them you have to first do
   set ytics nomirror
   set y2tics nomirror


> The problem was discovered in one of graphs produced by Octave.
> The problem is in gnuplot since version 4.0.
> 
> 
> reset
> set ytics
> set logscale y
> set yrange [1:100]
> 
> set y2tics
> set logscale y2
> set y2range [1:100]
> 
> plot 1+x*x
> 
> pause -1
> 
> set autoscale fix
> replot
> 
> 
> I don't see any reason why AUTOSCALE_FIXMIN causes double-exponentiation of 
> the y2 axis.

It doesn't.  If you change 'set autoscale fix' to 'set autoscale fixkeep'
then maybe that does what you want.  But I'm not entirely sure what you
were expecting, so perhaps not.

In any case, I think there is some confusion about whether you are
really looking at y2tics, or whether you are looking at mirrored y1tics. 

	Ethan

set autoscale fix; set logscale y2

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

There are wrong tics on the y2 axis if the following is set:
	set autoscale fix; set logscale y2
The problem was discovered in one of graphs produced by Octave.
The problem is in gnuplot since version 4.0.


reset
set ytics
set logscale y
set yrange [1:100]

set y2tics
set logscale y2
set y2range [1:100]

plot 1+x*x

pause -1

set autoscale fix
replot


I don't see any reason why AUTOSCALE_FIXMIN causes double-exponentiation of 
the y2 axis. Any idea?

***

Observation by John W. Eaton:

When I execute the following commands in gnuplot, the y2 tick marks appear
to be linearly spaced and the y2 tick labels do not appear:

  set logscale y2
  plot sin (x) axes x1y1, exp (x) axes x1y2

but after executing

  set logscale y
  replot

they do appear, but then the y1 axis is also log scaled.  Is is possible to
set them independently?

---
PM

Re: Any simple way to create for loops?

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

On Sunday 24 May 2009, Mojca Miklavec wrote:

> I'm sorry that it took me so long to answer this, but I'm a bit
> confused. Two different solutions have been offered which has confused
> me even more.
> 
> If there's a patch on sourceforge - what does that imply? What should
> I do upon it?

The purpose of the patch tracker on SourceForge is to float ideas for
possible additions to gnuplot.  If people show interest in a patch,
then it may be refined and improved by additional discussion and 
contribution, and moved into CVS when there seems to be a consensus.

Sometimes there are patches from multiple people that address the same
or related ideas, but using different approaches.  Then the discussion
helps to settle which approach is better.  Right now there are multiple
patches illustrating different approaches to adding block-structured
syntax.  There has beeen some discussion, but not a lot.  None of the
patches is a complete solution, so more work would be needed in any case.

> The syntax of both patches looks fine to me and I would be glad to use
> it, but I'm afraid to use it for the reports that I need to write if I
> cannot be sure if that code will still work once I update gnuplot or
> once I change the computer.

It would be helpful if you were to look at both, whether or not you 
actually build and test them, and report back something like 
"Patch A would be better for my use because ....,  but I like the
idea of <foo> from Patch B".  We need to hear feedback from a variety
of users in order to guide the choice of implementation.

> The problem is that I cannot tell:
> - if code has a potential to break anything since I don't know the
> source code well enough
> - what the guidelines for extending gnuplot syntax are
> Those two questions that are probably the most important when deciding
> about accepting or rejecting a patch both need to be addressed by main
> developers.

Exactly. That is why we need the discussion. 

> -----
> Unrelated to original question, but related to the two patches that
> have been proposed:
> 
> Approximately one half of patches on sourceforge have no resolution
> (neither accept nor reject). Often something like "won't fix" or "will
> fix, but needs some more testing" would help a lot.

I think you may be confusing items from two separate trackers.
"Won't fix" applies to bug reports, not to patches.  The great majority
of bug reports are dealt with relatively rapidly and then closed.

Patches are a different thing, and are rarely rejected outright.
They are collected on the tracker site in the hope that they will
generate discussion and additional  contributions. The tracker item is
closed only when the patch itself or some equivalent functionality has
been added to CVS.  

Some patches are quite old, but it is still very useful to have them
available for reference.  Sometimes there will be a request for feature X,
and we can say "So-and-so offered a patch #XYZ to implement something like
that. Please take at look and see whether that approach would provide what
you want."  In other words, often there needs to be discussion by the
potential users before a patch can be evaluated, and that discussion may
not happen until a long time has passed since the first version of the
patch was posted.

> It's a bit demotivating for authors of patches to get no feedback from
> main developers 

I can assure you that being a developer does not mean that I am familiar
with all parts and uses of gnuplot.  If someone offers a patch to part of
the program I have never used, what useful comment can I offer?
Feedback from the user community is equally, or even more, important for
evaluation of the patch's utility. Technical feedback about implementation
details can wait until there is evidence that the feature will be
generally useful.

> and what's worse: as time passes those patches become
> obsolete and probably stop working anyway because the original source
> code changes. This mailing list often helps a lot to resolve problems,
> but it would be great if someone with a clear vision of gnuplot future
> development could review the patches and say one of the following for
> each unresolved patch:
> 
> - accept it and close it

 This sometimes happens.  Particularly if the patch addresses something that
 one or more of the developers can evaluate directly.  For instance, if
 a patch adds a feature that I can see immediately would be useful for
 application in gnuplot-based tools I am already using, I can evaluate
 for myself whether it works as advertised.  

> - please provide more info/description (I don't understand what this
> patch is supposed to do)

 That should be the default state.  Although more often the issue is not
 "what does it do?", but "why would you want to do that?".  

> - unlikely to fix unless this or that happens
> - won't fix (with explanation) and close it
> - likely to fix, needs more thinking/testing

 If the word "fix" is appropriate, then the code should probably not be 
 submitted to the patch tracker at all, but rather attached to the
 corresponding bug report.

> (Long ago I wanted to fix and improve one of existing (almost broken)
> terminals and add another one, but neither rejection nor acception of
> patches or bugfixes made me lost any interest.)

 If you are talking about the context terminal, to the best of my
 recollection (a) it could not be used with the distributed version of
 context, so basically no one was in a position to try it out.
 Maybe for that reason, (b) no one ever spoke up to say "yes, it works" or
 "I would use it if it work", or best of all "this is great, but it would be
 even better if X, Y, and Z".  If my recollection is wrong, I apologize.
 Please point me to any discussion or  indications of general interest by
 other gnuplot users.  If nothing else, in the intervening time the distro I 
 use has switched to using texlive, which includes some version of context.
 If your driver now works with a common tex distribution, maybe you'll get
 more feedback now than you did the first time around?