Re: RFC on floating point output work

[Jerry Quinn <jlquinn at optonline dot net>]

I've done some more work on the floatconv library.  I addressed the
issues that Richard pointed out and cleaned up the Bigint class some
more.

I've also done somewhat fairer timing comparisons to see where things
stand.

For relatively small numbers, for example < 1e14, the dtoa conversion
here is MUCH faster than sprintf.  When dtoa uses the multiple
precision code, it is significantly slower than sprintf.

The optimal performance I currently get is by using dtoa's
optimizations, but switching back to sprintf for anything else.

I've done two timing tests.  These were done on an Athlon xp2200.  The
first generates 500,000 random doubles and prints them to a buffer:

sprintf:	34.27s
dtoa:		57.91s
hybrid:		31.17s

The second prints numbers from 1 to 500,000 to a buffer:

sprintf:	6.90s
dtoa:		1.76s

It seems like there's not a lot of value in bringing in the dtoa
multiple precision code, since it slows things down.  One thing we do
get from the dtoa code is a prediction of how large a buffer we need,
which is useful.

I was hoping the results would point to completely removing sprintf
code, but that doesn't seem to be the case.  However, the native
double optimization is worth bringing in and we can get rid of the
snprintf code, since dtoa will tell us how big a buffer is required.

The current version of floatconv.cc is at
http://bakerquinn.homelinux.net:8081/floatconv.cc


As before, comments are appreciated.

Thanks,
Jerry Quinn