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

Re: ./prepare asks for ./config.guess and config.sub

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

On Wednesday 08 June 2005 04:33 am, Ga=EBl Varoquaux wrote:
>   I am being very stupid but the prepare script from the CVS asks from
> two file it cannot find :
>=20
> automake: configure.in: required file `../config.guess' not found
> automake: configure.in: required file `../config.sub' not found

This is a problem with certain versions of automake/autoconf.
I never figured out exactly which versions.  But the work-around
is=20
	touch config.guess
	touch config.sub

I.e., it doesn't matter what's in the files, just that they exist.
I reported this as a configuration bug quite a while back.
=20
>    I also find it strange that, if you don't give a --prefix=3Dfoobar, you
> need root permission to make (and not make install). "make" should never
> need root permission.

Yes, I've been griping about this for ages as well.
The lisp subsystem is totally broken for non-root builds.
I *hope* I've fixed this at least in the case that you specify
	 ./configure --without-lisp-files
But I keep on finding more annoying lisp intrusions.

Note to everyone: =20
Is there any strong reason to keep --with-lisp-files as the default?
To me it is just a continual annoyance, because I keep
forgetting to disable it before building on a new system.

=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: ./prepare asks for ./config.guess and config.sub

[V. <gae...@no...>]

On Thu, Jun 09, 2005 at 01:58:56AM +0800, Hans-Bernhard Br=F6ker wrote:
> That's almost guaranteed to be a case of your automake or autoconf=20
> version being too old to be usable with gnuplot.

    Right, good guess ! Looks like the debian package changed its name to
automake1.9 rather than automake (I ran version 1.4). They claim they do
not want to superseed the old versions as " Automake 1.9 fails to work in
a number of situations that Automake 1.4, 1.6, 1.7 and 1.8 did". Its a
bit of a strange policy.

   Thank you for your help, I have updated my automake and the ./prepare
script does indeed work, and make does not any longer need root
permissions.

--=20
  Ga=EBl=20

Re: ./prepare asks for ./config.guess and config.sub

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

Gaël Varoquaux wrote:
>   I am being very stupid but the prepare script from the CVS asks from
> two file it cannot find :
> 
> automake: configure.in: required file `../config.guess' not found
> automake: configure.in: required file `../config.sub' not found

That's almost guaranteed to be a case of your automake or autoconf 
version being too old to be usable with gnuplot.

>    I also find it strange that, if you don't give a --prefix=foobar, you
> need root permission to make (and not make install). "make" should never
> need root permission.

Until you've updated to current auto-tools, it's moot to speculate about 
this.  If it still happens after that step, please provide more 
information: which step did fail, and how?

Re: ./prepare asks for ./config.guess and config.sub

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

Ga=EBl Varoquaux wrote:
>   I am being very stupid but the prepare script from the CVS asks from
> two file it cannot find :
>=20
> omicron ~/gnuplot $ ./prepare
> make: `Makefile.am' is up to date.
> make: `Makefile.am' is up to date.
> make: `Makefile.am' is up to date.
> make: `Makefile.am' is up to date.
> make: `Makefile.am' is up to date.
> automake: configure.in: required file `../config.guess' not found
> automake: configure.in: required file `../config.sub' not found

Not normal.  Try executing the script by changing to the directory rather=
 that=20
indirectly using "~/gnuplot".  Perhaps you've revealed a problem.  Could =
be a=20
different problem.

Dan

Re: ./prepare asks for ./config.guess and config.sub

[V. <gae...@no...>]

On Wed, Jun 08, 2005 at 12:22:32PM -0500, Daniel J Sebald wrote:
> Ga=EBl Varoquaux wrote:
> >omicron ~/gnuplot $ ./prepare
> >make: `Makefile.am' is up to date.
> >make: `Makefile.am' is up to date.
> >make: `Makefile.am' is up to date.
> >make: `Makefile.am' is up to date.
> >make: `Makefile.am' is up to date.
> >automake: configure.in: required file `../config.guess' not found
> >automake: configure.in: required file `../config.sub' not found

