From: Warren Young
Date: March 24 2009 6:04pm
Subject: Re: FW: inserts, strings and setprecision
List-Archive: http://lists.mysql.com/plusplus/8507
Message-Id: <49C920B7.4060207@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ken Smith wrote:
> the mechanism that MySQL++ uses to build queries
> effectively converts all the variables to strings.

Yes, as does virtually every other SQL-based system.  Elevating the 
abstraction layer from platform-specific binary data to plain old text 
is one of the reasons SQL has taken over the world.  There have been 
efforts to define cross-platform binary data formats (XDR and ASN.1 come 
to mind) but they remain relatively obscure.

> I'm at the mercy of
> setprecision if I want to preserve the original number.

Well, yes, but MySQL++ sets the precision to the largest value that 
preserves all the digits.  With a 64-bit float ("double"), that's 17 
digits.  If you're really running into roundoff or precision issues by 
losing something down in the 17th digit, you either shouldn't be using 
floating point in the first place, or you're using the wrong scale for 
your numbers.

This really isn't a MySQL++ issue.  It's an FP issue.

> It's critical
> for my work that the original data is not massaged in any way.

When you use FP, you lose precision at the lowest digits all the time.

The question is whether it actually matters.  You can say you need 
absolute fidelity, but you also say you're dealing with scientific data; 
I'd bet your data source doesn't actually give you 17 reliable digits of 
precision.  A I've heard of some experiments having precision down in 
the part-per-trillion range, 5 orders of magnitude bigger than the loss 
of data at the last digit in a 64-bit float.

If I'm wrong, please, I'd love to hear what instrument you're using that 
gives you 17 accurate digits in its measurements.  Sounds awesome.

> Is there a MySQL++ equivalent that facilitates movement of C++ types
> into MySQL types without running it through ostream manipulators?

SSQLS may gain this facility someday, but not until after SSQLSv2 is 
released, as part of MySQL++ 3.1.  The main reason to do it would be 
speed, rather than preservation of precision, and even that's of 
debatable value.