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,5f5a48f21d7f7525 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!v13g2000prn.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Inferring array index type from array object Date: Tue, 29 Jun 2010 15:22:32 -0700 (PDT) Organization: http://groups.google.com Message-ID: <102a43e8-21ea-4606-8b0d-6d492f9e07f8@v13g2000prn.googlegroups.com> References: <6b20ed09-efc1-4df7-90f9-5e141482e8d0@d37g2000yqm.googlegroups.com> <1305oqccr1h2t$.x33x4oxwd84d$.dlg@40tude.net> <88ec2vF3uqU1@mid.individual.net> <88f9osFmcmU1@mid.individual.net> <88sld2F9m8U1@mid.individual.net> <73a0af1d-7213-44af-90fa-ed6de4c64ce8@b4g2000pra.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1277850153 23287 127.0.0.1 (29 Jun 2010 22:22:33 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 29 Jun 2010 22:22:33 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: v13g2000prn.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:12008 Date: 2010-06-29T15:22:32-07:00 List-Id: On Jun 29, 2:00=A0pm, Warren wrote: > Warren expounded innews:Xns9DA6AC2A2C8BWarrensBlatherings@81.169.183.62: > > > > > > > > > Adam Beneschan expounded in news:73a0af1d-7213-44af-90fa-ed6de4c64ce8 > > @b4g2000pra.googlegroups.com: > > >> On Jun 29, 12:31 pm, Warren wrote: > > >>> > So, what is the "missing" function? > > >>> > > > >>> 1) The "inverse" of a complex number. > > >> Isn't that just 1.0 / X? =A0 > > > Ok, it seems to be, as the GSL (Gnu Scientific Library) > > defines it as: > > > gsl_complex > > gsl_complex_inverse (gsl_complex a) > > { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* z=3D1/= a */ > > =A0 double s =3D 1.0 / gsl_complex_abs (a); > > > =A0 gsl_complex z; > > =A0 GSL_SET_COMPLEX (&z, (GSL_REAL (a) * s) * s, -(GSL_IMAG (a) * s) * > s); > > =A0 return z; > > } > > Apologies for following up my own post, but > looking at the GSL implementation of complex > division: > > gsl_complex > gsl_complex_div (gsl_complex a, gsl_complex b) > { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* z=3Da/b = */ > =A0 double ar =3D GSL_REAL (a), ai =3D GSL_IMAG (a); > =A0 double br =3D GSL_REAL (b), bi =3D GSL_IMAG (b); > > =A0 double s =3D 1.0 / gsl_complex_abs (b); > > =A0 double sbr =3D s * br; > =A0 double sbi =3D s * bi; > > =A0 double zr =3D (ar * sbr + ai * sbi) * s; > =A0 double zi =3D (ai * sbr - ar * sbi) * s; > > =A0 gsl_complex z; > =A0 GSL_SET_COMPLEX (&z, zr, zi); > =A0 return z; > > } > > Given a=3D1.0, the inverse function is definitely > higher performance. =A0It's simpler calculation > probably implies more accuracy as well. That last makes no sense to me. The code to compute A / Z for real A has got to be essentially the same as computing 1.0 / Z and then multiplying the real and imaginary parts of the result by A---how else would it be done? So while you might gain slightly in efficiency by not performing an extra step, I don't see how you can gain in accuracy---I've never heard of accuracy ever getting lost by multiplying a floating-point number by 1.0. Not according to everything I know about how floating-point arithmetic works. Even if you implement A / Z by converting A to a complex number A+0i and then performing a complex division, I still don't see any way to do this except by computing 1.0/Z and performing a complex multiplication; again, while there will be some wasted processor cycles, you're still going to be multiplying numbers by 1.0 and then adding 0.0, which again is not going to result in any lost accuracy. -- Adam