Re: OOC Core Library

[acken@informatik.uni-kl.de]

Michael G. wrote:
   > I do like the error handling.  Nice touch.

   Thanks.  In all cases, the functions will continue operating by returning
   a default value like infinity, zero, or other logical result and set the
   appropriate error condition.  It will be up the caller to check (or ignore)
   the error state.

Mh, I think the correct way to handle errors is to raise an exception.
Having to check an error code defeats the purpose of increasing the
execution speed, doesn't it?  And it makes modules that doesn't
explicitly check the error code (ie, almost all modules), somewhat
unrealiable. 

   Both zero and infinity are approximations.  These approximations were
   stolen from some Math modules posted by Alan D. Freed from NASA.  Basically
   infinity=MAX(REAL)/100 and zero=1/infinity.  This implementation thus
   avoids hardware overflow/underflow traps.  To implement a check against
   zero, this module does the following:

       IF ABS(x)<zero THEN (* the number is effectively zero *) END

Both the `epsilon' and `infinity' are exact values in the IEEE
standard.  IMHO you should either define them precisely by setting
them to the appropiate bit patterns, or you give those variables a 
different name.  

   > [something about inlining deleted]

   BTW, does this mean we wouldn't be supporting CODE procedures as
   used by ETH and shown (1st recommendation) in the Oakwood report.  It
   may be useful to use code procedures when interfacing to other languages
   and the OS. 

The implementation of CODE procedures is up to the back-end.  A assume
that by CODE you mean a string of bytes defining the procedure body in
terms of the target's machine code.  But the reference to CODE in the
context of procedure inlining is somewhat misplaced.  It is not
possible to inline such CODE procedures, procedure inlining is
exclusively  done on the GSA level, _not_ on the assembler level.
Calls to a CODE procedure are always coded as explicit calls and
cannot be removed.

   All routines will be as accurate as possible in the given floating point
   mantissa.  The routines should be comparable to the SUN math routines'
   accuracy and similar to a FPU.  The only difference will be in how the
   overflow/underflow are handled by the software routines so that execution 
   continues instead of trapping.

As I said before, I'd prefer exceptions above error codes.

Michael van Acken