Re: Discussion period started Re: Proposal of Motion 6, version 3
P1788 members
On 6 Aug 2009, at 00:00, Vincent Lefevre wrote:
On 2009-07-29 10:00:45 +0200, Arnold Neumaier wrote:
Jürgen Wolff v Gudenberg schrieb:
I think motion 6 will give a solid foundation of the standard
I agree that Motion 6 converged to something convincing.
(The criticism by Dominique Lohez that ± infinity are handled
as numbers seems to me unfounded; they occur only as bounds,
not as elements of intervals.)
Therefore, I recommend voting with yes.
I completely agree. But here are a few comments:
Page 3: "3.3.14. *interval function*, *interval mapping*. A function
from intervals to intervals is called an *interval function* if it is
an interval extension of a point function, and an *interval mapping*
otherwise."
As it is said, it seems that a function from intervals to intervals
is either an interval function or an interval mapping, while interval
mappings should include interval functions. I would replace this
definition by:
3.3.14. *interval function*, *interval mapping*. A function from
intervals to intervals is called an *interval mapping*. If it is
an interval extension of a point function, it is also called an
*interval function*.
OK. Arnold, who proposed this use of terms, agrees this is what he
intended. I will make this change.
Page 3, 3.3.17: "Mixed-format does not mean that the lower and upper
bounds of an individual interval can have different floating point
formats. The theory, as phrased here, precludes this."
But what about midrad? Having the midpoint and the radius in different
formats can be useful in multiple precision, for efficiency reasons.
I agree. But 3.5 says explicitly that the motion and rationale are
[currently says "is" - bad grammar]
incompatible with certain representations, e.g., with a finite
precision midrad (midpoint-radius) representation of intervals,
though there is nothing to stop an algorithm using this internally.
I prefer to leave the wording unchanged. An implementation can use
any midrad form it likes, but that is no part of this motion. I
personally think midrad standards shouldn't be part of P1788, but
that may well be the subject of a later motion.
Page 4: "Mixed-radix is less easy, as there is no one best way to do
the needed radix conversions. In my view it should not be considered."
Mixed-radix can still be implemented in "valid" accuracy mode, thanks
to implicit conversions.
Yes. I had in mind that P1788 is a _language-independent_ standard.
It seems to me that
- implicit conversions are a language-dependent matter;
- however, our expression-evaluation subgroup may well make
recommendations (non-normative) on this issue in due course.
My current wording is not ideal. Vincent, will you suggest an
improvement?
Page 6, 3.5.5: "An interval mapping is called an *interval function*
if it is an interval version of some point function, as defined next."
However the definition of interval function is self-referenced.
But I think this is because the wording is incorrect. It is said:
an *interval extension* of f, also called an *interval version*
of f, is any interval function *f* such that
^^^^^^^^^^^^^^^^^
It should be "[...] is any interval mapping *f* such that".
Yes, I will change this.
Page 6, 3.5.5: "Examples of interval mappings that are not interval
functions are the hull and intersection operations."
Why not the hull operation? Isn't it the sharp interval extension
of the identity function?
I meant the binary version, hull(aa,bb) = hull of (aa union bb). I
will clarify.
Page 6, 3.6.1: "An *abstract floating point format* (*af-format*) F
is a finite subset of R* containing −∞ and +∞."
I would have called it an "abstract discrete format". In particular,
it can correspond to a fixed-point format.
Ah yes. It can indeed correspond to a fixed-point format, so the word
"floating" in the name is misleading. But your "discrete" is not the
right term to contrast with "interval". Whether point or interval,
each set of level 2 datums is finite, so discrete. I think
- "floating point" should just be changed to "point" here.
- So af-format, cf-format should become ap-format, cp-format throughout.
Arnold, you helped harden up this part of the text. Any comments?
Page 7: "My view of the purpose of NaI is that it is like NaN in
floating point computation: if any operand to an operation is NaI,
the result is NaI."
In fact, it is like sNaN, but *not* like qNaN. For instance,
hypot(±∞, qNaN) is +∞.
And max(qNaN,3) is 3, etc. So 754 doesn't treat NaN quite
consistently. I suggest to change it to
"... : mostly, if any operand to an operation is NaI, the result
is NaI."
But this is a Motion 7 issue and I will comment there.
Best wishes
Dr John D Pryce
46 Ponting Street
Swindon
Wiltshire
SN1 2BW
+44 1793 327341