> Not normal.  Try executing the script by changing to the directory rath=
er=20
> that indirectly using "~/gnuplot".=20

    Sorry, I wasn't very clear in my last message :=20
"omicron ~/gnuplot $" is my prompt, which I did not remove from my post.
I am indeed executing the scripts from the directory.

--
  Ga=EBl

Re: gnuplot slow on BIG files

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

> Do what you think is better: optimize the current parser, rewrite a new
> one, or use mine as a base for improvement. One thing I know for sure:
> it shouldn't stay as it is.
>
> The patch I published is against the file:
> gnuplot-4.0.0/src/datafile.c

Can you please update it for the current datafile.c from cvs on sourceforge?
(There are minor rejects.)

---
PM

Re: gnuplot slow on BIG files

[Dimitrios A. <ji...@gm...>]

> (OK, saw this file in a backlog of email.  Hans must be sending these 
> through manually.)  It is a possibility.  That matrix code is sort of a 
> tacked on thing.  But unless we understand what the problem is how can 
> we know that there is extraneous, inefficient code?  However, if you 
> believe what you've coded meets the definitions and format in the 
> documentation and is faster, then consider redoing the patch with the 
> old, unneeded code removed.  Otherwise, it will leave cruft floating 
> about, just what you are attempting to improve upon.

My patch certainly doesn't meet any definitions or format. I have no 
time right now to rewrite the patch correctly and according to the 
coding standards. If you wish that I send you another patch with the old 
code replaced, tell me so and I will. However it will be of the same 
(low) quality, which I think is not ready to replace the current code.

Did anyone actually tried it to see the speed improvement? I have done 
no benchmarks but what I described in an earlier email (how to plot big 
SRTM files) now works *much* faster (*10 or more speed improvement).

For now I will be happy to see an entry in the TODO file about 
optimizing the highly innefficient "matrix" parser. In the future, if 
you haven't found the time to fix it, perhaps I will submit a proper 
patch, compliant to the coding standards and good enough for you to use it.

Thanks,
Dimitris

./prepare asks for ./config.guess and config.sub

[V. <gae...@no...>]

  I am being very stupid but the prepare script from the CVS asks from
two file it cannot find :

