Re: Why no 'Floor for fixed point types

["Robert I. Eachus" <rieachus@comcast.net>]

Randy Brukardt wrote:
> "Robert I. Eachus" <rieachus@comcast.net> wrote in message
> news:3F9AFB67.5080401@comcast.net...
> 
>>But you didn't pay attention above.  The compiler allows you to think
>>about fixed-point types as if they are real (non-integer) values.  But
>>they are not implemented that way.  Any compiler that uses
>>floating-point arithmetic to do fixed-point computations has a lot of
>>bugs in it.   They just havent been found yet.  (And I think it was ACVC
>>1.4 that added a lot of tests which found such bugs.) 
> 
> As usual with blanket statements, this is wrong. Janus/Ada in fact does use
> floating-point arithmetic to implement fixed point in some cases (especially
> the mixed multiply). We did the error analysis on these operations, and they
> are fine - they'll get the right answer in all cases that Ada 95 requires
> that. (There are some cases where no technique will get the "right" answer
> as defined in Ada 83, and those of course we might get wrong for some bit
> patterns. Many Ada 83 compilers simply avoided the issue by restricting
> 'Small to powers of two, which of course is trivial to get right. And rather
> restrictive.) Since, in a generic, you don't know the 'Smalls involved, and
> you don't know the magatude of the values, there isn't much else to do
> except use the highest precision math that you have available. As with
> everything, it depends on how you use it.

Actually, I think you are agreeing with me.  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.  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).

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.

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.)

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.)

-- 
                                           Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig