"Marcus Denker" <denker at iam.unibe.ch> wrote:
 
> Am 20.07.2004 um 22:56 schrieb Boris Gaertner:
> 
> >
> > The result should be  1.0 + 0.0 i
> > but we get an arithmetic overflow.
> >
> > There are algorithms that can avoid arithmetic overflow.
> > These algorithms use scaling of operands.
> >
> > Attached you find a change set with two such algorithms
> > :
> > * an added method  #divideSecureBy: (required six divisions)
> > * an added method #divideFastAndSecureBy: (requires only three 
> > divisions)
> > * three additional tests for complex division.
> >
> >
> 
> I guess we should keep devision as is and provide the two others as 
> alternatives.

That is of course possible (and it is a solution that would allow me
numerical maths), but the user has to keep in mind that  reciprocal
is based on method "/". When a scaling algorithm is needed, the
user will have to write
  (1 + 0 i) secureDivisionBy: <arg>
This is doable, but perhaps we should add a comment to
method #reciprocal .

> I'l change the failing division test to run green (as we expect this to 
> fail due to the
> nature of floating point).
Yes, of course.
> 
> Or would it make sense to replace the implementation of #/ by  
> #divideSecureBy: ?
This is really difficult to say. For most appications #/ is certainly
sufficient. For problems where it is not sufficient, one has to look
for a suitable scaling of the operands. Problem analysis will
probably result in a specialized algorithm (because you can
scale the operands with an arbitrarily choosen non-zero factor.)
> 
>     Marcus

Greetings, Boris