(SC22WG11.754) German comments in LIA-2

[David Hough validgh business]

> (1) I strongly agree with UK comment 1 on the distinction between REAL 
> values that have no significant fractional part and exact INTEGERs.  
> (And I believe that Dr. Kahan would strongly agree with the UK position 
> that "real values should always be considered approximate", since he 
> wrote that in more than one paper.)

Without going into all the other reported comments, and things that could
be said about LIA-x, I must point out this is a grossly misleading 
oversimplification of reality and of Kahan's teachings on the subject.

In general, a value in a floating-point value may be exact or inexact, but
lots of critical software depends on arithmetic that treats that value as
if it were exact:  thus in general floating-point differences taken early in 
a computation must be rendered exactly if possible, even if the data items
whose difference is taken may have some error.     What's important is
preserving (or eliminating, if that's the intent) correlations in the error
affecting different items, and since general-purpose hardware and software
doesn't know what correlations will be important, it's best if it treats
data as exact, even if it isn't.    There would be no need for the inexact
exception in IEEE 754 arithmetic if all floating-point data were presumed
inexact to start with.

More to the present point, on many systems including a number of early RISC 
implementations, exact integer multiplication and division is done faster
in floating-point registers and so is done with floating-point variables. 
So sometimes an integer value in a floating-point variable is just an integer
value in a floating-point variable.

These matters are indeed confused within C implementations, 
with respect to the pow() function
and the missing powi or pown corresponding to Fortran's x**n, and I'm not
surprised that C's pow() is hard to map to LIA-x.

The ultimate resolution of many of these kinds of quandaries lies in
interval methods, which manifest the differences between exact and inexact
values.



> From edbarkacme.nist.gov Fri Jun 27 13:38:19 1997
> Date: Fri, 27 Jun 97 16:19:29 EDT
> From: edbarkacme.nist.gov (Ed Barkmeyer)
> To: sc22wg11adkuug.dk
> Subject: (SC22WG11.754) German comments in LIA-2
> 
> 
> Herein I do not represent the position of NIST or the United States or 
> any part of its deliberations.  
> 
> First, I would point out that only the attachment to the German comments
> is "identical to the US comments except in ordering".  This common set of
> comments, moreover, seems to be something more like a liaison statement
> from WG14.  The principal body of comments from Germany itself simply 
> says that the WG14 comments indicate that the document is not ready for
> standardization.  The rest of the German comment addresses very different
> fundamental concerns.  I do not intend to address these.
> 
> Second, I have two comments relative to the US/German/UK comments
> which I hope may be constructive:
> 
> (1) I strongly agree with UK comment 1 on the distinction between REAL 
> values that have no significant fractional part and exact INTEGERs.  
> (And I believe that Dr. Kahan would strongly agree with the UK position 
> that "real values should always be considered approximate", since he 
> wrote that in more than one paper.)
> 
> The problem with POWER and the C pow function, German comment 83 and a
> Major issue to the US, seems to me to be an insistence of X3J11/WG14 that 
> there must be a 1-to-1 mapping between C "pow" and LIA-2 "power_ff".  
> In fact, the C pow function is:
> 
> double pow(double x,y) := 
>     if y - int(y) = 0 then power_fi(x, int(y)) else power_ff(x, y) fi;
> 
> That is, there are two underlying LIA numerical functions and one 
> C-language convenience function that makes the difference invisible to the
> programmer.  Even in C/C++ libraries the underlying algorithms for
> power_fi and power_ff are separately coded and significantly different.
> LIA-2 defines the behavior of the underlying numerical functions power_fi 
> and power_ff and ISO 9899:199x can define "pow" in terms of the above 
> relationship.  I believe that recognition of this possibility should
> resolve this major technical complaint.
> 
> The US/German/WG14 comment 81 says: "The idea that an integer, just because 
> it is in floating-point format, is not an integer, needs to be removed."
> That is one spin, but let me put a bit of English on it myself:
> "The idea that a floating-point result should be treated as approximate
> even when it rounds to an integral value needs to be removed."
> The fact is that in general we cannot know at runtime whether a given 
> floating-point value is the image of an integer or the rounded result of 
> a computation.  What LIA-2 does is to define two functions -- one for
> the things which are really integers (regardless of representation)
> and the other for those which are really approximate.  It is up to the
> language to decide when to apply which one.
> 
> (2) Conversely, and for similar reasons, I disagree with UK comment 2.
> If it is important to distinguish true infinities from "overflows",
> then it is necessary to use distinct NaNs for "overflow values", and
> define the operations on them.  This might be a good idea, but it is not
> reflected in current practice.
> 
> By continuing a computation beyond an overflow, the programmer agrees to
> treat the resulting value as infinite.  LIA-2 should support exactly that 
> -- the result is treated as infinite, not as "overflow".  
> 
> So the logarithm of +inf is +inf, and arctan(+inf) is pi/2, etc., exactly
> as the US/German comments recommend.
> 
> The UK position that "poles created by divide by zero" are importantly
> different from infinities created by "accumulated values becoming too
> large" is inconsistent with their first comment.  Division by EXACT 0 
> produces an infinite result, while division by APPROXIMATE 0 produces an 
> indeterminate result.  LIA-2 should be consistent in this regard.  If 
> power does not treat the exponent as exact when it happens to be 
> integral, neither should division treat 0 as exact.  And if the
> programmer agrees to treat the indeterminate result as infinite, then 
> the above logic should also apply -- we treat it EXACTLY as if it were 
> infinite, without regard to where it came from.
> 
> Thus I agree with German comment 81.  (But I confess that I am at a loss
> to understand how a comment on an informative Annex can be Major.)
> 
> (BTW, I realize that an important part of standardization is to get
> agreement on common practice, not necessarily to get consistency among
> elements of the same standard.  But NONE of the comments from any of the
> national bodies argue that the problem with LIA-2 is its departure from
> common practice.  So I suggest consistency is no worse a rule for 
> resolving controversial provisions.)
> 
> -Ed
> 

<PRE>