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

Re: default & double terminal options

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

On Thursday 24 August 2006 11:38 am, Petr Mikulik wrote:
> >
> >> Shouldn't we provide a "dummy" command 'set termoptions' right
> >> now, with a proper implementation for postscript only (if
> >> possible), and with implementation for other terminals after 4.2?
>
> Sorry, I meant "unset termoptions".

I have no idea what "unset termoptions" is supposed to mean.
Could you please explain?

Right now, "set termoptions" simply passes the rest of the
command line to term->options().   

But I cannot see a parallel mechanism for "unset termoptions".
There is no such thing as term->unset_options(), and in general
you cannot just negate options anyhow.  You cannot, for example,
say either  "set term <foo> nofont 'Times'"
    or      "unset term <foo> font 'Times'"

It seems to me that Mojca had the right idea:
If all terminals allowed "set term <foo> default", then it would
be possible to allow "set termoption default".  In fact, it would
happen automatically as soon as you added "default" to the legal
options list.


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

Re: default & double terminal options

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

> As I remember, the need for an 'unset termoptions' or 'set termoptions 
> reset' command emerged some years ago for the first time. It came from the 
> octave community: how to reset terminal options to the default status 
> after a script has changed them on its own.

>> Shouldn't we provide a "dummy" command 'set termoptions' right now, with
>> a proper implementation for postscript only (if possible), and with
>> implementation for other terminals after 4.2?

Sorry, I meant "unset termoptions".

---
PM

Re: gnuplot on FreeBSD

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

Dhiman Barman writes:
> The following is a summary of what one has to do to hack gnuplot4.1's prepare
> to work on FreeBSD; thanks to Dan Andersen who made it work:
> 
> in the script 'prepare':
> 
> change all instances of 'make' with gmake.  Freebsd has it's
> own BSDesque make program.  The makefiles in gnuplot use features
> unavailable in bsd make, so gnu make must be used.
 
 This is not strictly correct. The auto* generated Makefiles work well with
 *BSD make, as is intended. But the "prepare" related stuff in Makefile.am.in
 fails. OBSD's make actually errors out where FBSD's make fails silently:

Using $< in a non-suffix rule context is a GNUmake idiom (line 11 of Makefile.am.in)

 I will address this. Ultimately, it is probably best to get rid of the
 various Makefile.am.in.

> work around FreeBSD's choice of naming autoconf and
> automake binaries with version numbers.  You can either modify the
> prepare script directly, or create a ~/bin directory and create symlinks
> like ~/bin/aclocal -> /usr/local/bin/aclocal19
 
 FreeBSD should really switch to metaauto ...

 I will address this, too. I have a patch ready to go into cvs that uses

ACLCAL=${ACLOCAL:-aclocal}
...

 etc. so that one can use, e.g. on FreeBSD (sh syntax - use env in t/csh):

$ AUTOCONF=autoconf259 AUTOHEADER=autoheader259 AUTOMAKE=automake19 ACLOCAL=aclocal19 ./prepare

 Unless there are objections, of course.

Re: default & double terminal options

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

On 8/21/06, Ethan Merritt wrote:
> On Monday 21 August 2006 02:17 pm, Mojca Miklavec wrote:
> > 1.)
> > is there a way to get the default terminal settings? Postscript
> > terminal provides an option "default", but most terminals don't
>
> There is no coherent philosophy at present.
> Several people have proposed that during the next round of
> development (after 4.2) we modify all terminal drivers to have
> "set term <foo> default" option.   It sounds reasonable to me.
>
> If you want to get a head start, go ahead and start putting together
> a patch that will convert your favorite terminals over to the new
> system.

I submitted a little patch to add the "default" option to the metapost term=
inal.

