Re: Renaming Fixed Point Mutiplicative operator in Ada 95

[dewar@merv.cs.nyu.edu (Robert Dewar)]

<<If you are suggesting that all divisions are guarded by a test for
denonimator non-zero - then wouln't the most obvious place for that test be
within the division operator itself! Otherwise you have a massive
review/verification effort to check that all divisions are guarded! If it
is inside the operator then that test is done once.  Also
 there is the question of the code that has to be placed inside the "if"
side of the check.

(BTW - the example you gave in your previous posting of surrounding the
operation with an exception handler is banned by SPARK Ada.....)
>>

Well certainly the problem is aggravated by this restriction. In general,
the Ada features are carefully organized to work together, and when you
start legislating that certain features not be used, you most certainly
are likely to create rough spots.

In particular, it is in general not feasible to define your own operators
for fixed-point multiplication in the general case anyway. This is because
you would need to define n**3 operators where n is the number of fixed-point
types you have. For a relatively simple COBOL-like program where it is
frequently reasonable to have 50-100 such types, you cannot go defining
a million fixed-point multiplication routines!

In Ada (as opposed to some arbitrarily legislated subset or dialect), the
problem of division by zero being tested by the fixed-point multiplication
is solved, at least if Machine_Overflows is True, which is likely for 
fixed-point (and certainly true in all implementations of which I am aware).
This exception can then be caught with whatever granularity you require.

Note that if you are using SPARK Ada, then you are in a realm where you most
definitely ARE expected to prove that what you do does NOT generate exceptions,
so I would think that runtime checks for division by zero would be quite an
oddity in such an applicatoin anyway. If there is a need for data validation,
it would happen much earlier on.