In the worlds of our common savior <- .oO( Yeah Right!!! ) Bill
Gates...hehehe....if nobody cares, it's a bug...if everyone cares, it's a
feature..;-)

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:bnmc74$137bsk$1@ID-25716.news.uni-berlin.de...
> 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
>