omicron ~/gnuplot $ ./prepare
make: `Makefile.am' is up to date.
make: `Makefile.am' is up to date.
make: `Makefile.am' is up to date.
make: `Makefile.am' is up to date.
make: `Makefile.am' is up to date.
automake: configure.in: required file `../config.guess' not found
automake: configure.in: required file `../config.sub' not found

  On my system I found=20
/usr/share/automake/config.guess
/usr/share/automake/config.sub

   I copied them in the gnuplot directory and then the prepare script
worked. Is this normal ?

   I also find it strange that, if you don't give a --prefix=3Dfoobar, yo=
u
need root permission to make (and not make install). "make" should never
need root permission.

--
  Ga=EBl

Re: Gnuplot logarithmic contours and palette

[Aapo L. <aap...@gm...>]

On Tue, 2005-06-07 at 19:52 +0200, Hans-Bernhard Bröker wrote:
> As so often, that depends on the background of the person doing the 
> expecting...
> 
> The right way of handling this would have been to do it like the other
> "tick series" things in gnuplot do it, i.e. like 'set xtics'.  Which 
> means the endpoints are numbers in the input format, but the increment
> is a *factor*, not an addition to the logarithm.

That's cool.  I made a new patch that implements it that way.


> So '5,2,200' should have delivered tics at (5,10,20,40,80,160)

Now the z ticks are exactly like that.  And the patch is even
simpler.  :-)


> Taking into account prior art, it is.  It just fails to be implemented 
> that way ;-(

Ok, thank you.  I don't have very deep knowledge of Gnuplot, so I didn't
realise that.  But now it's fixed, see the attached patch.

Best Regards,
Aapo Lankinen

-- 
Aapo Lankinen <aap...@gm...>

Re: gnuplot slow on BIG files

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

Dimitrios Apostolou wrote:
> Daniel J Sebald wrote:
> 
>> Please *explain* why the patch is faster.  Those listening will 
>> understand. Also, when running diff be sure to use unified (-u) so 
>> that it indicates what file the hunks come from.
> 
> 
> I don't know why it is faster. I just wrote a simple parser. I don't 
> understand what more the old parser does. I just can see that it is much 
> more complicated. My guess is that after so many years of development 
> and after many additions that today we see but can't figure out, the 
> code became a bit "bloated".

(OK, saw this file in a backlog of email.  Hans must be sending these through 
manually.)  It is a possibility.  That matrix code is sort of a tacked on thing. 
  But unless we understand what the problem is how can we know that there is 
extraneous, inefficient code?  However, if you believe what you've coded meets 
the definitions and format in the documentation and is faster, then consider 
redoing the patch with the old, unneeded code removed.  Otherwise, it will leave 
cruft floating about, just what you are attempting to improve upon.

Thanks,

Dan

Re: Patches to clean up string-handling corner cases

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

> Currently the check for single- or double- quotes is made at
> the time a string constant is parsed, as in:
>   A = "1\n2"
>   B = '1\n2'
>   if (A ne B) print "Strings are not equal"

In my opinion, it should be this way.  When I have to choose between
single and double quotes, I take the ones which are more
convenient in the current situation.  I do not want to take into
account what can happen to them later.

Quite a few programming language offer both single and double quotes
having different syntax (bash, perl, ...).  But I'm not aware of a
single one that keeps track wether a given string has been typed in
this or that way.

> But if you assign a value to a string variable via some more
> complex path, including your new system() function, then there
> is no check for whether embedded special characters should be
> given the single-quote treatment (store raw input) or the
> double-quote treatment (add \ in front of certain characters).

It works the way I would want it to have.  You can't input a newline
character directly on the command line, so there has to be a way to
get it into strings nevertheless.  There is no such problem within
pipes.  If I need a newline in the string returned by system(), I'll
use one.  I don't see any need for escape sequences in this case.


> As you can see from the sequence below, it does not
> work to define and invoke a macro on the same input line:
>
> gnuplot> set macros
> gnuplot> foo = "1"; print @foo;  foo = "2"; print @foo
>          warning: foo is not a string variable
>          warning: foo is not a string variable
>
> gnuplot> foo = "1"; print ;  foo = "2"; print
>                           ^
>          constant expression required

I wouldn't really expect this to work.


Juergen

Re: eps file

[V. <gae...@no...>]

On Tue, Jun 07, 2005 at 10:23:52AM -0700, Ethan Merritt wrote:
> >   You can always use the quick and dirty solutions : delete the line =
of
> > your eps file starting with :
> > %%BoundingBox:=20

> ???
> I think you have that backwards.
> It is exactly the BoundingBox line that tells an application program
> which portion of the page is of interest.  If you *remove* that line,
> then you will probably get an entire, mostly blank, page.=20

   Sure, I forgot to add that you should rebuild a bounding box with
ps2eps.

--
  Ga=EBl

Re: Gnuplot logarithmic contours and palette

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

` Lankinen wrote:

> You're welcome.  However, I found a new bug in the Gnuplot 4.1 CVS
> logarithmic contours code.  The following script doesn't work as
> expected:

As so often, that depends on the background of the person doing the 
expecting...

The right way of handling this would have been to do it like the other
"tick series" things in gnuplot do it, i.e. like 'set xtics'.  Which 
means the endpoints are numbers in the input format, but the increment
is a *factor*, not an addition to the logarithm.

So '5,2,200' should have delivered tics at (5,10,20,40,80,160)

> One thing to note is that it's not generally quite clear what is meant
> by "cntrparam level incremental" in logarithmic space.  

