Re: Why no 'Floor for fixed point types

[Nick Roberts <nick.roberts@acm.org>]

Robert I. Eachus wrote:

> ...  Trying to test even a small 
> subset of all possible reasonable values of 'Small and fixed-point 
> numbers just isn't reasonably possible without trillions of machines 
> crunching for millions of years.   So your compiler probably has 
> millions of errors in the low order bit that are just not practical to 
> find, and of no real interest to anyone anyway.

So possibly a question we should ask is "If nobody cares, does it count as 
an error (or bug)?" I admit, there might be a few Intel customers who'd 
like to know the answer to that one. :-)

> From experience with 
> fixed-point, the tough cases are of the form A := Fixed(B*C); where B 
> and C are of two other types than Fixed, and there is no easy 
> representation of Fixed'Small/(B_type'Small * C_type'Small).

What do you mean when you say these are tough cases? The RM95 essentially 
says that the result is either of the representable values (of the type 
Fixed here) which bound the precise result.

> In practice those cases are of little or no interest to anyone.  If your 
> compiler correctly implements A := A * I; where I is an Integer, or A := 
> B + C; where all three are of the same fixed-point type, then I and most 
> other fixed-point users won't care about those painful cases.  Other 
> than, of course, to note that they exist so that we can avoid them.

But why are the cases you refer to painful? Do they really need to be avoided?

I can certainly see that if a calculation causes a missile to hit someone's 
house (instead of the next door embassy), it might be quite painful for the 
occupants of the house. Are you saying that these cases are capable of 
being sources of nasty accidents, or are you saying that they are merely an 
academic curiosity, of no possible practical consequence? (And I realise 
this may be a slightly unfair question.)

> If you do use the three type multiplication operator, you should check 
> whether it is an easy or hard case, and avoid the hard cases.  (Any 
> conversion where the target type is the same as one of the multiplicand 
> types counts as easy, since it can be done with a single division.)

Would you please provide an example, to illustrate this point.

> I'm not trying to scare anyone here.  In fact one of the differences 
> between Ada 83 and Ada 95 is that the error bounds on the hard cases 
> were changed to make them easier to implement.  The hard cases do come 
> up, and for example, one of the harder parts of the Euro conversion was 
> to specify rules and error bounds for some of these three type 
> conversions.  (Say from Marks to Kronar, using today's market rates for 
> Marks to Euros and Euros to Kronar.)

I seem to dimly recall you mentioning this before, Robert. Was it in 
comp.lang.ada? I would like to review it on Google, if possible.

-- 
Nick Roberts