On Mar 25, 2009, at 3:50 AM, Ken Smith wrote:
> The file format and the API I'm using to read it (FITS) supports
> IEEE 754, and, as far as I know, so does C++ and MySQL (with the
> exception of NaN values). I just (perhaps naively) want to take
> those numbers from the file and store them in the database without
> parsing them as strings.
Sure, the *capability* is there, but someone has to write the code to
make it happen.
If you can't wait for me to get to it on my schedule, well, it's an
open source project; we accept patches. Study the code, make a
proposal about where you think your feature fits in with the library,
and we'll be happy to help you refine your ideas into something that
will work within the context of the current MySQL++ design.
>> This really isn't a MySQL++ issue. It's an FP issue.
>
> I've tested the precision, and MySQL++ doesn't set it
> automatically. I had to force it using setprecision.
How are you building your query strings, exactly? Post a code
snippet, please. Or, better, post a short (< 50 LOC) program that can
build on any system using only MySQL++, which demonstrates the
problem. Give the details of the machine and compiler, in case those
are relevant.
As Jim said, all paths for building a query string with an FP value
should pass through one of the four SQLTypeAdapter ctors taking FP
values. There are several things that could be going wrong, but
without code to demonstrate a flaw, it's hard to see what it could be.
> However inaccurate the measurements, at least I could say with
> confidence that the process of data ingestion has not further
> altered the data.
Unless we find that MySQL++ is indeed truncating meaningful digits
from your data, I think you're worrying about altering noise in your
signals, producing different noise. This is meaningless.
Also, realize that modern CPUs have very mature FPUs. They're
designed with scientific applications in mind, and have features to
preserve as much useful precision as possible. Much of the worries
about FP precision these days are residual FUD from the 70s, when
machines either had weak FPUs or people had to roll their own FP
routines, often poorly.
I tried to write a program to force an FP error, but failed. Here's
my attempt:
#include <iostream>
#include <iomanip>
#include <sstream>
using namespace std;
int main()
{
// Convert a million degrees F to C, traditional way
double f = (1e6 - 32.0) * (5.0 / 9.0);
cout << setprecision(17) << f << endl;
// Do it again, but in a way less likely to lose precision
f = (1e6 - 32.0) * 5.0 / 9.0;
cout << setprecision(17) << f << endl;
// Convert f to a string, then back to double, and print it again
ostringstream outs;
outs << setprecision(17) << f;
std::stringstream buf;
buf.write(outs.str().data(), outs.str().length());
cout << setprecision(17) << f << endl;
return 0;
}
All three outputs are the same on a bunch of different systems here:
CPUs: x86, x86_64, PowerPC G5
OSes: OS X 10.5.6, CentOS 3, 4 and 5, OpenSolaris 2008.11, and
Windows XP SP3
Compilers: Visual C++ and many variants of g++
This code duplicates the way MySQL++ does its FP-to-string and string-
to-FP conversions.
