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

wxwidgets terminal

[L. <tim...@en...>]

Hi !

I am a pleased user of gnuplot. I often use it, standalone or through
Octave, to study physic datas.

In order to make it more user friendly (but it already is, with a little
practice), I thought to write a terminal to wxwidgets 
(hhtp://www.wxwidgets.org), a gui toolkit. It would have the advantage of 
being cross-platform. Moreover, I think it would be really easy to copy
all the features of current x11 or windows terminals, and then to add
toolbars and other useful buttons ou dialogs. In particular, it would 
be something interesting to make 3rd-party software (like Octave,
or Maxima) reach a higher level of usablility.

I have looked for such projects, but found none. There's a
couple of projects which aim at buildung a complete gui for
gnuplot, but they appear dead. And none of them was using a
new terminal, as far as I guess.

I am not afraid at all by such a project, and I have began to
learn how to use wxwidgets. But I have a question : wxwidgets
is a library for C++, and gnuplot is written in C. So, can
I write a terminal for gnuplot in C++ ?

Can gnuplot be compiled entirely with a C++ compiler (g++ in my
case) ? Does somebody know a way to do it (I've not tried) ?

Do you think the whole idea of writing a wxwidgets terminal is good ?

I would be pleased to get your opinions.

Timothée Lecomte
French student, at the ENS, Paris (http://www.ens.fr) 

Re: gnuplot slow on BIG files

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

Daniel J Sebald wrote:
> Hans-Bernhard Br=F6ker wrote:
>> Robert Hart wrote:

>>> sscanf takes an arbitrary format string as an argument, which it must=

>>> parse every time it is called, it is also very generic so, I imagine,=

>>> ends up doing a lot of extra work to support this.=20

>> None of that extra work can possibly be "a lot", compared to the heavy=
=20
>> task of actually doing a floating-point conversion. =20

[... Dan found a quote from myself...:]

> BTW: if I change the call from sscanf() to strtod(), the run time=20
> becomes O(n) in all platforms I cared to test.=20

Well, the processing that caused that example to be O(N^2) wasn't=20
related to the format string at all --- it was triggered by handling of=20
input string.  So my answer to Robert quoted above still holds.

Apparently the culprit implementations in that case (glibc, DJGPP,=20
possibly others) run strlen() on the input string as part of the job of=20
constructing a memory-based pseudo-file, so they can essentially=20
implement sscanf() on top of fscanf().  That's really quite a stupid way =

of doing this.

But yes, indeed, a QoI issue like this could explain the speed=20
difference we're seeing here.  The enormous length of the OP's matrix=20
datafile's lines would trigger this copying overhead on platforms=20
working that way.  The crucial difference in that case turned out the=20
length of the "tail" after the scanned number, e.g.

   sscanf("3.14 ", "%lf", &mydouble);

would complete much faster than

   sscanf("3.14 [10000 other characters here...]", "%lf", &mydouble);

> Now, here's the interesting part.  :)  The date of this contribution is=
=20
> May 22, 2002.  And the contributor of this was... Hans-Bernhard Broeker=
=20
> :)

Let's just say I know full well why I never claim to have perfect memory =
;-)

Re: gnuplot slow on BIG files

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

On Sat, 11 Jun 2005, Hans-Bernhard Broeker wrote:

> We have two library functions doing essentially the same thing, both 
> specified precisely enough by C Standards for 15 years now.  We know of 
> one OS that got one of them wrong, at one point in time at least.  How 
> do we know there isn't also a platform that gets the other one just as 
> wrong? The answer is, we don't.

You seem to be implying that we shouldn't be making any kinds of changes
to the core of gnuplot without being sure they will work on all of the
platforms that gnuplot has *historically* supported.

The fact is:

a) we've checked this on all the platforms we have access to.

b) we've attempted to contact people knowledgable in the known
"problem" platform.

