Re: Amendments to Motion 6, version 3

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2009-08-10 09:39:41 +0100, John Pryce wrote:
> 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.

With SRMF, the language would still have to implement the "formatOf"
operations in a generic way, and if it doesn't (some languages, such
as C, cannot), the software developer needs to do this himself. So,
this isn't much different, except that there are more possibilities.

Here with C++, can't you use generic types in order to write a
single function AddIR, actually two, one that uses formatOf (to
have a single rounding) and one that does a conversion of its
inputs first (used if formatOf is not available for the types)?

Also note that I suggested MRMF to be only a recommendation.

> 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.

Not every one can use an interval-aware compiler, and really such
things shouldn't matter for P1788. Also, the whole point is to have
such operations standardized. Then how this is implemented (e.g. by
a language) and the API spec would be at the language level.

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)