Re: Motion: Number format
On 2012-04-12 01:28:55 -0700, Dmitry Nadezhin wrote:
> I will ask a stupid question but I really don't surely understand
> what does this motion regulate.
> The P1788 is interval standard, so it can't make requirement
> on underlying number formats.
I partly agree. I agree that it can't make requirement on operations
of numbers only, but since P1788 specifies:
* operations where numbers are involved (together with intervals),
* inf-sup interval types (actually numbers will appear explictly
in constructors, that are operations mentioned in the point
above),
it should say something about the numbers, in particular those
that are explicitly used in P1788. For instance, inf(Entire) and
sup(Entire) need to return -oo and +oo respectively (any finite
number would be an incorrect answer).
> It only can regulate interaction of interval library with
> existing number formats in underlying system.
An implementation would have to create a new number format if need be,
in order to be able to implement some operations specified by P1788.
Or perhaps make the number format optional, but this would mean that
all the operations involving numbers would no longer be defined by
the standard with such an implementation.
> The underlying system may have a few number formats,
> some of them satisfy the requirements on F from them motion, some don't .
>
> For example, on Java platform types "float" and "double" satisfy
> the definition below as they are 754 formats.
> Types "int" and "BigDecimal" don't satisfy because they don't contain special
> datum -oo, +oo, NaN .
This means that "int" and "BigDecimal" could not be used as number
formats. An implementation would still be free to define operations
with such types, but this would be an extension, not in the scope
of P1788.
Perhaps one could define the notion of input number format, where the
only requirement would be a mapping from the numbers to Rbar U { NaN }.
But one should have somthing like: at least a full number format should
be supported for all operations associated with the interval type T.
> Some interval library implements class Interval with float/double/int/BigDecimal constructors and numeric functions.
> class Interval {
> Interval(float u, float v) {...}
> Interval(double u, double v) {...}
> Interval(int u, int v) {...}
> Interval(BigDecimal u, BigDecimal v) {...}
>
> float mid_float() {...}
> double mid_double() {...}
> int mid_int() {...}
> BigDecimal mid_bigDecimal() {...}
> }
>
> Then what does the motion require from the class Interval ?
>
> a) "Interval" must have either float or double constructor and
> it must have either float or double version of "mid".
> The properties of the constructor and of the "mid" version are regulated by P1788.
> "Interval" can't have int/BigDecimal versions of constructor and "mid".
>
> b) "Interval" must have float/double constructor and float/double version of mid.
> Their properties are regulated by P1788.
> "Interval" may have int/BigDecimal constructors/numeric functions,
> but it doesn't specify their properties.
>
> c) "Interval" must have float/double constructor and float/double version of mid.
> Their properties are regulated by P1788.
> "Interval" may have int/BigDecimal constructors/numeric functions,
> and their properties are regulated by P1788 too.
The implementation could choose which constructors are covered by
P1788 (there must be at least one).
But the goal of this motion is to define what is a number format,
not to say what is required w.r.t. the operations and the interval
types (this should be later motions). For instance, defining
Interval(int u, int v) as the only constructor would not be allowed.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)