Re: Problems with large records (GNAT) [continued]

[tmoran@acm.org]

>  type PriceSummary_T is record
>     OpenPrice   : Float;
>     HighPrice   : Float;
>     LowPrice    : Float;
>     ClosePrice  : Float; -- Split and dividend corrected price
>     UncorrectedClose : Float; -- Raw share price
>     Volume      : Integer;
>     Time        : Time_T;
>  end record;
  I realize you are interested in the generic large-memory-with-Gnat
problem, but, as they say, sometimes it's better to improve the
algorithm than the hardware.  I worked on a commercial system
(Technical Tools Co.) with stock (and commodity) historical data of
this type, using DPMI DOS and Windows 3.1 (and Ada 9X).  For
historical data, stock prices can be 16 bit fixed point with delta of
1/8, rather than 32 bit floats (excluding Berkshire-Hathaway).  Even
with prices in pennys nowadays, 24 bits should be quite enough for a
stock price.  Similarly, a 24 bit Volume (16 million shares of one
stock traded in one day) should be normally be adequate, perhaps with
an exception list for anything that doesn't fit.  A sixteen bit fixed
point value, with suitable delta, should be fine for holding the
split correction, or 24 bits if you really want to allow for even the
most bizarre changes.  I don't know what kind of processing you are
doing, but usually one processes a small number of complete time
series, or the complete market for just a few days, so only a few
rows or columns of the complete matrix need be in RAM at any one time.