|
Well said on both counts, Richard.
Cheers,
Bill
On 7/15/13 1:32 PM, Richard Fateman wrote:
I sent my votes (yes, yes) to
George Corliss, expressing some reservations. He suggested
I record the reservations. Here they are.
Regarding interval literals, I vote yes in the interest of no
longer discussing this matter.
In reality I feel that the only numbers necessary for defining
an interval are those scalar numbers
that can be expressed in the host language as input and as
output. If there are numbers
that one wishes to express for purposes of defining interval
endpoints that cannot be expressed
(input, output, storage) in the host language except as
character strings,
then that language is simply unsuitable for interval arithmetic.
I would prefer that interval literals and the complications
revolving around them simply be
struck from the standard especially given the complexity of this
material.
This does not seem to be a popular opinion, and so my reaction
is basically, eh, if you insist that you need it.
I would not use it or implement it.
............
Regarding exact dot product, there are many pieces of
information offered which appear to me
to be irrelevant, like the fact that it can be implemented in
hardware (or not), and is it a good idea for numerical
computation generally.
The question appears to me to be
Is it something that, absent inclusion in a P1788 standard,
would be done in different ways that would cause confusion in
the application of interval arithmetic.
I think the answer to that is: NO. So it should not be
required. Should it be recommended?
If the implementation of interval arithmetic is conveniently and
economically phrased in terms of EDP as
provided or implemented in the language of the implementation,
then implementors would be wise to use it.
It could be a recommended technique. However, if interval
arithmetic is implemented to the same specification but happens
not to use EDP, there is no fault, and therefore no need to
REQUIRE EDP.
Furthermore, counting against requirement:
adding a functionality which has neither interval inputs nor
interval outputs and appears to require
a data object (extended accumulator) not otherwise present in
the standard, seems gratuitous in the
context of an interval standard.
My vote is to make it NOT required. My preference would be to
relegate it to a suggestion for
implementation technique.
Richard Fateman
|