Re: Higher precision and generics

[kst@thomsoft.com (Keith Thompson)]

In <3kbhv0$jcl@maple.enet.net> dkurfis@enet.net (Dan Kurfis) writes:
> 	Next, I think I can now explain what I was trying to say earlier 
> about the use of the optional range clause.  A typical application for me 
> might involve radar range data.  Most of the radars I work with have 
> range accuracies no better than a few meters.  Therefore, I might create 
> the following type:
> 
> 	type Radar_Range_Meters is digits 1;
> 
> 
> This type would be more than adequate for my needs, since 1/10 of a 
> meter far exceeds the accuracy of my radar.  However, my compiler will 
> still use the largest floating point types available because it has no 
> idea what the MAXIMUM range is.  If I qualify the type declaration:
> 
> 	type Radar_Range_Meters is digits 1 range 0.0..37000.0;
> 
> I now have a type which covers a maximum range of 20 nautical miles.  
> This type can easily fit inside the 32-bit format.

Hmm.  That's odd but legal behavior on the part of your compiler.  Both
Ada 83 and Ada 95 define a minimum implicit range for a floating-point
type definition that doesn't have an explicit range constraint (the range
is determined slightly differently in 83 vs. 95).  For your declaration

	type Radar_Range_Meters is digits 1;

this implicit range is (almost?) certain to be within the range of a
32-bit floating-point type; under Ada 95 rules, the minimum range for
this declaration is -10_000.0 .. +10_000.0.  Some implementations choose
the smallest suitable representation.  The only requirement is that the
chosen implementation has to be able to represent all the "model numbers"
defined by the declaration.

The compiler could choose either 32 or 64 bits both of your declarationss
of Radar_Range_Meters; I'm surprised it doesn't choose the same for both.

The real problem with your declaration, though, is that the digits value
specifies the *total* decimal digits of precision, not the digits after
the decimal point.  For a value of, say, 800.0, the relative error is
on the order of 100.0, not 0.1.

It happens that the smallest floating-point type on typical systems
has about 6 digits of precision, which is why your declaration happens
to work.

If you want to specify absolute precision (0.1 meters) rather than
relative precision (N digits), use fixed-point rather than floating-point.

I don't think implicit scaling or biasing makes much sense for
floating-point, given current hardware; it would simply require
extra operations for each result to maintain the representation.
For fixed-point, scaling is part of the definition (fixed-point values
are essentially scaled integers); biasing might be useful, but I don't
know of any implementations that support it.

-- 
Keith Thompson (The_Other_Keith)  kst@thomsoft.com (kst@alsys.com still works)
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
That's Keith Thompson *with* a 'p', Thomson Software Products *without* a 'p'.