Re: Motion 57 and decoratedEqual
Vincent,
Here is the history of "decoratedEqual":
This function appeared to fix former definition of "equal(xx,yy)".
Its decorated version compared both interval part and decoration part.
This violated principle, formulated in Section 6.4 .
"The standard requires that at Level 2, for all interval types, all operations and all inputs other
than NaI, the interval part of a decorated interval operation equal the corresponding bare interval
operation."
equal([2,3]_com, [2,3]_trv) = false != true = equal([2,3], [2,3]) .
This was repaired when we say that decorated "equal" doesn't take into account
decoration parts of its arguments (ecxept NaI).
equal([2,3]_com, [2,3]_trv) = true = equal([2,3], [2,3]) .
The former decorated version of "equal" was moved to a new operation
"decoratedEqual" with only decorated version.
I don't insist that "decoratedEqual" is a required operation.
It's Ok for me if it is dropped or is moved to recommended operations.
-Dima
----- Исходное сообщение -----
От: vincent@xxxxxxxxxx
Кому: stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Среда, 20 Ноябрь 2013 г 5:04:09 GMT +04:00 Абу-Даби, Маскат
Тема: Motion 57 and decoratedEqual
The decoratedEqual operation has been introduced in Motion 57.
I wonder whether this operation would be useful in practice: Is there
any application that would need this operation, i.e. need to detect
whether both the interval parts and the decoration parts are equal
except for NaI?
Note that if you want to check whether two results are the same (e.g.
computed by different, but equivalent algorithms), you would need a
true result on (NaI,NaI), contrary to what decoratedEqual gives.
If there isn't any practical use, I don't think it should be kept in
the standard.
--
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)