Taking into account prior art, it is.  It just fails to be implemented 
that way ;-(

Re: eps file

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

On Tuesday 07 June 2005 08:01 am, Ga=EBl Varoquaux wrote:
> On Mon, Jun 06, 2005 at 02:02:57PM +0200, Hartmut Ehmler wrote:
> > For info, I copy here the first comment lines of my .eps file:
> > %!PS-Adobe-2.0 EPSF-2.0
> > %%Title: eps_example_file.eps
> > %%Creator: gnuplot 4.0 patchlevel 0
> > %%CreationDate: Mon Jun 06 14:01:44 2005
> > %%DocumentFonts: (atend)
> > %%BoundingBox: 50 50 301 226
> > %%Orientation: Portrait
> > %%EndComments
>=20
>   You can always use the quick and dirty solutions : delete the line of
> your eps file starting with :
> %%BoundingBox:=20

???
I think you have that backwards.
It is exactly the BoundingBox line that tells an application program
which portion of the page is of interest.  If you *remove* that line,
then you will probably get an entire, mostly blank, page.=20


=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: label offset error on 4.1

[KITA T. <t-...@cc...>]

From: Hans-Bernhard Br=F6ker <br...@ph...>
Subject: Re: label offset error on 4.1
Date: Tue, 07 Jun 2005 16:55:42 +0200
Message-ID: <42A...@ph...>

> KITA Toshihiro wrote:
> =

> > The problem happens when I set a label string and the offset at the=
 same time.
> > =

> > gnuplot> set xla "x"
> > gnuplot> set xla -10, -2
> > =

> > is OK, but, I get
> > =

> > gnuplot> set xla "x" -10, -2
> >                         ^
> >          invalid expression =

> =

> Please compare this command to the actual syntax description found un=
der =

> "help xlabel": you're missing the 'offset' keyword.

Oops, that was literally 'offset'!
Thanks a lot for your quick reply to my misunderstanding.
-- =

  KITA Toshihiro

Re: Gnuplot logarithmic contours and palette

[Aapo L. <aap...@gm...>]

On Wed, 2005-03-23 at 11:01 -0800, Ethan Merritt wrote:
> On Tuesday 22 March 2005 01:01 pm, Aapo Lankinen wrote:
> > same colour.  I removed the other de-log, and following patch fixes the
> > problem at least for me.  :-)
> 
> Thanks.  Applied in cvs.

You're welcome.  However, I found a new bug in the Gnuplot 4.1 CVS
logarithmic contours code.  The following script doesn't work as
expected:

---- clip ----
unset surface
set contour
set log z
set palette model HSV functions gray, gray, 0.8-0.5*gray
set log cb
unset colorbox
set view map
set cntrparam level incremental 5,2,200
splot x**2+y**2+1.0 palette
---- clap ----

Nothing is plotted.  The problem is in the "cntrparam level incremental"
definition; Gnuplot recognizes the values as linear increments in
logarithmic axis, which leads in HUGE steps in the actual z-value.  The
steps go like (10^5, 10^7, 10^9, ... , 10^200), which is obviously very
wrong.

By replacing the "set cntrparam" command with

"set cntrparam level incremental 1,0.1,2"

one gets a nice plot with z range [10:100] (10^1 and 10^2) with ten
contours (1/0.1).  This works, but is very confusing for the end user.

One thing to note is that it's not generally quite clear what is meant
by "cntrparam level incremental" in logarithmic space.  I assume that
the user means constant increments in logarithmic space.  However,
because addition in logarithmic space means multiplication in linear
space, there will be a problem: What is the multiplicator (i.e. the
logarithmic addition)?  The incrementation parameter is not usable, as
it should mean an incrementation in linear space, not multiplication.  

I wrote a small patch based on the interpretation of constant increments
in logarithmic space.  In the patch, the incrementation in logarithmic
space is calculated so that the first incremental step (in linear space)
is exactly as large as the incrementation the user selected.  I chose
that implementation, because

a) it's intuitive
b) it's simple to program
c) it doesn't seem to break the existing, correct implementation for
linear z axis.

