FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
> Sent: February 5, 2003 3:19 PM
> 
> Yes, this would be very handy for implementing the missing dbmny*()
> arithmetic functions, among other things.  It's not clear to 
> me that there would be any performance benefit, though.

Nick, 

I'm either insightful or silly; someone stop me before I hurt myself again.


src/tds/numeric.c includes a nasty function: 

        char * tds_numeric_to_string(const TDS_NUMERIC * numeric, char *s)

TDS_NUMERIC is a structure with three members: precision, scale, and array.
"array" is an array of (up to 33) values, each value being between 0 and
255.  In effect, it's a string representation of the number, base 256, with
a side order of scale and precision, base 10.  

My thought is to use gmp's functions, starting with:

        int mpz_set_str (mpz_t rop, char *str, int base) 

where base can be 2 to 36.  Since our base is 256, it's simple to convert it
to a hex string, which we then hand to gmp.  That set the value of rop,
which can be converted to anything (big benefit there; otherwise we'd need
sprintf() to get to floating point) but what I have in mind is:

        char * mpz_get_str (char *str, int base, mpz_t op) 

that returns a decimal string, into which we insert a decimal point, at
"scale".  If that's not faster than tds_numeric_to_string(), I'll eat my
hat.  

I got on this road because of money, TDS_MONEY, that is.  For money, we
don't need gmp; we need Bill's tds_money_to_string() implementation to work
correctly on all architectures with 64-bit integer support.  IIRC, it
produced Just Wrong answers on little endian beasties, which is why we
reverted to Brian's code.  

+++

Freddy raised the question of priorities.  For 0.60, we were very happy to
have a full suite of working any-to-any conversions.  0.61 saw a lot of
nailing down, fixing up, and filling in the holes.  I think FreeTDS is
nearing -- probably is -- production quality BCP functionality, especially
with Bill's soon-to-arrive error file and my promised fleshing out of the
ct-lib (cs-lib, really) blk-* routines.  For BCP, conversion speed matters
more because it's otheriwise a low-overhead environment.  And it seems I
tripped on a real doosie.  

Slow is OK.  Order of magnitude slower precludes using FreeTDS for many BCP
applications, though, and that's something I think we should address.  If
gmp is overkill, we can make it an optional configuration, like iconv.  

I agree date conversions are awkward, but they're not so loopy as
TDS_NUMERIC processing.  Even though they're more lines of code, I think
they're probably not all that slow.  Just my intuition.  

That's how I see it.  This is the FreeTDS mailing list, where you feedback
is, as always, welcome.  

--jkl









The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.