From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a05:660c:145:: with SMTP id r5mr5645219itk.25.1538758604385; Fri, 05 Oct 2018 09:56:44 -0700 (PDT) X-Received: by 2002:a9d:6515:: with SMTP id i21-v6mr159437otl.0.1538758604189; Fri, 05 Oct 2018 09:56:44 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.166.215.MISMATCH!z5-v6no87564ite.0!news-out.google.com!n199-v6ni124itn.0!nntp.google.com!z5-v6no87562ite.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 5 Oct 2018 09:56:43 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=76.18.64.97; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 76.18.64.97 References: <3f2828df-d54a-4427-bc3c-dc5ef0dc8069@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6a6e83b4-090c-4317-8880-d559fac4a9fc@googlegroups.com> Subject: Re: A little trouble with very large arrays. From: Shark8 Injection-Date: Fri, 05 Oct 2018 16:56:44 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:54484 Date: 2018-10-05T09:56:43-07:00 List-Id: 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? >=20 > A wrong way dealing with protocols is attempting to define an Ada type=20 > having the exact representation of the data as defined by the protocol.= =20 > It is both useless and difficult to impossible, especially if bits are=20 > 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 t= here 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=20 > simply provide operations to construct reasonably defined Ada objects=20 > from raw protocol data and conversely. Nobody would ever program=20 > anything using 999-D arrays. Nobody would ever instantiate n**1000=20 > instances. I still need a way to conform to the standard, that means if the standard s= ays that it's possible to have a 999-dimension array, I need to have some w= ay to represent this... even if it is never in actuality used. >=20 > You could use a flat array internally and provide operations for image=20 > serialization/deserialization in whatever format, e.g. by=20 > 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 =3D> 1, when 1 =3D> Item( Item'First ), when 2 =3D> Item( Item'First ) * Item( Item'Last ), when others =3D> Flatten( Item(Item'First..Item'Last/2) ) * Flatten( Item(Axis_Count'Succ(Item'Last/2)..Item'Last) ) ); >=20 > The hardest problem would be controlling bit representations. If they=20 > really mean that. Modern hardware usually handles octets atomically and= =20 > simply does not allow accessing individual bits. There is basically no=20 > way to tell the bit order programmatically or even define "order". >=20 > --=20 > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de