From: Warren Young
Date: March 25 2009 7:14pm
Subject: Re: inserts, strings and setprecision
List-Archive: http://lists.mysql.com/plusplus/8510
Message-Id: <A3BDC403-0804-4256-8B7A-24A82B8814B2@etr-usa.com>
MIME-Version: 1.0 (Apple Message framework v930.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

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.