From: Ann W. Harrison
Date: February 18 2009 7:16pm
Subject: Re: Patch for bug#42208
List-Archive: http://lists.mysql.com/falcon/553
Message-Id: <499C5E87.7070302@mysql.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
Content-Transfer-Encoding: 7BIT

Vladislav Vaintroub wrote:
> 
> And while we're on it why not to fix integer representation;) Doubles are
> strange creation by mathematician, exact longlongs would be really nice,
> not?
> 

Not, I think.  Yes, we could have a separate index representation
for numbers declared as integer, but I don't think that buys us
much.  Double precision float is precise to 15 digits, so only
numbers in the upper range of int64 lose precision when converted.
The conversion guarantees that if x > y when represented as
int64, x >= y when represented as double.  That's good enough
for our indexes - we have to look at the value anyway.

But just being good enough and giving a single representation
for numbers isn't the best argument for using double precision
as opposed to int64 keys.  Nor is the fact that I happen to
know how to mangle a double to byte comparable form, and don't
have an algorithm at hand to do the same for int64.  No doubt
there is one.

Double precision allows us to make on-line changes to the
length, scale, and type of numbers without rebuilding indexes.
Falcon represents decimal/numeric values as binary with a
decimal scale factor - meaning that the value is multiplied
by 10^<scale> before being stored and divided by 10^<scale>
for comparisons with values with different scales.

If someone decides after storing lots of GPS data in meters
that the actual precision is centimeters, Falcon would allow
the field to change from int64 to decimal [20,2] on line
instantly.

I think that's good.

Cheers,

Ann