Re: A little trouble with very large arrays.

[Shark8 <onewingedshark@gmail.com>]

> > No, the smallest sensible number of indices is 1, for everything except
> > maybe the first two or three dimensions: eg Image data from a camera, or
> > perhaps topological data from a map (longitude, latitude, elevation).
> 
> FITS images can have more dimensions than that. Further dimensions might 
> be the frequency of the light (spectral imaging); polarisation; time 
> when image was taken; and perhaps a couple more that don't come to mind 
> immediately.

Sure; but even those are a fairly small dimensionality than what the standard allows.
 
> I understand what you tried to do, including having length-one 
> dimensions, but I don't think that it is a sensible approach to handling 
> up to 999 dimensions. I agree with the flattening approach that Dmitry 
> suggested.

That would be rather unfortunate, to be honest. I'd much rather rely on the compiler translating the indexes than have to do so manually. I trust the compiler more than myself; plus letting it take care of keeping track of the mapping (ie FORTRAN convention) is nice.

My ultimate goal was to have some FITS_OBJECT type that had the appropriate data-members be able to simply "write itself to a stream" to output the proper FITS format file.

> 
> If your FITS files are not much larger than your RAM, the fastest 
> approach is probably to "mmap" the file into your virtual address space 
> and then compute the address of any given image pixel with the 
> flattening method. If your FITS files are larger than your RAM, your 
> program should process the file as a stream, which may or may not be 
> practical, depending on what the program should output.

Most of the anticipated usage for where I am right now would be producing FITS files, likely in something that would boil down to a coupling like this:

  Count      : Positive := 1;
  Today      : Ada.Calendar.Time renames Ada.Calendar.Clock;
  New_Image  : Camera_Image renames Normalize( Get_Camera_Image );
  New_Object : FITS.Object := FITS.Create_w_Defaults( New_Image );
  --..
  -- Writes data out to "Observation(YYYY-MM-DD)_00X.FITS".
  New_Object.Write( Base => "Observation", Date => Today, Count => X );

I'd rather not tie things to a memory-mapped file at a high level, but it may be that my ideal abstraction is non-tenable.


> > FITS was developed for handling "image" transport by the astronomy
> > world, back when there were 9-bit bytes and such.
> 
> I know, I used to work in astronomy. What's your point about 9-bit 
> bytes? FITS standard version 4.0 defines "byte" as 8 bits, and allows 
> only 8, 16, 32 and 64-bit pixels. No 9-bit pixels.

Sorry, that was more about Dmitry's suggestion to pretend representation-clauses don't exist; I haven't done anything at a bit-level at all. (And I don't think I need to, except perhaps to mark the Primary-Data array elements as Big-endian [IIRC].)