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);
}