So, the new patch should give contours in z positions (5, 7, 9.8, 13.7,
19.2, ...) for "set cntrparam level incremental 5,2,200".  The idea is
that 5 + 2 = 7, so that the first two steps are the same as for the
linear case, and the next steps are calculated logarithmically based on
the first two.  I hope that is intuitive enough; at least it's lot
better than the current behaviour.  The main problem is that it doesn't
draw anything with negative values (which do not have real logarithms
anyway).  Well, at least it doesn't dump core either.  :-)

The very very small patch to implement this is attached, please try it
for the example above to see what I mean.  I've tried it with simple
linear and logarithmic scripts (like the sample above), but who knows?
It may break something; works for me, but YMMV.  :-)

Best Regards,
Aapo Lankinen

-- 
Aapo Lankinen <aap...@gm...>

Re: eps file

[V. <gae...@no...>]

On Mon, Jun 06, 2005 at 02:02:57PM +0200, Hartmut Ehmler wrote:
> For info, I copy here the first comment lines of my .eps file:
> %!PS-Adobe-2.0 EPSF-2.0
> %%Title: eps_example_file.eps
> %%Creator: gnuplot 4.0 patchlevel 0
> %%CreationDate: Mon Jun 06 14:01:44 2005
> %%DocumentFonts: (atend)
> %%BoundingBox: 50 50 301 226
> %%Orientation: Portrait
> %%EndComments

  You can always use the quick and dirty solutions : delete the line of
your eps file starting with :
%%BoundingBox:=20

--
  Ga=EBl

Re: label offset error on 4.1

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

KITA Toshihiro wrote:

> The problem happens when I set a label string and the offset at the same time.
> 
> gnuplot> set xla "x"
> gnuplot> set xla -10, -2
> 
> is OK, but, I get
> 
> gnuplot> set xla "x" -10, -2
>                         ^
>          invalid expression 

Please compare this command to the actual syntax description found under 
"help xlabel": you're missing the 'offset' keyword.

Re: eps file

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

Hartmut Ehmler wrote:
> When creating an .eps file with 'set terminal postscript eps'
> I get an output file, which is on A4, but contains only a very small plot.

How exactly did you establish the fact that this plot was "on A4"?  I 
ask because I'm quite sure that's not the case.  Look at the 
BoundingBox: it's considerably less than one A4 page's worth large.

label offset error on 4.1

[KITA T. <t-...@cc...>]

Hello,

# I am now using heavily gnuplot epslatex terminal for my
# dissertation. Thank you very much indeed.

It seems label offset setting does not work for some offset value on gnuplot
4.1 that I built today from CVS source.
The problem happens when I set a label string and the offset at the same time.

gnuplot> set xla "x"
gnuplot> set xla -10, -2

is OK, but, I get

gnuplot> set xla "x" -10, -2
                        ^
         invalid expression 

It's OK when the offset for x-direction is positive like
gnuplot> set xla "x" 10, -2


# I looked a bit into axis.c, parse.c and util.c, but I can't locate
# where the problem is.
-- 
  KITA Toshihiro
  http://t-kita.net/    PGP-Key: http://t-kita.net/pubkey.asc
  fingerprint : CBFF 6A61 5990 10F5 B4B6  D2E8 279A 7063 CF8B 6339

Patches to clean up string-handling corner cases

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

On Saturday 04 June 2005 10:06 am, J=C3=BCrgen Wieferink wrote:
> Today I've searched the code for other occurances of
> 'free(...string_val)' and replaced them by 'gpfree_string'.

Great. I put that one in cvs.

> The third patch keeps track of backslashes within double quoted strings.

I had forgotten about this issue.  I've put your fix into cvs
because it is better than the current state of affairs.=20
But I don't think this is the end of the story.  I see it as=20
applying a bandaid to the deeper problem of extending the=20
distinction between single-quoted strings and double-quoted
string constants to string variables.

Currently the check for single- or double- quotes is made at
the time a string constant is parsed, as in:
  A =3D "1\n2"
  B =3D '1\n2'
  if (A ne B) print "Strings are not equal"

But if you assign a value to a string variable via some more
complex path, including your new system() function, then there
is no check for whether embedded special characters should be
given the single-quote treatment (store raw input) or the
double-quote treatment (add \ in front of certain characters).

