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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Attributes: gid103376,gid1094ba,public X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 29 May 2006 15:07:05 -0500 Date: Mon, 29 May 2006 13:07:37 -0700 From: glen herrmannsfeldt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.fortran Subject: Re: Ada vs Fortran for scientific applications References: <4dd87pF18ot14U1@individual.net> <447207D6.3010408@cits1.stanford.edu> <4dg101F17acafU1@individual.net> <44730df4$1@news.meer.net> <4diimsF1b0c25U1@individual.net> <8V_cg.155757$eR6.70498@bgtnsc04-news.ops.worldnet.att.net> <646dnfYoKul8MOnZnZ2dnUVZ_tydnZ2d@comcast.com> <4e09bgF1cdqssU2@individual.net> In-Reply-To: <4e09bgF1cdqssU2@individual.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Host: 24.18.174.4 X-Trace: sv3-SmXIChaFY/k20trYDMJ39Fi1QNTw2rJph0n5zGZQdB86q9ZnI5b8kZETjcHzfW+4Vh+54+fNM42HxzR!J3LrH+Njiz/npCExhFm31aOrVk0b5qKr6CBR7JcHJ2/ZOzj0dks5O4918aVrKIcRWWrg2r8jAKA8!G9qkVA== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:4591 comp.lang.fortran:10453 Date: 2006-05-29T13:07:37-07:00 List-Id: Jan Vorbr�ggen wrote: >> OK, but say for a certain program it is more efficient to store a >> complex array with all the real parts followed by all the imaginary >> parts, and the compiler figured this out. The "as if" rule would work >> only if there was no other way for the program/programmer to discover >> the change. If the array was in COMMON, EQUIVALENCEd, or passed to an >> external routine, this optimization most likely couldn't be done. >> Without any legal way to view the storage association, it would seem >> possible to do it. > Precisely what I was thinking. So historic baggage is weighing Fortran down > in this particular case. It seems pretty convenient for FFT routines to treat a COMPLEX array as REAL. It would take some time to know if this speeds up the FFT or not. One alternative, as you say precluded by Fortran history, would be something like the descriptor of assumed shape arrays that could describe a COMPLEX type where the real and imaginary parts are not consecutive. It would seem that this could be done in the case of assumed shape arrays, as they are already incompatible with assumed size arrays, normally requiring a copy if passed to an assumed size array subprogram. -- glen