Re: M0020.01 Comparing comparisons NO
Vladik, John, p1788
I completely agree with the fact that the set of interval comparisons
must be slim.
However it is not enough to state that to be conformant to the
Standard some interval comparison must be provided.
It must be stated in the standard that
NO ADDITIONAL COMPARISON MAY BE PROVIDED.
Otherwise you may be sure that some vendor will add some "very
convenient" comparison. Good reason may be found easily since at least
three or four "slimmest"
sets of comparisons have been proposed to the p1788 group.
I am reluctant forbid that way.
I had rather to make mandatory the use of some framework which prevent
unwanted addition.
Such a framework could to the definition of the BRA of Interval
Comparisons.
The overlap of motion 21 introduces also such a framework.
Best regards,
Dominique
Kreinovich, Vladik a écrit :
I vote NO, for the same reason.
-----Original Message-----
From: stds-1788@xxxxxxxx [mailto:stds-1788@xxxxxxxx] On Behalf Of John Pryce
Sent: Monday, September 20, 2010 3:36 AM
To: stds-1788
Subject: M0020.01 Comparing comparisons NO
I forgot to give my reasons to vote NO on Dominique Lohez's "frameWorkForComparisonRelations" paper.
As a pure mathematician, I like its contents a lot. As a mathematician trying to do software engineering, I think it goes beyond what anyone writing practical interval software needs.
- Arnold says he only ever needed 3 comparisons.
- Baker concurs, though admitting his applications were similar to Arnold's.
- Someone said the Kulisch <= is used in branch-and-bound to rank candidates: that makes 4.
No one else has offered evidence of uses in actual interval code. So for sake of KISS I vote against.
John Pryce
--
Dr Dominique LOHEZ
ISEN
41, Bd Vauban
F59046 LILLE
France
Phone : +33 (0)3 20 30 40 71
Email: Dominique.Lohez@xxxxxxx