Re: Logic Errors and Ada

["Robert I. Eachus" <rieachus@attbi.com>]

Peter Hermann wrote:

> thank you, Robert, for your excellent contribution:
> you should have sent it a couple of years sooner   ;-)
> OTOH, thanks to Ada it is quite easy to update my code 
> http://www.csv.ica.uni-stuttgart.de/homes/ph/adapilotresources/basic_tools/coords.ads
> for enhanced precision.

It probably would not have worked.  In Ada83 there was an unintentional 
glitch in the definition of the multiply operator for fixed point types 
that made it a pain for compilers to accept "arbitrary" specifications 
of 'Small.  This was all the more painful because a programmer might 
never create the horrible case, but compilers had to reject the type 
declaration if they couldn't handle all possible cases where types with 
different 'Smalls were used in one multiplication.  I won't go into the 
gory details, but there were a few cases which required triple precision 
integer arithmetic at run time.  No one really wanted to use those 
operations, but the easiest thing for implementors to do was to reject 
many specifications of 'Small.

In Ada95 the rules were change slightly.  But IMHO, the bigger change 
was that all implementors were reassured that if a weird case not 
covered by the rules showed up, the intent was to fix the rules, not 
punish implementors.  Add to that the new decimal types which require 
some support for non-powers-of-two 'Small, and AFIAK all Ada compilers 
now support the most important case: 1.0/X where X is a (32-bit) integer.

Oh, and I really do mean integer there.  Division of 1.0 by a universal 
integer is legal in Ada.  I don't know if any compilers are not smart 
enough to figure out that 1.0/360000.0 should mean the same thing. It is 
so easy to ask for what I want (X * My_Type'Small = 1.0 exactly).  So I 
do that instead of asking for something else and hoping the compiler 
will figure it out.

> For storage reasons I could?should offer different types of precision.

I can't see why.  Most likely unless you really want to try to force the 
compiler to use 16-bit representations, you will get a 32-bit object. 
Hundreths of a second gets you, what, about one foot accuracy? 
(Technically, a compiler should be able to support 1/2000 of a degree in 
latitude and  1/1000 in longitude, but I have never tried it.)