Re: A little trouble with very large arrays.

[Shark8 <onewingedshark@gmail.com>]

On Friday, October 5, 2018 at 12:36:47 AM UTC-6, Dmitry A. Kazakov wrote:
> On 2018-10-04 23:38, Shark8 wrote:
> > 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.

Protocol?
FITS is a file-format. The only reason bits are involved at all in the spec is because it was developed back when some machines had 9-bit bytes. It's all defined based on 2880 byte blocks at the very lowest level; atop that there are headers (key-value pairs) and data-arrays/-structure (indicated by data within the header).

> 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.

I still need a way to conform to the standard, that means if the standard says that it's possible to have a 999-dimension array, I need to have some way to represent this... even if it is never in actuality used.

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

I tried this, it doesn't quite work though. (Stack overflow, oddly enough.)
    Function Flatten( Item : Axis_Dimensions ) return Natural is
      (case Item'Length is
	   when 0 => 1,
	   when 1 => Item( Item'First ),
	   when 2 => Item( Item'First ) * Item( Item'Last ),
	   when others =>
	     Flatten( Item(Item'First..Item'Last/2) ) *
	     Flatten( Item(Axis_Count'Succ(Item'Last/2)..Item'Last) )
      );


> 
> 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