From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a05:622a:1f16:b0:3ab:c68a:de4f with SMTP id ca22-20020a05622a1f1600b003abc68ade4fmr573311qtb.511.1674453719329; Sun, 22 Jan 2023 22:01:59 -0800 (PST) X-Received: by 2002:a05:6871:4097:b0:15f:3213:dfc4 with SMTP id kz23-20020a056871409700b0015f3213dfc4mr1533769oab.77.1674453719058; Sun, 22 Jan 2023 22:01:59 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!border-1.nntp.ord.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 22 Jan 2023 22:01:58 -0800 (PST) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=157.143.56.236; posting-account=Wbe3fAoAAAALa8UT9MWTy6mw2ahlRJms NNTP-Posting-Host: 157.143.56.236 References: <9c7cccd9-733f-49a8-b482-087ccb14b58dn@googlegroups.com> <3db6b678-5a45-4b4d-9f6c-e4933b04d6c2n@googlegroups.com> <6dbff95d-8e30-4a60-ad03-d0aa4cff1583n@googlegroups.com> <49c1bfc5-38aa-4360-81f3-c95f867160een@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7ac68f96-7041-4b3c-adbc-547b17735357n@googlegroups.com> Subject: Re: Real_Arrays on heap with overloaded operators and clean syntax From: Jim Paloander Injection-Date: Mon, 23 Jan 2023 06:01:59 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:64863 List-Id: On Monday, January 23, 2023 at 2:14:58 AM UTC+1, Leo Brewin wrote: > Here is a slight variation on the solution suggested by Gautier. It uses= =20 > Aad's "rename" syntax so that you can avoid all the .all stuff. I use=20 > this construction extensively in my large scale scientific computations.= =20 >=20 > with Ada.Numerics.Generic_Real_Arrays;=20 > with Ada.Unchecked_Deallocation; > procedure Test_Large is=20 >=20 > type Float_15 is digits 15;=20 >=20 > package F15_R_A is new Ada.Numerics.Generic_Real_Arrays (Float_15);=20 >=20 > use F15_R_A;=20 >=20 > procedure Solve_it=20 > (x : in Real_Vector;=20 > y : out Real_Vector;=20 > A : in Real_Matrix) is=20 > begin=20 > null; -- Here, the big number-crunching=20 > end;=20 >=20 > n : constant :=3D 10_000;=20 >=20 > type Vector_Access is access Real_Vector;=20 > type Matrix_Access is access Real_Matrix; > x_ptr, y_ptr : Vector_Access :=3D new Real_Vector (1 .. n);=20 > A_ptr : Matrix_Access :=3D new Real_Matrix (1 .. n, 1 .. n);=20 >=20 > x : Real_Vector renames x_ptr.all;=20 > y : Real_Vector renames y_ptr.all;=20 > A : Real_Matrix renames A_ptr.all;=20 >=20 > procedure FreeVector is new=20 > Ada.Unchecked_Deallocation (Real_Vector,Vector_Access);=20 > procedure FreeMatrix is new=20 > Ada.Unchecked_Deallocation (Real_Matrix,Matrix_Access);=20 >=20 > begin=20 > Solve_it (x, y, A);=20 > -- Deallocation here=20 > FreeVector (x_ptr);=20 > FreeVector (y_ptr);=20 > FreeMatrix (A_ptr);=20 > end; Thank you very much, would a for Real_Vector_Access'Storage_Pool use = localPool; save you from the need to free the vectors and matrix yourself? On the other hand, is there any way of avoiding temporaries? Possibly a mo= dern version of the Real_Array using expression generic syntax or something= similar? Since you are using scientific computationas extensively, you mus= t be aware of Fortran. Have you compared Fortran's complex numbers with ADA= 's for inner products or similar computations to see who is faster? You see= , I like a lot of things about ADA, but the syntax is really difficult to f= ollow. Sometimes it gives me the impression that it is more difficult than = really needed to be. For example there should be a way for Real_Arrays to a= llocate memory internally and not on the stack directly like containers. An= d for containers to provide an indexer Vector(i) and overloaded operators s= imilarly to Real_Vectors. But the fact that they do not give me the impress= ion that this Language although being designed by the army for mission crit= ical applications never realized that modern mission critical need to simpl= ify mathematical calculations providing an easy syntax. I am surprised that= after so many years and so many updates to the Standard the designers of t= he Language did not realized that such mathematical syntax should be simpli= fied to attract more people from scientific computing, who are tired with F= ortran 10000 ways of declaring something a variable.