How many pieces have to be in place to make a --with-Decimal64 option that works similarly to --with-long-double in configure? That is, what all does building with long-doubles affect, and what do they depend on?
A spreadsheet that used decimal floating point semantics would be quite a handy thing for anybody who has thought that it might be nice to add quantities of money, time, etc, in a spreadsheet. (Using binary floating point for this purpose must be considered a hack that goes back to Visicalc!) The basic infrastructure of gnumeric has already been parameterized to accomodate --with-long-double, so in principle, it should be possible to accomodate _Decimal64 as just another type using the same typedef and #define tricks. Intel has cooked up some fast routines for doing basic calculations with decimal numbers based on IEEE 754-2008 and added them to gcc upstream, so gcc supports the types and can do the basic math. They're already working on transcendentals (see John Harrison's paper, "Decimal Transcendentals via Binary"). Some platforms like HP-UX already have decimal support in their libc, but John Harrison's paper shows that in many cases, if you have 80 bit long doubles, you can just cast your _Decimal64 to long double and pass it to the existing long double libc function to get accurate results, at least for transcendentals. (This is suggested as a quick hack to get things working until C libraries are properly updated.) Doing conversions to and from _Decimal64 via C library long double functions would partly defeat the purpose of the exercise, but doing custom conversions between external representations and _Decimal64 is straightforward compared to the contortions required to convert to and from binary floating point, and in any case, doing custom conversions would be worthwhile because they could preserve trailing zeros. (Decimal floating point is not normalized like binary floating point is.) Bitfields from _Decimal64s could be manipulated as 64 bit long longs and converted to digit strings with existing C library integer functions for formatting. Somebody will ask, "What about _Decimal128?" Well, it would be nice, but _Decimal64 is a nice place to start, especially considering that performance better, transcendentals might get calculated with long doubles until C libraries are updated, and it is a bit tricker to manipulate bitfields from _Decimal128s since they can be longer than 64 bits, the longest integers in available in typical C environments. Getting Gnumeric to work with _Decimal64s would make a lot of things work "right" like accurate representations of decimals that have an internal idea of significance instead of relying on various rounding tricks to fit prefabricated formats. In addition to the representational accuracy issue, a spreadsheet using decimal arithmetic would reduce the required effort for formatting each number to round to a suitable number of decimal places since most numbers would already have an internal idea of what sort of external representation would be sensible. In some sense, it should have always been that way, but only recently have the tools to make it work practically been coming together. Jeffrey Streifling _______________________________________________ gnumeric-list mailing list gnumeric-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnumeric-list
