Adam Beneschan expounded in news:102a43e8-21ea-4606-8b0d-6d492f9e07f8
@v13g2000prn.googlegroups.com:

> On Jun 29, 2:00�pm, Warren <ve3...@gmail.com> wrote:
>> Warren expounded 
>> > Adam Beneschan expounded 
>> > @b4g2000pra.googlegroups.com:
..
>> >> Isn't that just 1.0 / X? �
>>
>> > Ok, it seems to be, as the GSL (Gnu Scientific Library)
>> > defines it as:
>>
>> > gsl_complex
>> > gsl_complex_inverse (gsl_complex a)
>> > { � � � � � � � � � � � � � � � /* z=1/
> a */
>> > � double s = 1.0 / gsl_complex_abs (a);
>>
>> > � gsl_complex z;
>> > � GSL_SET_COMPLEX (&z, (GSL_REAL (a) * s) * s, -(GSL_IMAG (a) * s) *
>> s);
>> > � return z;
>> > }
>>
>> gsl_complex
>> gsl_complex_div (gsl_complex a, gsl_complex b)
>> { � � � � � � � � � � � � � � � /* z=a/b 
> */
>> � double ar = GSL_REAL (a), ai = GSL_IMAG (a);
>> � double br = GSL_REAL (b), bi = GSL_IMAG (b);
>>
>> � double s = 1.0 / gsl_complex_abs (b);
>>
>> � double sbr = s * br;
>> � double sbi = s * bi;
>>
>> � double zr = (ar * sbr + ai * sbi) * s;
>> � double zi = (ai * sbr - ar * sbi) * s;
>>
>> � gsl_complex z;
>> � GSL_SET_COMPLEX (&z, zr, zi);
>> � return z;
>>
>> }
>>
>> Given a=1.0, the inverse function is definitely
>> higher performance. �It'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.  

I'll concede your accuracy point. Efficiency however is 
still important for some applications, like realtime signal 
processing.

Warren