Re: Amendments to Motion 6, version 3
Vincent, Arnold, P1788 members
On 8 Aug 2009, at 19:40, Vincent Lefevre wrote:
(Vincent's proposed new wording on MRMF):
Mixed-radix should be supported and an elementary function should
return an interval at least as tight as if the following operations
were done: each input is converted into the destination format, then
the single-format elementary function is applied on the converted
inputs.
(John's comment):
This proposition by Vincent really belongs in the motion (and thus
specifies something about the standard-text) rather than in the
rationale.
Should it be part of the motion?
I think so.
On thinking this over, I cannot agree. I believe P1788's remit is to
provide elementary operations _below_ the language level that offer,
as far as possible, clean and efficient implementation of an interval
system at language level on various architectures -- whether done as
a library or within an interval-aware compiler or language.
Suppose I am converting the C++ package PROFIL/BIAS to be P1788
compliant. Suppose the underlying system is 754-2008 conforming and
provides the five basic formats b32, b64, b128, d64, d128. As argued
in the motion 6 rationale, then providing SRMF support in several
formats as motion 6 currently requires, seems to require relatively
trivial code changes: basically templating the floating point format
in a slightly more systematic way than at present, and instantiating
the code for each of the 5 formats. Then 754's "formatOf" operations
should do the rest automatically. There only needs to be one copy of
the code for, say, the BIAS operation AddIR "add interval to real".
But providing MRMF support as Vincent proposes seems to require a
massive increase in the number of versions of operations. Because
"formatOf" doesn't apply for mixed-radix, I would need AddIRbinary
(decimal, binary), AddIRbinary(binary, decimal), AddIRdecimal
(decimal, binary), AddIRdecimal(binary, decimal), ... Hopefully
"formatOf" in the coding could avoid having separate code for each
(decimal format), (binary format) operand combination, but if it
doesn't, the situation becomes *far* worse.
I have not tried to do this, and I don't know to what extent
"formatOf" is actually supported on current 754 systems, so maybe it
can't yet be tried.
And what would be the advantage of adding MRMF to P1788's basic
operations? I think MRMF belongs better at the language level.
Providing AddIR(decimal, binary), etc., is more easily done in an
interval-aware compiler than in a library. The compiler is best
placed to insert code for any needed format conversion of operands
before doing the operation.
I think the standard needs a section on "Interval expression
evaluation" analogous to 754 section 10. I _would_ support Vincent's
proposed wording going in there, whether as
- A P1788-conforming language _shall_ provide MRMF support such
that ...; or
- If a language provides MRMF support, then it _shall_ ...; or
- A language _should_ provide MRMF support such that ...
or whatever, to be decided.
I am not an expert on compilers, or on the capabilities of C++
templating, so it is possible that I have written nonsense -- please
put me right.
Best wishes
John Pryce