Re: A little trouble with very large arrays.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-10-04 23:38, Shark8 wrote:
> I'm trying to implement a FITS library for work -- see https://fits.gsfc.nasa.gov/standard40/fits_standard40aa.pdf -- and have come across some rather interesting problems implementing it.
> 
> The main-problem right now is the "Primary Data Array" which can have a dimensionality in 1..999, each itself with some non-zero range. (In the files these are specified by keywords in the file like NAXIS = n, NAXIS1 = n_1, NAXIS2 = n_2, and so on until the NAXISn = n_n keyword/value pair is encountered.)
> 
> Relatively straightforward, no? Well, I'd thought I could handle everything with a dimensionality-array and generic like:
> 
> 
>      Type Axis_Count is range 0..999 with Size => 10;
>      Type Axis_Dimensions is Array (Axis_Count range <>) of Positive
>        with Default_Component_Value => 1;
> ...
> Generic
> 	Type Element is (<>);
> 	Dim : Axis_Dimensions:= (1..999 => 1);
> Package FITS.Data with Pure is
> 
> 	Type Data_Array is not null access Array(
> 			1..Dim( 1),1..Dim( 2),1..Dim( 3),1..Dim( 4),
>    			1..Dim( 5),1..Dim( 6),1..Dim( 7),1..Dim( 8),
>    			--...
> 			1..Dim( 997),1..Dim( 998),1..Dim( 999)
> 		) of Element
>        with Convention => Fortran;
> End FITS.Data;
> 
> But no dice.
> GNAT won't even compile an array like this [999 indexes].
>
> What's the proper way to go about doing this?

A wrong way dealing with protocols is attempting to define an Ada type 
having the exact representation of the data as defined by the protocol. 
It is both useless and difficult to impossible, especially if bits are 
involved.

As a starting point consider representation clauses non-existent and 
simply provide operations to construct reasonably defined Ada objects 
from raw protocol data and conversely. Nobody would ever program 
anything using 999-D arrays. Nobody would ever instantiate n**1000 
instances.

You could use a flat array internally and provide operations for image 
serialization/deserialization in whatever format, e.g. by 
Get_Pixel/Set_Pixel.

The hardest problem would be controlling bit representations. If they 
really mean that. Modern hardware usually handles octets atomically and 
simply does not allow accessing individual bits. There is basically no 
way to tell the bit order programmatically or even define "order".

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de