I don't have a specific example of when this would cause a
problem, but it makes me uneasy.  I think it might be better to
remove the single/double quote processing from the parser, and
instead *always* store a string in its "raw" form, and add a
separate flag to indicate whether it is to be expanded or not
when printed.

>The second problem I found is revealed by:
>  set macros
>  foo =3D "print foo"
>  @foo
>  print "@foo"
>  print "\"@foo\""
>  print "\"@foo"; @foo

I haven't looked at this one yet, but there's another unresolved
issue as well, pointed out by Petr Mikulik a while back.
As you can see from the sequence below, it does not
work to define and invoke a macro on the same input line:

gnuplot> set macros
gnuplot> foo =3D "1"; print @foo;  foo =3D "2"; print @foo
         warning: foo is not a string variable
         warning: foo is not a string variable

gnuplot> foo =3D "1"; print ;  foo =3D "2"; print=20
                          ^
         constant expression required

gnuplot> show var

        Variables:
        pi =3D 3.14159265358979
        foo =3D 1

gnuplot> foo =3D "2"; print @foo;  foo =3D "3"; print @foo
1
1


=2D-=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

eps file

[Hartmut E. <Har...@ip...>]

I use gnuplot for windows (wgnuplot.exe).
When creating an .eps file with 'set terminal postscript eps'
I get an output file, which is on A4, but contains only a very small =
plot.
This is especially annoying when importing this file as a graphics into
MS-word. Is there a solution for this?

For info, I copy here the first comment lines of my .eps file:
%!PS-Adobe-2.0 EPSF-2.0
%%Title: eps_example_file.eps
%%Creator: gnuplot 4.0 patchlevel 0
%%CreationDate: Mon Jun 06 14:01:44 2005
%%DocumentFonts: (atend)
%%BoundingBox: 50 50 301 226
%%Orientation: Portrait
%%EndComments

Regards, Hartmut

-------------------------------------------------------
Dr. Hartmut Ehmler
W7-X Basic Device/Magnets
Max Planck Institut f=FCr Plasmaphysik
Wendelsteinstra=DFe 1
17491 Greifswald (Germany)

phone: +49 (0)3834/88-2525
fax:   +49 (0)3834/88-2709
email: eh...@ip...
 =20

Re: gnuplot slow on BIG files

[Robert H. <en...@no...>]

On Sat, 4 Jun 2005, Dimitrios Apostolou wrote:

> This time I used the format you suggested:
> diff -ur  <oldfile> <newfile>

The annoying thing about this patch is that it fails to show how your
code compares to what was there before, because you didn't actually
remove the old version.

Rob

-- 
         \			Robert Hart
       ___\______		en...@no...
      /   ^    \_]======]	http://www.nott.ac.uk/~enxrah
 ____[##########\_____
/ ___________________ \		15 Benington Drive
\/{oOOOOOOOOOOOOOOOo}\/		Wollaton
  \o%%%%%%%%%%%%%%%o/		Nottingham
   ~~~~~~~~~~~~~~~~~		NG8 2TF


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.

Re: Fill boxes using pcl5 terminal

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

Xavier wrote:
> I read that the new version does not support this option, however I'd like to 
> know if someone knows a work arouund to this problem.

First off, I'm not sure I agree that absence of explicitly optional 
features from some of the drivers qualifies as a "problem".  It's a 
limitation, caused by nobody interested enough in having this feature 
also having the knowledge to actually implement it.

Re: [Fwd: Gnuplot: MAX_NUM_VAR in src/syscfg.h]

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

Ethan Merritt wrote:

>>Is it worth complexifying the code to save 1K bytes of memory?
> 
> 
> No. But that isn't the motivation.  The idea is to make
> parameter allocation dynamic, so that we don't have a hard-coded
> maximum number.  I was just pointing out that switching to 
> dynamic allocation would save space as a side benefit.

I almost always vote for dynamic allocation.  "lot's of memory" shouldn't be an 
excuse for inelegant programming.

Dan