Tom -
So are you really doing a sscanf(buf, "%f", &value) where value is a float,
rather than a
sscanf(buf, "%lf", &value) where value is a double? There is this just
fabulous inconsistency in c, whereby a printf using a "%f" is referencing a
double (64 bits) but a scanf referencing a "%f" is referencing a float (32
bits). I am a bit rusty on my c, but I believe this is a painful gotcha oft
encountered. Fixing this alone would help a great deal. However, one still
cannot exactly represent any given number in one base with an internal
representation in another base with a finite amount of storage. So there is
no magic past that point. But it actually looked to me from Carlos' numbers
that you only had 6-7 digits precision, and that limitation is consistent
with truncation to float in ptraj. Note that even if your target value is a
double, c would be rounding or truncating and dumping a 4 byte value in your
double. This is all highly testable conjecture, from someone who has been
sort of fortran-lobotomized for the last 5-6 years (so guys currently
actively doing c may feel free to straighten out anything I don't have quite
right).
Regards - Bob
----- Original Message -----
From: "Thomas Cheatham III" <tec3.utah.edu>
To: <amber-developers.scripps.edu>
Sent: Monday, February 05, 2007 5:37 PM
Subject: Re: amber-developers: ptraj precision
>
>> EXAMPLE
>> input trajectory file:
>> 18.438 29.157 33.019 18.614 28.133 32.690
>> output restart from ptraj:
>> 18.4379997 29.1569996 33.0190010 18.6140003 28.1329994 32.6899986
>
> As a follow-up to this, Scott or Ross or Bob do you know about IEEE
> conversions and all that hidden magic that likely causes this, i.e. is
> there a compiler option to prevent it?
>
> Basic code is sscanf(buffer, "%f", &value). Note that this could all be
> mute if I get off my butt and fix the character overflow problem (where
> numbers merge into others in trajectories and choke ptraj) with the atof()
> fix, as atof() may not do this magic conversion...
>
> Regardless, do any of you "C" guru's know about this precision adaption
> and conversion of a sensible xxx.123 value into xxx.12299997 value?
>
> --tom
>
>
>
>
Received on Wed Feb 07 2007 - 06:07:26 PST
