Bob, Malcolm,

Thanks so much for the feedback.

Since I have access to all three platforms, I ran a benchmark on Mac OSX,
Windows, and Linux, to compare the speed of the the two implementations.
Each test performed 900,000 complex multiplications. The results are as
follows:

Platform   | CPU        | 4 mult/2 add | 3 mult/5 add
-----------+------------+--------------+-------------
Mac OSX    | G5, 1.8GHz | 33.5 sec     | 33.7 sec
Linux      | P4, 3.0GHz | 20.0 sec     | 20.2 sec
Windows XP | P4, 3.8GHz | 44.8 sec     | 45.0 sec

The standard method is marginally faster than the method with one less
multiplication. There is almost no difference. It is interesting to note
that the Windows machine, which has the fastest CPU, was slower than the
other machines.

Since rounding errors could become an issue for large numbers when
subtracting floating point numbers (or when one number is large compared to
the other when adding floating point numbers), keeping the number of
operations as low as possible should minimize such errors. Hence, I decided
to stick with the current implementation.

Thanks again for the feedback, and cheers,

Roger




> From: Malcolm Smith <[EMAIL PROTECTED]>
> Reply-To: REALbasic NUG <[email protected]>
> Date: Sun, 16 Jul 2006 12:34:32 -0700
> To: REALbasic NUG <[email protected]>
> Subject: Re: [ANN] Complex Utilities 1.0 (Open Source)
> 
> 
> On Jul 16, 2006, at 12:05 PM, Bob Delaney wrote:
> 
>> I note that you use the standard code for a complex multiply:
>> 
>> (a + i*b) * (c + i*d)  =  ( (a*c) - (b*d) + i*((a*d) + (b*c)) )
>> 
>> This requires 4 multiplications and 2 additions. Since a
>> multiplication of doubles takes considerably longer than does an
>> addition, you might want to consider using the following:
>> 
>> x + i*y = (a + i*b) * (c + i*d)
>> 
>> ac = a*c
>> bd = b*d
>> 
>> y = (a + b)*(c + d) - ac - bd
>> x = ac - bd
>> 
>> which requires 3 multiplications and 5 additions.
> 
> I just did some timings and it appears as if the multiply is faster
> on my G4 but the difference is quite small.
> 
> I would not recommend the "fast" method as it performs more total
> operations (8 versus 6) and is likely to have greater rounding error
> due to canceling out the ac and bd terms in the y term.
> 
> If you are concerned about speed, the best thing to do is probably to
> benchmark the two methods on a variety of platforms.


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Reply via email to