Re: My thoughts on FTDIA
Arnold Neumaier wrote:
On the other hand, it is the *property tracking* which actually computes
the
range enclosure and decoration on the left. In his own words, I believe
John
therefore demonstrates both the need for property tracking and its
relation
to FTDIA.
Property tracking is also only theory. All it does is talk about
evaluation or computation.
Practice is the implemented version of whatever we discuss here.
A conforming implementation of IEEE 1788 must surely practice evaluation and
computation.
Another key point.
For the reasons Arnold would have Motion 25 rejected:
Arnold Neumaier wrote:
But I think Motion 25 is far too low level on arithmetic operations...
Thus I would recommend voting No to the current version of the motion.
This is only half of the reason, and probably the less important half.
The other half is the way the motion treats intersection and union.
The motion text does not address intersection and union.
Anyhow, the formulation of intersection in v3.01 may lead to catastrophic
failures in interval algorithms. Clearly this is not acceptable.
To my understanding, IEEE 1788 is *supposed* to be a standard that is
practically implementable at a low-level, notably at the hardware level.
If
this is true, then John and Arnold need to show that FTDIA is practicable
at
this level, and even more importantly that such practice can be done in a
standardized manner. Neither of them have accomplished this.
This doesn't depend on whether the decorations are defined as bit patterns
(low level) or as abstract level 1 semantic units.
Motion 25 does not define any bit patterns.
The decorations are abstract level 1 units.
Nate