c) anybody who later has difficulties compiling/running the new version,
will have access to comments in the source explaining the situation,
archives of the mailing list, and the CVS history of gnuplot itself.

So, I think unless somebody can show that either:

a) A significant number of people are running gnuplot on platforms we
aren't ourselves using,

or

b) strtod has known bugs in *current* implementations.

there's not a lot more we can do.

FYI: Known strtod bugs, I can find:

http://www.blackdown.org/cgi-bin/jdk/known-bugs?id=1001;page=4;user=guest

Bug in glibc 2.0.7: returned "0.0" on an input of "-0.0". I doubt this
would cause an issue for gnuplot anyway. Fixed in more recent versions.

http://savannah.nongnu.org/bugs/?func=detailitem&item_id=2924

bug in avr-libc: endptr is not set correctly. Fixed in current versions,
obscure platform anyway. Not sure gnuplot would be appropriate for it.

http://www.hmug.org/man/3/strtod.php

On mac OSX, "NaN" is not recognised.

http://www.opensource.apple.com/darwinsource/10.3.1/tcl-14/tcl/unix/tcl.m4

Under Solaris 2.4, strtod returns the wrong value for the
terminating character under some conditions.  Check for this
and if the problem exists use a substitute procedure
"fixstrtod" (provided by Tcl) that corrects the error.
Also, on Compaq's Tru64 Unix 5.0,
strtod(" ") returns 0.0 instead of a failure to convert.

int main() {
    char *infString="Inf", *nanString="NaN", *spaceString=" ";
    char *term;
    double value;
    value = strtod(infString, &term);
    if ((term != infString) && (term[-1] == 0)) {
	exit(1);
    }
    value = strtod(nanString, &term);A
    if ((term != nanString) && (term[-1] == 0)) {
	exit(1);
    }
    value = strtod(spaceString, &term);
    if (term == (spaceString+1)) {
	exit(1);
    }
    exit(0);
}

Re: License

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

Robert Hart wrote:
> I was just trying to brush up on the license of gnuplot. I only recently
> realised it isn't GPL. I've done a bit of googling, so I'm aware that
> the original authors are MIA, 

Only one is MIA.  The other is just off to other business, but could be 
reached if necessary.  That's how we got the license (slightly) changed 
from 3.5 to 3.7, and versions 3.7.* to 4.0 blessed "official".

Re: gnuplot slow on BIG files

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

Ethan Merritt wrote:
> On Thursday 09 June 2005 07:34 pm, Hans-Bernhard Br=F6ker wrote:
>=20
>>>strtod() is more portable than %n,
>>
>>Unless we have somebody verify to us that strtod() implements the same
>>ANSI standard more correctly than sscanf(), on OS-9, we don't know that=
=2E
>=20
>=20
> ?? The point is that using strtod we don't *need* %n.
> Where does "more correctly" come into it?

We have two library functions doing essentially the same thing, both=20
specified precisely enough by C Standards for 15 years now.  We know of=20
one OS that got one of them wrong, at one point in time at least.  How=20
do we know there isn't also a platform that gets the other one just as=20
wrong? The answer is, we don't.

> Not that it's a big deal, since the code currently has no provision
> for reported over- or under- flow.

It has (weak) provision for inf and NaN, though, elsewhere.

Re: [ gnuplot-Bugs-1217701 ] Locale settings not initialized properly

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

>=20
> >Comment By: Petr Mikulik (mikulik)
> Date: 2005-06-10 09:24
>=20
> I hope gnuplot's reading will not depend on environmental
> variables as it would immediately became non-portable.

I think you have this backwards.  The LOCALE mechanism is our
best and probably only path toward true portability.
=20
> I would rather prefer
>         set decimalsign input ","

We can discuss the choice of gnuplot commands at leisure,
but the fact is that the only way to take action on such a
request is via the LOCALE mechanism, and for better or for
worse that affects both input (scanf, atof, strtod, ...) and
output (printf, ...) in parallel.

