From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ead02e7101c0c023 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-01 11:34:10 PST Path: supernews.google.com!sn-xit-03!supernews.com!news-feed.riddles.org.uk!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!news1.frmt1.sfba.home.com.POSTED!not-for-mail From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: Problems with large records (GNAT) [continued] References: <3A9EC49C.9F5CD8D6@linuxchip.demon.co.uk> X-Newsreader: Tom's custom newsreader Message-ID: Date: Thu, 01 Mar 2001 19:32:05 GMT NNTP-Posting-Host: 24.20.190.201 X-Complaints-To: abuse@home.net X-Trace: news1.frmt1.sfba.home.com 983475125 24.20.190.201 (Thu, 01 Mar 2001 11:32:05 PST) NNTP-Posting-Date: Thu, 01 Mar 2001 11:32:05 PST Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: supernews.google.com comp.lang.ada:5362 Date: 2001-03-01T19:32:05+00:00 List-Id: >a lot of splits and dividends in their history have very >small prices back in the '70s. >... >With volume, I think that really needs to better than 32 bit range. >Once you start to calculate weekly or monthly volumes, quite a number >... >Fixed point for this wide ranging data doesn't give me the confidence >I want from a (mission critical) financial application. Of course we were in a "minimize storage" mode for speed and because customers downloaded the data over 14,400 baud modems. So internal computation could use large, or even floating point, variables, but stored data was as compact as possible. For instance, the original prices were stored in 16 bits scaled, but were converted, then multiplied by a "split factor", for computation. Similarly for aggregated volumes. Many customers did very trivial arithmetic, but would be unhappy over rounding errors, so float (especially for commodities with non power-of-two scale factors) was undesirable for the raw data.