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

[Laurent Guerby <guerby@acm.org>]

Dr Adrian Wrigley <amtw@linuxchip.demon.co.uk> writes:
> Since you ask, I have something like the following...
> ------------------------------------
>    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;
> 
>    type StockIndex_T is new Integer range 1 .. 3000;
>    type TradingDay_T is new Integer range 0 .. 1860;
> 
>    type DailyArray_T is array (TradingDay_T, StockIndex_T) of PriceSummary_T;
> 
>    type BooleanDailyArray_T is array (TradingDay_T, StockIndex_T) of Boolean;
>    pragma Pack (BooleanDailyArray_T);
> 
>    type Oracle_T is record
> -- Various other record values may go here!
>       Tradeable    : BooleanDailyArray_T;
>       Daily        : DailyArray_T;
>    end record;
> ------------------------------------

Nice to see we're not alone using Ada for critical applications in the
financial world ;-). (Note that we have a support contract from Ada
Core Technologies, if you have one you can probably discuss the record
size limitation with them.)

Anyway, here I would probably want a few things:

- control the layout of the data to match computational access, if you
process your serie along time or stock.

- lazy loading (ie not mmap'ing the whole thing at once).

To do so, I wouldn't put all the things in the record, I would use
access types hidden behind proper abstraction. 

type PriceSummary_TV is array (Positive) of aliased PriceSummary_T;
type PriceSummary_TVA is access all PriceSummary_TV;

type Oracle_T is record
   N1 : Natural := 0;
   P1 : PriceSummary_TVA;
end record;

You mmap your stock history and store the pointer to it in your
Oracle_T (unchecked_convertion from the address returned by mmap to
PriceSummary_TVA). You need to use array of P1/N1 to implement
everything.  The "aliased" allow you to access any record by access
instead of copy when you're hiding things. N1 is needed to do manual
checking in your abstraction.

Note that if you compute historical volatilities or correlations, you
will probably be memory-bound performance wise (algorithm complexity
proportional to data size, with a small enough computation factor so
that memory access becomes dominant).

-- 
Laurent Guerby <guerby@acm.org>