Re: Motions 54, 55, 56, 57: YES

[Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>]

Guillaume,

> We don't need T-hull for debugging and reproducibility. A simple 
> sentence such as "Given the same inputs, operations at level 2 shall 
> always return the same outputs" would be sufficient for that purpose. 
> Knowing that there exists some theoretical T-hull function does not 
> bring any additional help for debugging purpose.

I think that the reproducibility is
reproducibility among different independent implementations
of a certain definition of implicit type T.

For example, some may define T=midrad_F with
T-hull(x)=(mid(x),rad(x)).
Here x is a level 1 set-based interval.
mid(x) and rad(x) - are Level 2 definitions from current P1788.
Then there may be a few independent conforming implementations of T.
Their basic operations return T-hull of exact result.
add_T(x,y) = T-hull(add(x,y))
div_T(x,y) = T-hull(div(x,y))

> You might have missed my point. I am not saying that it is not possible 
> to design a div function that returns a T-hull. What I am saying is that 
> it is might be impossible to design some add, sub, mul, div, sqrt, fma, 
> conversion functions that share the same T-hull function. The important 
> word here is "share".

It is possible to implement basic 6 operations that
return shared T-hull (for example, T-hull above) of exact result
though this requirement might force to inefficient implementation.

For example, for division 
(mx,rx) / (my,ry) with mx-rx > 0 and my-ry > 0
we must compute correctly-rounded
M=roundNear(((mx-rx)/(my+ry) + (mx+rx)/(my-ry))/2) = roundNear((mx*my+rx*ry)/(my*my-ry*ry)).
This can be done in multiple-precision.
So required reproducible version of division might be slow.

A fast version of division might consider M = roundNear(mx/my),
though sometimes this is not T-hull.

> Indeed, as currently worded, the document forces all the functions to 
> use the same definition of T-hull (rather than one per operation, for 
> instance). Do you (or anyone else) know of a mid-rad library that 
> guarantees this property?

It is possible that nobody knows how to find T-hull(pow(x,y)),
but this is not required. This document forces an implementation
to have tightest version of basic operations, but it doesn't force to
have tightest version of transdential opoerations like cospi or pow.

  -Dima


----- Исходное сообщение -----
От: guillaume.melquiond@xxxxxxxx
Кому: stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Среда, 1 Январь 2014 г 11:38:23 GMT +04:00 Абу-Даби, Маскат
Тема: Re: Motions 54, 55, 56, 57: YES

On 01/01/2014 06:21, Dmitry Nadezhin wrote:

> My understanding is that the purpose of a particular choice of T-hull
> among different minimal enclosure in implicit types was for debugging and for reproducibility.

We don't need T-hull for debugging and reproducibility. A simple 
sentence such as "Given the same inputs, operations at level 2 shall 
always return the same outputs" would be sufficient for that purpose. 
Knowing that there exists some theoretical T-hull function does not 
bring any additional help for debugging purpose.

> The tightest accuracy mode is required only for basic operations (add,sub,mul,div,sqrt,fma)
> and for some other "easy" operations.
> For other operations like "cospi", only valid accuracy mode required.
> It seems that there is no even a requirement that valid result must contain T-hull of
> exact result. It may be another minimul enclosure or non-minimal enclosure.
> Hence, it is possible to design a conforming implementation.

You might have missed my point. I am not saying that it is not possible 
to design a div function that returns a T-hull. What I am saying is that 
it is might be impossible to design some add, sub, mul, div, sqrt, fma, 
conversion functions that share the same T-hull function. The important 
word here is "share".

Indeed, as currently worded, the document forces all the functions to 
use the same definition of T-hull (rather than one per operation, for 
instance). Do you (or anyone else) know of a mid-rad library that 
guarantees this property?

Best regards,

Guillaume