[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnuplot-info-beta
Subject:    Re: bug or missing feature?
From:       "Stefan A. Deutscher" <stefand () ferrari ! lcam ! u-psud ! fr>
Date:       1998-07-07 16:58:09
[Download RAW message or body]


> On Tue, Jul 07, 1998 at 03:20:36PM +0200, Hans-Bernhard Broeker wrote:
> > On Tue, 7 Jul 1998, Alexander Mai wrote:
> > 
> > > This data
> > >   9.34380D+00  1.12012D+01
> > >   1.53615D+01  7.68253D-04
> > > 
> > > is plotted as expected (?) using pl338. Using 347 I get
> > > the second point at (1.53615 7.68253) instead of (15.3615 7.68253).
>                                  ^^^^^^^                      ^^^^^^^^  
>                                   well, not 'exactly' there ... ;-)

> > This is due to the speedup patch for the datafile reading module.
> > Among some other changes, it now defaults to *not* supporting the
> > FORTRAN floating point syntax as above. You'll have to recompile
> > datafile.c with FORTRUN_NUMS defined to re-enable it. I'd suggest
> > turning this definition around (#ifndef NO_FORTRAN_NUMS, instead of
> > #ifdef FORTRAN_NUMS), so the default will be consistent with old
> > betas (and the docs?). If someone really needs all the datafile
> > reading speed possible, (s)he could compile with NO_FORTRAN_NUMS
> > #defined.

> I also prefer the default to be in agreement not only with the 
> older betas but also with my needs ;-)

I totally agree. I recall that processing of the Fortran goodies (D and
I think, even Q for double and quadruple precision) was put in after --
as usual -- massive whining from my account back in '95 or '96 or so,
which was when I first ran into this thing. It did slow down reading the
files, but it made gnuplot very usable to process Fortran output w/o
having to run it through some awk or sed script or what not (which gets
unpleasant and quickly evolves into a neat parsing job when you also
have comments in the data file). Given that most numerical data these
days is generated with Fortran programmes [1] I'd support the idea to
turn the defaults this way. Another option would be to make it .gnuplot
setable 'set acceptfortrannotationforrealnumbers' (all right, a name
a tad bit shorter would do) and then to invoke either the standard or
the enhanced line parser?

> BTW, if the module doesn't understand the numeric format shouldn't it
> complain? Ignoring unknown characters in a number as 'nothing' and
> keeping the 'valid' part without any message is not a good behaviour.

Agree, too.

> I'm used to get warned on 'corrupted' datafiles.

I never saw that -- it simply made very unexpected plots and I knew
something was wrong. Anyway, I know I owe a lot of gummy bears and
chocolates to all the folks out there who actually do the coding, but
the one who initially put in Fortran style number parsing deserves a big
bag of it (and so does the one who puts it back in for pl348 :->).

 Cheers!  Stefan


[1] Stefan A. Deutscher, totally unsupported bold-arsed guess during a
    private communication, Paris, 1998

--
=========================================================================
Stefan A. Deutscher                       | (+33-(0)1)   voice      fax
Laboratoire des Collisions Atomiques et   | LCAM :  6915-7699  6915-7671
Mol\'{e}culaires (LCAM), B\^{a}timent 351 | home :  5624-0992  5624-0992
Universit\'{e} de Paris-Sud               | email:  sad@utk.edu 
91405 Orsay Cedex, France (Europe)        |         (forwarded to France)
=========================================================================
 Do you know what they call a quarter-pounder with cheese in Paris?

[[[[ unsubscribe from info-gnuplot-beta via majordomo@dartmouth.edu ]]]]

[prev in list] [next in list] [prev in thread] [next in thread]