This is the code I have been testing:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
/* process 'set decimalsign' command */
static void
set_decimalsign()
{
    c_token++;

    if (END_OF_COMMAND) {
        if (decimalsign !=3D NULL)
            free(decimalsign);
        decimalsign=3DNULL;
#ifdef HAVE_LOCALE_H
    } else if (equals(c_token,"locale")) {
        c_token++;
        setlocale(LC_NUMERIC,"");
        fprintf(stderr,"decimal_sign in locale is %s\n", (localeconv()->dec=
imal_point));
        decimalsign =3D gp_strdup(localeconv()->decimal_point);
#endif
    } else if (!(decimalsign =3D try_to_get_string()))
        int_error(c_token, "expecting string");
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

So to read an input file with numeric formatting in the convention
of your local environment, you would say
	set decimal locale
	plot "foo" ...

So far as I know, it is not possible to hard-code the LOCALE choice
entirely internal to gnuplot, because gnuplot has no control over
what locales are installed or supported on the machine it runs on.
We are guaranteed that the "C" locale is available, which uses=20
'.' as a decimal sign, but I have been unable to find any guaranteed
locale that would use ',' instead.

=46rom the command line on linux you can say
	setenv LC_NUMERIC ,
and `locale -c -k` claims that the decimal sign is now "," but upon
testing I find that it does not in fact have any effect on formatting
and anyhow the equivalent request from inside a program via setlocale()
is not accepted at all.

(I'll be out of town for several days, so I won't see any replies for
 a while)

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

Re: License

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

Robert Hart writes:
> Hi,
> 
> I was just trying to brush up on the license of gnuplot. I only recently
> realised it isn't GPL. I've done a bit of googling, so I'm aware that
> the original authors are MIA, and therefore the license is unlikely to
> change - (I big shame in my opinion). I guess my question is: Without
> the original authors, how are we able to distribute new versions of
> (i.e. changes to) gnuplot?
 
 I am the point of contact for Thomas Williams. It is Colin Kelley who is MIA.
 There were never any problems getting permissions for the release, and
 Tomas has been very impressed with the new features in 4.0.

License

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

Hi,

I was just trying to brush up on the license of gnuplot. I only recently
realised it isn't GPL. I've done a bit of googling, so I'm aware that
the original authors are MIA, and therefore the license is unlikely to
change - (I big shame in my opinion). I guess my question is: Without
the original authors, how are we able to distribute new versions of
(i.e. changes to) gnuplot?

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


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: [OT] octave to gnuplot

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

  Yes, that was the obvious simple answer.

  so here is what I did :

echo "tee -a logfile | gnuplot" > gp.sh
chmod u+x gp.sh
octave
> gnuplot_binary=3D"./gp.sh"
> plot((sin(0:0.1:1))
> hold on
> plot(cos(0:0.1:1))
> exit

and here are the contents of ./logfile :

set data style lines
set nologscale
set nopolar
pl '/tmp/oct-KvIS79' u 1:2 t "line 1"
set nologscale
set nopolar
rep '/tmp/oct-882efm' u 1:2 t "line 2"

  So if I am not wrong the replot command is indeed used by octave.

--
  Ga=EBl

[OT] octave to gnuplot

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

On Fri, 2005-06-10 at 11:58 +0200, Petr Mikulik wrote:
> > Couldn't you replace gnuplot with a wrapper script that does something
> > like:
> >
> > tee -a logfile | gnuplot.real
> 
> Try:
> gnuplot_binary = '/usr/bin/tee a.log | /usr/local/bin/gnuplot';

try:

echo "tee -a logfile | gnuplot" > gp.sh
chmod u+x gp.sh
octave
> gnuplot_binary="./gp.sh"
> plot(1)
> exit
cat logfile

-- 
Robert Hart <en...@no...>
University of Nottingham


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: gnuplot slow on BIG files

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

> Couldn't you replace gnuplot with a wrapper script that does something
> like:
>
> tee -a logfile | gnuplot.real

Try:
gnuplot_binary = '/usr/bin/tee a.log | /usr/local/bin/gnuplot';

... but then octave fails to write to it, why?

---
PM

Re: gnuplot slow on BIG files

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

>    By the way,	do you have an idea on how to monitor the commands sent
> by ovtave or maxima to gnuplot ?

On MSW, wgnuplot.exe shows them it, if you de-iconify it.

Otherwise, it needs some "pipe monitor" to be put between octave and
gnuplot.

---
PM

Re: gnuplot slow on BIG files

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

On Fri, 2005-06-10 at 11:28 +0200, Ga=EBl Varoquaux wrote:

>    By the way,	do you have an idea on how to monitor the commands sent
> by ovtave or maxima to gnuplot ?

Couldn't you replace gnuplot with a wrapper script that does something
like:

tee -a logfile | gnuplot.real

?
--=20
Robert Hart <en...@no...>
University of Nottingham


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: gnuplot slow on BIG files

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

On Fri, Jun 10, 2005 at 02:11:25AM +0300, Dimitrios Apostolou wrote:
> Ethan Merritt wrote:
> >Instead we should modify the replot command so that it re-uses
> >the data previously read in if at all possible.

> I believe this would be a nice fix. Since replot is mostly used in=20
> interactive mode, this should not break many scripts. And perhaps a=20
> "reread" command would be nice for rereading the input file.

   Isn't it used by octave ?

   By the way,	do you have an idea on how to monitor the commands sent
by ovtave or maxima to gnuplot ?

--
  Ga=EBl

Re: gnuplot slow on BIG files

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

> Moreover, gnuplot is really memory inefficient IMHO. To read 36M numbers
> for example it needs:
>
> (36M * sizeof(float)) + (36M * 3 * sizeof(float))

I have started a similar discussion some time ago, when I've concluded that
gnuplot needs 132 B per each point in 3D (data read + drawing cache in
terminal for X11 or Windows) ... it was for "set pm3d; splot ...".

Having maps organized in a different fashion would be definitely nice, but
too much code relies on the current model.

---
PM

Re: gnuplot slow on BIG files

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

> > Instead we should modify the replot command so that it re-uses
> > the data previously read in if at all possible.

This is the case of splot's and mouse rotations.

> I believe this would be a nice fix. Since replot is mostly used in
> interactive mode, this should not break many scripts. And perhaps a
> "reread" command would be nice for rereading the input file.

We would need "replot" and "Replot" -- the new one would replot without
rereading the file. The current behaviour of "replot" should not be changed.

---
PM

Re: gnuplot slow on BIG files

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

Hans-Bernhard Br=F6ker wrote:
> Robert Hart wrote:
>=20
>> On Thu, 2005-06-09 at 21:18 +0800, Hans-Bernhard Br=F6ker wrote:
>>
>>> Robert Hart wrote:
>=20
>=20
>>>> strtod() is indeed significantly faster than sscanf.=20
>=20
>=20
>>> And I still don't see why that should be the case...
>=20
>=20
>> sscanf takes an arbitrary format string as an argument, which it must
>> parse every time it is called, it is also very generic so, I imagine,
>> ends up doing a lot of extra work to support this.=20
>=20
>=20
> None of that extra work can possibly be "a lot", compared to the heavy=20
> task of actually doing a floating-point conversion.  I've inspected lib=
c=20
> source sufficiently to be reasonably sure of that.  There's no way the=20
> format string parser in sscanf() can take 10 times as much time as the=20
> actual floating point parsing (which may very well be done by calling=20
> strtod(), internally).


I think I've found a discussion that parallels what has been here:

http://dbforums.com/t327787.html

See if you agree.  For example:


"So this is a quality-of-implementation issue, at most, and it's not rest=
ricted to
glibc. I've just found O(n^2) on another platform with a different libc, =
too.

BTW: if I change the call from sscanf() to strtod(), the run time becomes=
 O(n)=20
in all
platforms I cared to test. I.e. the difference must happen in sscanf() it=
self,=20
and be
caused by the length of the remainder of the input string following the m=
atched=20
3.14."

Now, here's the interesting part.  :)  The date of this contribution is M=
ay 22,=20
2002.  And the contributor of this was...

Hans-Bernhard Broeker (br...@ph...)

:)

Re: gnuplot slow on BIG files

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

On Thursday 09 June 2005 07:34 pm, Hans-Bernhard Br=F6ker wrote:
> > strtod() is more portable than %n,
>
> Unless we have somebody verify to us that strtod() implements the same
> ANSI standard more correctly than sscanf(), on OS-9, we don't know that.

?? The point is that using strtod we don't *need* %n.
Where does "more correctly" come into it?

>  > and allows more complete
> > error reporting than sscanf().
>
> No, it doesn't.  It tells us nothing that sscanf()'s return value,
> combined with the output of %n, wouldn't.

strtod sets errno;  scanf does not.
Not that it's a big deal, since the code currently has no provision
for reported over- or under- flow.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

Re: gnuplot slow on BIG files

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

On Thursday 09 June 2005 04:11 pm, Dimitrios Apostolou wrote:
> I agree with you and don't like overcommit mode myself. How do you turn
> it off?

 The overcommit policy is set via the sysctl `vm.overcommit_memory'.
 The overcommit percentage is set via `vm.overcommit_ratio'.

=46rom the command line:
 echo "0" >/proc/sys/vm/overcommit_memory    # turn overcommit off

The /proc/sys/vm  mechanism is fairly recent. I don't remember
exactly which kernel version it first appeared in.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

Re: gnuplot slow on BIG files

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

On Thursday 09 June 2005 07:44 pm, Hans-Bernhard Br=F6ker wrote:
>
> It's actually called OS-9, a realtime OS for 68000 processors IIRC.
> > but if strtod works where sscanf doesn't then that's a win.
>
> IF.  But we don't know that.

A bit of poking around on the web leads me to the conclusion that
there is no single libc for OS9/OSK.  There are many, including
(since 1994) gcc and glibc.  Trying to figure out which of these
long ago libc variants was having a problem with %n is probably
a lost cause.  To the extent we can assume anything, I think we can
assume that a glibc implemtation provides strtod and follows the
ANSI requirement that strtod and scanf use the same format rules.

This is beating a dead horse, though.  The whole point of OSK is
that it runs in minimal RAM on embedded systems on old hardware.
I don't believe for a minute that anyone is going to install a
full-blown gnuplot version 4.2 on one of these old devices.

I suggest that we concentrate on the more relevant point of whether a
2X or 5X or 10X or whatever speed-up is worth the slight uncertainty
of replacing the current scanf() call with strtod().  ANSI says they
behave the same on formatting, and benchmarking shows that strtod()
is faster.  Sounds like a win to me. =20

The strongest counter-argument I see is that if you really want to
read in these huge matrices, you're better off using the binary
input mode anyhow.  Or if binary mode is not faster, then we should be
fixing that first.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington 98195-7742

Re: gnuplot slow on BIG files

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

Robert Hart wrote:

> My measurements using gnuplot on a 2000x2000 array, do seem to be closer
> to the 10x. I'm assuming the simple test case is much more efficient in
> cache usage, and so see less of an improvement.

There's no way cache effects can explain a change of speed difference 
between two library functions executed in a tight loop.

Re: gnuplot slow on BIG files

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

Robert Hart wrote:
> On Thu, 2005-06-09 at 21:18 +0800, Hans-Bernhard Bröker wrote:
>>Robert Hart wrote:

>>>strtod() is indeed significantly faster than sscanf. 

>>And I still don't see why that should be the case...

> sscanf takes an arbitrary format string as an argument, which it must
> parse every time it is called, it is also very generic so, I imagine,
> ends up doing a lot of extra work to support this. 

None of that extra work can possibly be "a lot", compared to the heavy 
task of actually doing a floating-point conversion.  I've inspected libc 
source sufficiently to be reasonably sure of that.  There's no way the 
format string parser in sscanf() can take 10 times as much time as the 
actual floating point parsing (which may very well be done by calling 
strtod(), internally).

>>  /* cannot trust strtod - eg strtod("-",&p) */

> I've seen this comment, and tried it out. In my tests this isn't an
> issue. The man page says:
> 
>        If  no  conversion is performed, zero is returned and the value of nptr
>        is stored in the location referenced by endptr.

That's the manpage of one system.  "To trust" means we must be sure that 
all implementations on the planet get this right.  Are we?

> I have attached my test program. I can't find any input on my system
> that gives different results between sscanf and strtod.

"On my system" being the key phrase here, which means that the test is 
inconclusive.

> Well comments in the code say "%n" doesn't work on OSK.  I don't even
> know what OSK is, 

It's actually called OS-9, a realtime OS for 68000 processors IIRC.

> but if strtod works where sscanf doesn't then that's a win.

IF.  But we don't know that.

Re: gnuplot slow on BIG files

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

Ethan Merritt wrote:

> It turns out that different ANSI revisions describe
> the behavior of %n differently, so it is not portable.  

Even the (Linux) libc man page isn't sure of itself in this regars. 
They only say the TC "seems to say otherwise".  I think they're 
misguided.  The description of %n in C90 is very easy to misinterpret. 
I'm reasonably sure the update they mention was only meant to clarify, 
not change the standardized behaviour.  The tricky bit is that %n is not 
a "conversion", so it's not supposed to affect the return value.

 > Here is an
> excerpt from the current man page:
>   "Probably  it  is  wise not  to  make any assumptions on the
>    effect of %n conversions on the return value."

That comment doesn't necessarily concern the case of gnuplot.  We don't 
have to know whether our sscanf("%lf%n",...) returned 1 or 2, which is 
all this is talking about.  We only need to know if it's zero (because 
the %lf failed), EOF (empty input, shouldn't happen) or anything else 
(so the %lf succeeded).

> The current code assumes that 
> 	count = sscanf(s, "%lf%n", ...)
> will set count to 1 if successful, but on some systems it will instead
> set count to 2.  I do not know if this is the specific problem with OSK.

No. I dimly recall the problem with OS-9 (which #defines OSK) was that 
%n simply didn't work at all.  I.e. it didn't put anything into the 
'used' variable.

> strtod() is more portable than %n, 

Unless we have somebody verify to us that strtod() implements the same 
ANSI standard more correctly than sscanf(), on OS-9, we don't know that.

 > and allows more complete
> error reporting than sscanf().

No, it doesn't.  It tells us nothing that sscanf()'s return value, 
combined with the output of %n, wouldn't.

Re: gnuplot slow on BIG files

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

On Thu, 9 Jun 2005, Ethan Merritt wrote:

> Not the factor of 10X that Dimitrios Apostolou was hoping for,
> but up to a factor of 5X depending on the platform.

My measurements using gnuplot on a 2000x2000 array, do seem to be closer
to the 10x. I'm assuming the simple test case is much more efficient in
cache usage, and so see less of an improvement.

Rob

Re: gnuplot slow on BIG files

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

On Thu, 9 Jun 2005, Ethan Merritt wrote:

> Somewhat more complete patch attached, adding a TBOOLEAN to 
> toggle fortran_float handling.

You didn't change the sscanf for the rereading after changing dDqQ. It
would be better to be consistent. There might even be somebody trying
to read a huge matrix of fortran floats into gnuplot.