Re: Promotion of bare decorations & comparisons
Nate
On 5 Jan 2013, at 21:06, Nathan T. Hayes wrote:
> Then it appears Motion 42 should be entirely tossed out, too, since it also
> invalidates many things P1788 previously agreed on in Motion 8:
I take your point, though I would say the theory of real numbers that underlies Motion 3 hasn't changed much since then, while we have learned a lot about decorations since Motion 8.
The basics of the motion 42 scheme come from discussions between you and Arnold Neumaier, with Arnold's slant on the conclusions. However, there are foundational differences between it and your scheme. A key statement is in 8.8.4 "Permitted combinations". I have to admit this was my idea:
(*)
> A decorated interval yy_dy shall always be such that yy \supseteq Rge(f|x) and p_dy(f,x) holds, for some (f,x) as in §8.8.2 -- informally, it must tell the truth about some conceivable evaluation of a function over a box.
I think it is definitely *not* the case for your system.
Hence, you have a wider set of possible combinations than I'm proposing. Here is a table of these combinations, in the Motion 42 scheme.
n (no) means forbidden.
y (yes) means allowed.
m (maybe) means not produced by normal evaluation of arithmetic
expressions, but may be by other means, e.g. by setDec.
yy
+----------------------------
| nonempty nonempty
dy | empty unbounded bounded
+----------------------------
ill | y m m
emp | y m m
trv | m y y
def | n y y
dac | n y y
com | n n y
Principle (*) derives from the original purpose of decorations as saying something about (f,xx) pairs. One can view "n" slots in the table in at least two ways:
(a) They would violate a basic principle, so must stay forbidden.
(b) They represent potentially useful encodings for other information, so let's use them.
My instinct is to prefer (a), because it's easier to ensure logical consistency that way. But I may be wrong. I originally thought that the "m" slots should remain forbidden, but Vincent Lefevre argued strongly for allowing them.
Nate, I should like to see a corresponding table for the scheme you propose, and any combinations that have special uses. In particular, how you report an invalid constructor call, since you don't use an "ill" decoration.
John Pryce