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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,38fc011071df5a27 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-03 15:20:50 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: 18k11tm001@sneakemail.com (Russ) Newsgroups: comp.lang.ada Subject: Re: Ideas for Ada 200X Date: 3 Jun 2003 15:20:50 -0700 Organization: http://groups.google.com/ Message-ID: References: <6a90b886.0305262344.1d558079@posting.google.com> <3ED41344.7090105@spam.com> <3ED46D81.FF62C34F@0.0> <3ED46E07.4340CABC@0.0> <3ED4F3FD.A0EF7079@alfred-hilscher.de> <6vWcnTWjF83bD0qjXTWcpA@gbronline.com> <3EDCBDF4.1050900@attbi.com> NNTP-Posting-Host: 128.102.146.44 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1054678850 4737 127.0.0.1 (3 Jun 2003 22:20:50 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 3 Jun 2003 22:20:50 GMT Xref: archiver1.google.com comp.lang.ada:38559 Date: 2003-06-03T22:20:50+00:00 List-Id: "Robert I. Eachus" wrote in message news:<3EDCBDF4.1050900@attbi.com>... > Russ wrote: > > > Once again, I will explain why. The first form requires the creation > > of a temporary matrix to hold the sum, then a copy from the temporary > > back to A. The second form, on the other hand, can do the addition in > > place in A on an element by element basis, eliminating the need for > > the temporary matrix and the copy operation. > > Give it a rest. You keep trying to "explain" things like this to a > newsgroup where there are several compiler experts who regularly post. > Bob, Randy, Tucker and I could probably spend hours discussing where Ada > requires that the intermediates be materialized. We have had such > discussions, one of the results of those discussions is the Ada 95 > Reference Manual. But since there are more than four participants out there in this newsgroup, I assume that some of them are NOT compiler experts. So please don't take my posts so personally. > If Ada does require an intermediate value to be materialized, it does so > with good reason. Let's take a look at your matrix example. Ada > requires that in > > A := A + B; > > The value of A be unchanged if Constraint_Error is raised, in other > words if there is an overflow when adding one of the elements of A to > one of the elements of B. If the type of A and B is modular, then no > intermediate is required or used. A better example might be: Suppose the elements of A and B *are* modular, and I write A := A + B + C Are you telling me no temporaries are needed? And suppose I define "+" for quaternion arithmetic. Still no temporaries needed? > A := A and B; > > Where A and B are boolean vectors. This can be done in place. Again, how about A := A and B and C? No temps needed? > What if Ada did allow: > > A += B; ? > > Then the Ada rules would still require that A be unchanged if > Constraint_Error was raised, so there would be an intermediate. Of > course, a compiler could 'unwind' the partial addition by subtraction to > produce the required result. It would be an interesting optimization, > but AFAIK, no Ada compiler does it. Well, it seems to me that such an "interesting optimization" might be well worth doing. Then again, the "unwind" operation would obviously depend on the definition of the "+=" operation, which could be different for each type, so I don't see how it could be done in general. In any case, the performance hit taken to keep A unchanged when a Constraint_Error is raised seems rather expensive to me. If it were up to me, I would take the factor of four better efficiency over preserving A in the rare case of an overflow. And I'll bet most programmers doing heavy-duty number crunching for simulation would too. I know that Ada is preferable for safety-critical applications, but based on what you are telling me, it sure seems to be a poor choice for non-safety-critical simulation with heavy number crunching. Thanks for clarifying that. I guess C++ is good for something after all, eh?