Math Update for Ada 2005

["Steven Deller" <deller@smsail.com>]

All the email about Math libraries reminded me of one of Ada 95's
shortcomings.

The IEEE math definitions have included NaN and Inf semantics for quite
some time. Many (if not all) native platforms and many embedded
platforms can support this.  I have run into C++ and C code that uses
these.  Ada 95 does NOT support these.

Interfacing Ada with C or C++ code that uses these can be quite a pain.

How could we add these semantics into Ada 2005 without breaking past
code and without *forcing* platforms to support this (if they don't do
so easily).

My thought was to have some sort of program wide values for floating
point (settable?), with appropriate attributes to query the settings.

Is that reasonable?

Does anyone else want these semantics available?

Suppose you have a subtype with narrow constraints (less than the 'Base
range).  Would Inf and NaN apply?  I believe it would.

I'd suggest that wherever raising constraint_error (for these types)
would occur, instead the values would be set directly to "Inf" or "NaN"
(consistent with IEEE semantics).  Basically, if 'Base includes Inf and
NaN values, then any subtype would include them as well.   Or more to
the point, any and all floating point types either would, or would not,
include the values Inf and NaN (and appropriate semantics).

Addition of these values would not require any additional constraint
checking beyond that which is done now.  Wherever code (without NaN and
Inf) would have done a constraint check:
  if val<low_bound then raise constraint_error
  if val>hi_bound then raise constraint_error

code (with NaN and Inf) would now be generated as
  if val /= NaN and val<low_bound then val := -Inf
  if val /= NaN and val>hi_bound then val := +Inf

I seem to recall (?) that the "two" predicates are really just one test
in IEEE arithmetic, i.e. I believe there is a way to check for something
being "commensurate" and then comparing values, so the resulting code
should not be any more complex or costly than current code. 

Typical application code could then look like:
  do lots of computations to compute one or more values
  if val = Inf then
    do things based on value going out of range
    including possibly explicitly raising constraint_error
  end if

  if val = NaN then
    ...

The state could even be settable (perhaps at execution startup).  In
that case, there would have to be a test for the state (to decide
whether to raise constraint_error or set a value to +/-Inf) though there
might be some clever load time operations that could eliminate that
test.

This model can simplify code in many situations.  When it is EXPECTED
that something may go out of range and "that is ok", then raising an
exception is not necessarily the right thing to do, particularly if the
computation code "consumes" some inputs.  The current Ada model *forces*
an application to either "consume all data before computing", wrap an
exception handler around every data "consumption", or have coupling
between code and one "overall" exception handler so the handler knows
how much data to "skip".   None of these may be as satisfactory as:
  loop
   get data
   compute some
   get more data
   compute some
   get more data
   compute some
   if NaN or Inf values then
     output something
   else
     output something else
   end if 
  end loop

Regards,
Steven Deller