I would like to add it to PNG & PDF, but I have no idea how to compile
it properly (and thus I can't test it). I changed the compiler
yesterday (I was using MS Visual Studio - PNGs are crashing with that
compilation, and gave a try to MinGW). The very first time it worked,
but when I recompiled for the second time gnuplot started crashing
again. I have absolutely no clue about makefiles & compilers.

On 8/22/06, Hans-Bernhard Br=F6ker wrote:
> Mojca Miklavec wrote:
> > The most safe way would be to write a single script for each input
> > (which is what is done now), but that influences efficiency
> > considerably (think of calling gnuplot 30 times versus calling gnuplot
> > only once with 30 plot commands and perhaps a few changes of the
> > terminal and output file inbetween).
>
> Huh?  What does having separate scripts have to do with running a
> completely new instance of gnuplot for each script?

I didn't understand your question, but the two alternatives I had in
mind were the following:

option A
----------
file1.plt:

set term png default
set term png transparent
plot sin(x)
set term png default
plot cos(x)

> gnuplot file1.plt

option B
----------
file1.plt

set term png transparent
plot sin(x)

file2.plt

set term png
plot cos(x)

> gnuplot file1.plt
> gnuplot file2.plt

The second option is considerably slower when dealing with lots of plots.

> > Example:
> > the user selects PNG terminal and wants the first figure to be
> > transparent and the second one to use "default" values (whatever they
> > are, notransparent in that case).
>
> Then the user should have a look at 'set term push' and 'set term pop',
> and maybe at 'save terminal', too.

set term push/pop preserve old terminal settings.
    set term png transparent
    set pop
    set term png
will still result in "transparent".

"save terminal" (the option which I didn't know so far) does almost
exactly the thing that I want, but reading and writing from files when
things could be solved in another way is also an additional overhead.

There is also one additional issue (buglet perhaps?).

set term png
save terminal 'a.dat'
set term png transparent
load 'a.dat'

will keep transparent option since "notransparent" is not written to
the file and thus not reset when loading that file.

On 8/22/06, Hans-Bernhard Br=F6ker wrote:
> Petr Mikulik wrote:
> > Shouldn't we provide a "dummy" command 'set termoptions' right now, wit=
h
> > a proper implementation for postscript only (if possible), and with
> > implementation for other terminals after 4.2?
>
> What do you mean by "should we provide" it?  "set termoption" already
> exists as a command, and has done for about 2 years at last, now.

So perhaps it's only "set termoption default" the one that is missing?

Mojca

Re: can't set term to x11

[Shehu S. A. <she...@ya...>]

--- Hans-Bernhard Bröker
<br...@ph...> wrote:

> .  You'll have to install some package called
> "X11 development" 
> or similar from your distributor --- and odds are

That helped, and now I get 

$ gnuplot
Expected X11 driver: 
usr/local/libexec/gnuplot/4.1/gnuplot_x11
Exec failed: Permission denied
See 'help x11' for more details

I have checked gnuplot_x11 got right permissions.




		
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Missing/invalid data points in PM3D

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

While investigating a bug report on comp.graphics.apps.gnuplot
I discovered what appears to be a long-standing coding bug in
the data input loop of plot3d.c.   In outline, the main loop
looks like this:

  while ((j = df_readline(v,MAXDATACOLS)) != DF_EOF) {
     cp = local_this_iso->points + xdatum;

     ... lots of conditional stuff ...

     come_here_if_undefined:
        ++xdatum;
  }  /* end of whileloop - end of surface */


The tricky bit is the increment of xdatum at the end, which
is the only thing that advances the cp (current point) pointer.
Most of the conditional tests either reach the end of the while
clause naturally, or terminate prematurely via an explicit jump:
  goto come_here_if_undefined;
However, two cases terminate via a "continue" statement instead,
which means that the current point is not incremented.
In particular there is this test:

    if (j == DF_UNDEFINED || j == DF_MISSING) {
        cp->type = UNDEFINED;
        continue;
    }

Setting cp->type to UNDEFINED is useless, because cp itself is not
incremented. So during the next iteration of the while clause it is
over-written with the next data point.  This messes up the gridding
structure, and leads to the problem reported on the newsgroup.

It seems clear to me that at least for gridded surfaces the 
"continue" statement should be replaced by a jump to 
come_here_if_undefined.  That does, in fact, fix the specific 
problem reported on the newsgroup.

However, I am dubious about the affect this has on PM3D output.
I tried replacing one of the data points in triangle.dat with a
nonsense string, or with NaN, and issuing the commands

	splot 'triangle.dat' using 1:2:3 with pm3d
	splot 'triangle.dat' using ($1):($2):($3) with pm3d

The results are odd, to say the least.

Version 4.0:
  Very, very odd behavior (try rotating it!).

The current cvs version:
  1st command distorts the grid, which I would predict,
  2nd command distorts and also produces a strange coloring.

Current cvs patched to increment xdatum before continuing:
  1st command distorts the grid (but why?)
  2nd command has no grid distortion, but loses the entire rest of
      the grid line after the invalid point

No version of gnuplot that I have here acts as I would expect.

What is supposed to happen if pm3d sees an invalid point?
Leave a hole in the surface?
Interpolate the color from the surrounding blocks?
Error exit?
Something else?   (see note)


Note:
I originally understood the documentation under 
"help splot datafile" to mean that in case the 3rd value on the
input line was unusable, the previous z value was used
("last value"). But upon rereading I am not sure that was the
intent. It says:

  If two or four values are provided, `gnuplot` uses the last
  value for calculating the color in pm3d plots.

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

Re: can't set term to x11

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

Shehu S. AbdusSalam wrote:
> i can't set term to X11 on 4.1
> there is no X11 in the list from

> $set term

That's because you built your own gnuplot, but didn't take care to read 
the READMEs and have a look at your ./configure output --- or you would 
have noticed that it said it couldn't find the X11 libraries and 
headers.  You'll have to install some package called "X11 development" 
or similar from your distributor --- and odds are you're better off 
installing their gnuplot binary package, too, while at it.

can't set term to x11

[Shehu S. A. <she...@ya...>]

i can't set term to X11 on 4.1
there is no X11 in the list from

$set term

i've tried fillbetween.dem but couldn't get any of the
colouring right in all the three demos.

any ideas what's going on?

shehu


		
___________________________________________________________ 
All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

Re: automake version mismatch

[Shehu S. A. <she...@ya...>]

thanks. i guess it was a conflict between automake
version 1.4 and 1.7. i installed version 1.7 in order
to have aclocal.

i have solved that problem by downloading and
installing GNU autotools from the GNU site.

Cheers
Shehu


--- Hans-Bernhard Bröker
<br...@ph...> wrote:

> Shehu S. AbdusSalam wrote:
> > mv Makefile.amt Makefile.am
> > configure.in:10: version mismatch.  This is
> Automake
> > 1.7.9,
> 
> That line number makes no sense.  Line 10 of the
> current CVS version of 
>   configure.in is a comment.
> 
> > I will be glad for how to get around this.
> 
> You didn't give us terribly much information to work
> with.  The cause is 
> obviously an automake version mixup, so at the very
> least, you have to 
> figure out which versions of the relevant tools you
> have:
> 
> 	aclocal --version
> 	automake --version
> 	autoconf --version
> 
> (and make sure you have only *one* version of each
> of these visible to 
> the shell from which you're doing this).  It might
> also help to know 
> what platform you're doing this on.
> 
> 


		
___________________________________________________________ 
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

Re: automake version mismatch

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

Shehu S. AbdusSalam wrote:
> mv Makefile.amt Makefile.am
> configure.in:10: version mismatch.  This is Automake
> 1.7.9,

That line number makes no sense.  Line 10 of the current CVS version of 
  configure.in is a comment.

> I will be glad for how to get around this.

You didn't give us terribly much information to work with.  The cause is 
obviously an automake version mixup, so at the very least, you have to 
figure out which versions of the relevant tools you have:

	aclocal --version
	automake --version
	autoconf --version

(and make sure you have only *one* version of each of these visible to 
the shell from which you're doing this).  It might also help to know 
what platform you're doing this on.

Re: default & double terminal options

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

Petr Mikulik wrote:
> Shouldn't we provide a "dummy" command 'set termoptions' right now, with 
> a proper implementation for postscript only (if possible), and with 
> implementation for other terminals after 4.2?

What do you mean by "should we provide" it?  "set termoption" already 
exists as a command, and has done for about 2 years at last, now.

Re: default & double terminal options

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

>> The most safe way would be to write a single script for each input
>> (which is what is done now), but that influences efficiency
>>
>> the user selects PNG terminal and wants the first figure to be
>> transparent and the second one to use "default" values (whatever they
>> are, notransparent in that case).

As I remember, the need for an 'unset termoptions' or 'set termoptions 
reset' command emerged some years ago for the first time. It came from the 
octave community: how to reset terminal options to the default status after 
a script has changed them on its own.

Shouldn't we provide a "dummy" command 'set termoptions' right now, with a 
proper implementation for postscript only (if possible), and with 
implementation for other terminals after 4.2?

---
PM

Re: default & double terminal options

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

Mojca Miklavec wrote:
> The most safe way would be to write a single script for each input
> (which is what is done now), but that influences efficiency
> considerably (think of calling gnuplot 30 times versus calling gnuplot
> only once with 30 plot commands and perhaps a few changes of the
> terminal and output file inbetween).

Huh?  What does having separate scripts have to do with running a 
completely new instance of gnuplot for each script?


> Example:
> the user selects PNG terminal and wants the first figure to be
> transparent and the second one to use "default" values (whatever they
> are, notransparent in that case).

Then the user should have a look at 'set term push' and 'set term pop',
and maybe at 'save terminal', too.

Re: default & double terminal options

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

On Monday 21 August 2006 02:17 pm, Mojca Miklavec wrote:
> 1.)
> is there a way to get the default terminal settings? Postscript
> terminal provides an option "default", but most terminals don't

There is no coherent philosophy at present.
Several people have proposed that during the next round of
development (after 4.2) we modify all terminal drivers to have
"set term <foo> default" option.   It sounds reasonable to me.

If you want to get a head start, go ahead and start putting together
a patch that will convert your favorite terminals over to the new
system.

	Ethan



> (metapost terminal sets everything back to default values without
> asking for it which is probably against the main phylosophy of how
> terminals should work, but that's another topic which I don't intend
> to discuss here).
>
> I would like to write a longer gnuplot script with multiple changes of
> terminal type and output file. The input will be provided from outside
> (from other users, so I can't assume anything about it in advance).
>
> The most safe way would be to write a single script for each input
> (which is what is done now), but that influences efficiency
> considerably (think of calling gnuplot 30 times versus calling gnuplot
> only once with 30 plot commands and perhaps a few changes of the
> terminal and output file inbetween).
>
> Example:
> the user selects PNG terminal and wants the first figure to be
> transparent and the second one to use "default" values (whatever they
> are, notransparent in that case).
>
> first plot:
> ********
> terminal: png
> additional options: transparent
> script: plot sin(x)
>
> second plot:
> ********
> terminal: png
> additional options: -
> script: plot sin(x)
>
> The first approach would be to write two scripts, while the "efficient
> one" would be to do something like this:
>
> set term png transparent
> set output 'p001.png'
> set title 'first plot'
> plot sin(x)
> reset
> # how to get the default terminal settings again?
> set term png
> set output 'p002.png'
> plot sin(x)
>
> "reset" is very handy, but I'm looking for a similar thing for
> terminal settings as well.
>
>
> In the worst case I can still warn the user that it's his own fault if
> he wants to do such obscure things and that it's his own
> responsibility to set the things back as they were. Or I can leave the
> inefficient version there, but I would be very happy if there was some
> "magic reset switch" for terminal settings as well. (There's only one
> thing I'm sure about: I don't want to parse options in that program to
> set them back to defaults.)
>
>
> 2.)
> What is the main phylosophy behind terminals. Is a sentence like
>     set terminal post color monochrome
> allowed? Well, the above is not, but for example
>     set term png notransparent transparent
> doesn't complain. I prefer the later, since I don't have to worry then
> if I set some settings which I consider to be default for my purpose
> (for example "set term post color") and simply append user-provided
> ones to the end of the string (if user wants portrait, the command
> would become "set term post color portrait", if the user wants
> monochrome, the command would become "set term post color monochrome",
> but that doesn't work).
>
> OK, I know, I can do it in two steps. I can first apply my own
> defaults and then user-provided ones (wouldn't work with metapost, but
> then again: I don't care about metapost terminal too much).
>
> There are some work-arounds, but life would be much easier if
> behaviour would be more consistent accross terminals. (I see no reason
> why someone would make a restriction that an option may not be
> specified more than once.)
>
> Thank you very much for any answer,
>     Mojca
>
> ------------------------------------------------------------------------
>- Using Tomcat but need to do more? Need to support web services,
> security? Get stuff done quickly with pre-integrated technology to make
> your job easier Download IBM WebSphere Application Server v.1.0.1 based
> on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

default & double terminal options

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

Hello,

1.)
is there a way to get the default terminal settings? Postscript
terminal provides an option "default", but most terminals don't
(metapost terminal sets everything back to default values without
asking for it which is probably against the main phylosophy of how
terminals should work, but that's another topic which I don't intend
to discuss here).

I would like to write a longer gnuplot script with multiple changes of
terminal type and output file. The input will be provided from outside
(from other users, so I can't assume anything about it in advance).

The most safe way would be to write a single script for each input
(which is what is done now), but that influences efficiency
considerably (think of calling gnuplot 30 times versus calling gnuplot
only once with 30 plot commands and perhaps a few changes of the
terminal and output file inbetween).

Example:
the user selects PNG terminal and wants the first figure to be
transparent and the second one to use "default" values (whatever they
are, notransparent in that case).

first plot:
********
terminal: png
additional options: transparent
script: plot sin(x)

second plot:
********
terminal: png
additional options: -
script: plot sin(x)

The first approach would be to write two scripts, while the "efficient
one" would be to do something like this:

set term png transparent
set output 'p001.png'
set title 'first plot'
plot sin(x)
reset
# how to get the default terminal settings again?
set term png
set output 'p002.png'
plot sin(x)

"reset" is very handy, but I'm looking for a similar thing for
terminal settings as well.


In the worst case I can still warn the user that it's his own fault if
he wants to do such obscure things and that it's his own
responsibility to set the things back as they were. Or I can leave the
inefficient version there, but I would be very happy if there was some
"magic reset switch" for terminal settings as well. (There's only one
thing I'm sure about: I don't want to parse options in that program to
set them back to defaults.)


2.)
What is the main phylosophy behind terminals. Is a sentence like
    set terminal post color monochrome
allowed? Well, the above is not, but for example
    set term png notransparent transparent
doesn't complain. I prefer the later, since I don't have to worry then
if I set some settings which I consider to be default for my purpose
(for example "set term post color") and simply append user-provided
ones to the end of the string (if user wants portrait, the command
would become "set term post color portrait", if the user wants
monochrome, the command would become "set term post color monochrome",
but that doesn't work).

OK, I know, I can do it in two steps. I can first apply my own
defaults and then user-provided ones (wouldn't work with metapost, but
then again: I don't care about metapost terminal too much).

There are some work-arounds, but life would be much easier if
behaviour would be more consistent accross terminals. (I see no reason
why someone would make a restriction that an option may not be
specified more than once.)

Thank you very much for any answer,
    Mojca

automake version mismatch

[Shehu S. A. <she...@ya...>]

I am trying to build gnuplot 4.1 from the cvs and got
stucked with:

mv Makefile.amt Makefile.am
configure.in:10: version mismatch.  This is Automake
1.7.9,
configure.in:10: but the definition used by this
AM_INIT_AUTOMAKE
configure.in:10: comes from Automake 1.4-p6.  You
should recreate
configure.in:10: aclocal.m4 with aclocal and run
automake again.
 
Some part of the preparation process failed.
Please refer to INSTALL for details.

I will be glad for how to get around this. Thanks,

ssa



		
___________________________________________________________ 
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

Re: 'data-file' as a string variable in the "plot" command

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

On Sunday 20 August 2006 11:50 am, Daniel J Sebald wrote:
> 
> Perhaps he means:
> 
> gnuplot> print "string one"" string two"
>                            ^
>          ';' expected
> 
> I think in C that is a valid concatenation.

So what?  Different languages have different syntax.
We have a perfectly well-defined syntax for
string concatenation, and that isn't it.

gnuplot> print "AAA"."BBB"
AAABBB



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

Re: 'data-file' as a string variable in the "plot" command

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

Hans-Bernhard Broeker wrote:
> On Fri, 18 Aug 2006, Constantine Nenkov wrote:
> 
> 
>>Latex extensions. Unfortunately the "plot" command doesn't accept the
>>name of the 'data-file' as a string variable. 
> 
> 
> That claim doesn't seem to coincide with my observation in a quick 
> experiment.  Please provide an actual example script that fails to work.
> 
> And, while at it, you should also specify what version of gnuplot you're 
> talking about.  This being the developers' mailing list you're posting to, 
> that had better be the latest CVS version.
> 
> 
>>"plot" command. The other option of the possibility of concatenating
>>various string variables for that purpose, as is done in high level
>>compiled languages like FORTRAN and C/C++, will be also very welcome.
> 
> 
> What on earth are you talking about?  gnuplot has had string manipulation
> quite exactly as long as it has had string variables.

Perhaps he means:

gnuplot> print "string one"\
> " string two"
string one

gnuplot> print "string one"" string two"
                           ^
         ';' expected

I think in C that is a valid concatenation.

Dan

Re: 'data-file' as a string variable in the "plot" command

[Hans-Bernhard B. <br...@ph...>]

On Fri, 18 Aug 2006, Constantine Nenkov wrote:

> Latex extensions. Unfortunately the "plot" command doesn't accept the
> name of the 'data-file' as a string variable. 

That claim doesn't seem to coincide with my observation in a quick 
experiment.  Please provide an actual example script that fails to work.

And, while at it, you should also specify what version of gnuplot you're 
talking about.  This being the developers' mailing list you're posting to, 
that had better be the latest CVS version.

> "plot" command. The other option of the possibility of concatenating
> various string variables for that purpose, as is done in high level
> compiled languages like FORTRAN and C/C++, will be also very welcome.

What on earth are you talking about?  gnuplot has had string manipulation
quite exactly as long as it has had string variables.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

'data-file' as a string variable in the "plot" command

[Constantine N. <ne...@at...>]

String variables in GnuPlot are associated with various commands like "label",
"title", 'key', etc. This is all nice since one can even use Latex extensions.
Unfortunately the "plot" command doesn't accept the name of the 'data-file' as
a string variable. In a way it is kind of hard-wired into this most important 
of commands, around which the whole system is built. Very often (at least in 
my scripts!) I need to change the names (or only part of the names!) of my 
input data files, which are being processed for plotting, on the fly directly 
in my script. But due to the fact that I can not use a string variable as the 
name of a data file I have to go outside the GnuPlot system, run a Sequential 
Editor on the GnuPlot script in order to change the names of the data-files, 
and then return back to GnuPlot. Quite often this is nuisance and time 
consuming.

Therefore, my advice to the developers of future versions of this very useful 
plotting and visualization system is to incorporate, if possible, the option 
of using 'data-file' names as string variables in the generic "plot" command.
The other option of the possibility of concatenating various string variables 
for that purpose, as is done in high level compiled languages like FORTRAN and 
C/C++, will be also very welcome.

Any comment from the developers will be highly appreciated. Thanks a lot.

Best regards,
Constantine Nenkov

Re: Interesting bug: relative offset + log scale = problem

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

On Wednesday 16 August 2006 03:19 pm, Hans-Bernhard Br=F6ker wrote:
> Ethan Merritt wrote:
> > Zero is zero.
>
> Not on a logarithmic axis it ain't.  On a logarithmic axis, offset
> zero is actually negative infinity.  If the user wanted an offset of
> _visually_ zero, then on a log axis the gnuplot way of saying so
> would be to specify an offset factor of 1.

I concede the point.

I will apply the minimal fix of initializing the default histogram
title structure to specify 0 character units for the offset.

If the user explicitly changes it to something else that breaks=20
in the presence of a log-scaled axis, that's their own headache.

> increments to logarithmic values are specified as values that
> have to be  logarithmized, following the way 'set xtics <incr>'=20
> behaves  ...

> The offsets of axis labels and titles should work the same way.

Probably.  But those are already correctly defaulting to character
units.  I'm trying very hard not to touch any of the core code at
this point.


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

Re: Interesting bug: relative offset + log scale = problem

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

Hans-Bernhard Br=F6ker wrote:

> The same way he can enter an increment for logarithmic tics: as a=20
> factor, instead of the usual summand.

OK, you say "factor".  Here is what I sent to Ethan and what I think you =
are saying:

...

That is

y_title =3D alpha * y_hist;

Then

 log(y_title) =3D log(y_hist) + log(alpha)

and right there the log(alpha) is the "offset" we are searching for.

Is THIS what the user is thinking of when saying offset?  I'm guessing no=
, because in all likelihood the user would never enter an "offset" (i.e.,=
 alpha) of zero and it should be invalid.  If that is how we compute "off=
set", then the user will typically be entering something like 1.1 or 1.05=
, etc.

...

You are saying that the code is then correct (except for moving the compu=
tation of x_offset and y_offset outside the loop for efficiency) and 0 is=
 an invalid user entry.  Perhaps we should have an error message:

  For logarithm scale, 0 is not a valid factor.  Try a factor of 1.

Dan

Re: Interesting bug: relative offset + log scale = problem

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

Ethan Merritt wrote:

> I am leaning towards the idea that map_position_r() needs a
> top level check on entry for zero offsets.
> Who cares whether it's zero characters, zero plot units,
> or zero something else?
> Zero is zero.

Not on a logarithmic axis it ain't.  On a logarithmic axis, offset zero 
is actually negative infinity.  If the user wanted an offset of 
_visually_ zero, then on a log axis the gnuplot way of saying so would 
be to specify an offset factor of 1.

> But it may also be true that map_position_r() should never
> do range checking, even for non-zero offsets.  

Then you should be glad --- because it doesn't actually do range 
checking.  It does illegal value checking on logarithmically scaled 
values, which is a different thing.

This is ultimately a usage error we're looking at, possibly caused by 
insufficient documentation.  In gnuplot, the tradition is that 
increments to logarithmic values are specified as values that have to be 
logarithmized, following the way 'set xtics <incr>' behaves on log axes:

	set log x
	set log y 2.0
	set ytics 16
	plot [1e-3:1e3] x

The offsets of axis labels and titles should work the same way.

Re: Interesting bug: relative offset + log scale = problem

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

Daniel J Sebald wrote:

> Well, this is sort of my point.  As far as placement of text (or
> color box, or whatever) why does that need to be in a logarithmic
> scale?  

Because on a logarithmic axis, that's the only data scale there is
(but see 'graph', 'char' or 'screen' coordinate systems).

> OK, if we are saying the user can enter an _offset_ for title
> placement, well then I don't see how we can expect the user to enter
> that as a logarithmic value pertaining to a logarithmic scale.

The same way he can enter an increment for logarithmic tics: as a 
factor, instead of the usual summand.

> Ignoring the mathematical limitations for now, from a conceptual
> standpoint, that would mean the visual offset is different for each
> value.  

Only if we did it even wronger than the code dug out by Ethan.

> What is the sense of working with logarithmic values if the offset is
> always going to be a constant?  

None.  Which is why that's not what we're doing.

 > Why can't the user indicate an offset
> using, say, a linear screen scale value?

He can.  But he should be *allowed* to specify it in data coordinates, too.

Re: Interesting bug: relative offset + log scale = problem

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

Ethan Merritt wrote:
> On Wednesday 16 August 2006 12:26 pm, you wrote:
> 
> 
>>Well, the test should be against 
>>the eventual placement, not the offset, right? 
>>I would guess this:
>>
>>	    x = map_x((hist->start + hist->end) / 2.);
>>	    y = xlabel_y;
>>	    x += (int)xoffset_d;
>>	    y += (int)yoffset_d + 0.25 * term->v_char;
>>
>>has to come before this:
>>
>>	    map_position_r(&(histogram_opts.title.offset), &xoffset_d,
>>&yoffset_d, "histogram");
> 
> 
> That would be absurd.
> The whole *point* of map_position_r() is to calculate for you
> what needs to be added to the x,y coordinates.  If you're going
> to do that everywhere in-line, then there is no need for
> the map_position_r() routine at all.

Well, perhaps there isn't... But first, if we are talking efficiency, why is the following inside the inner loop?

	if (hist->title.text && *(hist->title.text)) {
	    double xoffset_d, yoffset_d;
	    map_position_r(&(histogram_opts.title.offset), &xoffset_d, &yoffset_d,
			   "histogram");

Aren't the values of xoffset_d and yoffset_d going to be the same every pass?  Why keep calculating them?


> I am leaning towards the idea that map_position_r() needs a
> top level check on entry for zero offsets.
> Who cares whether it's zero characters, zero plot units,
> or zero something else?
> Zero is zero.

Well, this is sort of my point.  As far as placement of text (or color box, or whatever) why does that need to be in a logarithmic scale?  Now, I can understand if the user options have manual placement, then fine.  As with tics, etc. the user needs to think in terms of the logarithmic scale and do a bit of computing; a bit of arduous work.

OK, if we are saying the user can enter an _offset_ for title placement, well then I don't see how we can expect the user to enter that as a logarithmic value pertaining to a logarithmic scale.  Ignoring the mathematical limitations for now, from a conceptual standpoint, that would mean the visual offset is different for each value.  However, that is not how the code works.  In the code I see and as you describe the idea is to compute the offset and have it be the same no matter the histogram bin height.  So ostensibly, we're taking a quantity we expect the user to enter as some kind of logarithmic offset and then convert that back to something working on a linear scale?  (It is difficult to follow sometimes exactly what scale gnuplot is using without trial and error.)

What is the sense of working with logarithmic values if the offset is always going to be a constant?  Why can't the user indicate an offset using, say, a linear screen scale value?

Dan