Counter-Productive Accuracy of Universal Fixed 87-02-10 AI-00522/00 1
!standard 04.05.05 (11) 87-02-10 AI-00522/00
!class binding interpretation 87-02-10 (provisional classification)
!status received 87-02-10
!topic Counter-Productive Accuracy of Universal Fixed
!summary 87-02-10
!question 87-02-10
!recommendation 87-02-10
!wording 87-02-10
!discussion 87-02-10
!appendix 87-02-10
*****************************************************************************
!section 04.05.05 (11) Terry Froggatt 86-12-09 83-00888
!version 1983
!topic Counter-Productive Accuracy of Universal Fixed
There are areas where the Ada language insists on too much accuracy,
and so violates any rationale based on accuracy/time/store tradeoffs.
The best-known case is that of floating-point exponentiation, but far
worse problems arise when implementing fixed-point arithmetic fully.
These problems have not come to light sooner because the implementation
of arbitrary "small" representation clauses has been made optional in the
language. So as far as I am aware, no compiler yet fully implements them
because of uncertainty as to whether the accuracy requirements could be met.
However, this is putting things the wrong way round. It is important to
implement arbitrary smalls so that the classical fixed point range-related
scalings can be used. Our customers want us to do this. The only problem is
whether to honour Ada's accuracy requirements or do something more sensible.
In my paper "Fixed-Point Conversion, Multiplication, & Division, in Ada(R)",
to appear shortly in Ada Letters, I show that the operations
required for classical fixed-point working can be implemented to the
accuracy required by the Ada language, using finite-precision arithmetic.
For example, I show that a fixed-point multiplication or division, of two
operands of the same length, which is converted to another fixed point
type of the same length, can be achieved, but by triple-length arithmetic.
If the result type is integer or float, longer arithmetic may be needed.
Thus the current accuracy requirements are counter-productive:
on a typical machine having 16 bit arithmetic with 32 bit products
and 32 bit arithmetic with 64 bit products, only 16 bit fixed point
types can be fully implemented by hardware. With relaxed accuracy
requirements, 32 bit fixed point types could be implemented: the
Counter-Productive Accuracy of Universal Fixed 87-02-10 AI-00522/00 2
overall effect is to provide greater accuracy in less time.
So, as a matter of some urgency, the accuracy required of scaled
fixed-point multiplication and division should be relaxed,
so that they can be "handled simply by the underlying hardware",
using nothing more than the double-length arithmetic already needed.
This relaxation can be made without upsetting any existing Ada users.
*****************************************************************************
!section 04.06 (07) Terry Froggatt 86-12-08 83-00887
!version 1983
!topic Counter-Productive Accuracy of Numeric Conversions
There are areas where the Ada language insists on too much accuracy,
and so violates any rationale based on accuracy/time/store tradeoffs.
The best-known case is that of floating-point exponentiation, but far
worse problems arise when implementing fixed-point arithmetic fully.
These problems have not come to light sooner because the implementation
of arbitrary "small" representation clauses has been made optional in the
language. So as far as I am aware, no compiler yet fully implements them
because of uncertainty as to whether the accuracy requirements could be met.
However, this is putting things the wrong way round. It is important to
implement arbitrary smalls so that the classical fixed point range-related
scalings can be used. Our customers want us to do this. The only problem is
whether to honour Ada's accuracy requirements or do something more sensible.
In my paper "Fixed-Point Conversion, Multiplication, & Division, in Ada(R)",
to appear shortly in Ada Letters, I show that the operations
required for classical fixed-point working can be implemented to the
accuracy required by the Ada language, using finite-precision arithmetic.
For example, I show that conversion of a fixed-point type to an integer
type of the same length can be achieved by a multiplication by one
constant and division by another, but using one more bit than double-length.
Conversion of Universal Fixed to an integer type is particularly difficult.
(Conversions between fixed and float may also loose accuracy if a
normallisation shift occurs as a result of the scaling multiplication).
Thus the current accuracy requirements are counter-productive:
on a typical machine having 16 bit arithmetic with 32 bit products
and 32 bit arithmetic with 64 bit products, only 16 bit fixed point
types can be fully implemented by hardware. With relaxed accuracy
requirements, 32 bit fixed point types could be implemented: the
overall effect is to provide greater accuracy in less time.
So, as a matter of some urgency, the accuracy required of scaled
conversions between fixed types and other types should be relaxed,
so that they can be "handled simply by the underlying hardware",
using nothing more than the double-length arithmetic already needed.
(The requirement to always correctly round conversions to
Counter-Productive Accuracy of Universal Fixed 87-02-10 AI-00522/00 3
integer types is probably the worst culprit: without this,
multi-length divisions could probably be avoided).
This relaxation can be made without upsetting any existing Ada users.