Our solution for the large number problem and escape the floating point jungle was to implement a display format fixed point decimal arithmetic processor with an arbitrary precision. It has add, subtract, multiply and divide plus aggregate functions. A wrapper handles the interface and intercepts the DECIMAL declared type which uses the standard SQL definition for precision and scale.
The purpose of the format is that these numbers can be displayed unchanged into HTML pages, PostScript documents or general reports without editing or radix changes. They are not the best solution for arithmetically intensive applications but are very suitable for representing money and other commercial number usage where radix changes and editing tend to consume more resources than arithmetic. Using 64 bit integers with an associated precision and scale would probably be a better solution where you have a lot of arithmetic and less presentation. You are welcome to the code if it would work for you. Email me at johns <at> viacognis.com. BCD is a good way to go only if you need to save space with the packed decimal format and if you are using a machine with built-in BCD arithmetic instructions or have to interface with legacy COBOL applications. We also have some BCD routines from an old COBOL compatibility product if you are interested. John S Transportable Software Aladdin Lampé wrote: > Hi all! > In the application I'm developing, I'm dealing with monetary values that may > become *very* huge (but with few decimals), and I have the feeling that the > sqlite representation of "REAL" numbers with 8 bytes doubles may not be > enough in my case, and I may get overflows (which would obviously be > unacceptable in my case :-) ). > > Following the recent thread "BCD representation of float" ( > http://thread.gmane.org/gmane.comp.db.sqlite.general/36787/focus=36803 ), I > thought that maybe a custom implementation of BCD would be a possible > solution in my case. > > Maybe I could also implement my own floating point format, based for instance > on an int64 and a way to tell where the decimal point is. But in this case I > would need to reimplement addition, division, etc. to deal with the position > of the decimal point, and this may have a negative impact on performance and > a storage overhead. > > Do you think BCD is the way to go for me? Maybe somebody has already solved > this problem (John Stanton?) and could share a possible solution? > > Thank you for any insight. I'm very interested in pointers or source code > dealing about that... :-) > Aladdin > > > _________________________________________________________________ > Votre contact a choisi Hotmail, l'e-mail ultra sécurisé. Créez un compte > gratuitement ! > http://www.windowslive.fr/hotmail/default.asp > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
