Re: Motion 42: NO
Le dimanche 10 février 2013 à 15:10 +0000, John Pryce a écrit :
> > - The motion states that "the final result is decorated com if and only
> > if the evaluation of the whole expression was common as defined in 5.4"
> > in Section 6.3. I understand the "only if" direction, but not the "if"
> > direction. Indeed, Section 5.4 deals with level 1 while 6.3 deals with
> > level 2, where overflow, precision, and so on, matter. I guess that the
> > fact the sentence uses "f" instead of "phi" is not unrelated to my
> > confusion.
> Actually the reference to 5.4 should be to 5.3 (penultimate paragraph) I think.
>
> You query "if (A) the evaluation of the whole expression was common as
> defined in 5.4, then (B) the final result is decorated com", right?
> But isn't the proof, both ways round, a purely graph-theory result of
> the propagation rule for decorations, with no real-analysis content?
Sorry, you have lost me. I was under the impression that f designated a
level-1 function while phi designated a level-2 function. Since phi
produces wider intervals than f due to the reduced precision, I don't
understand how the fact that all the intervals for f are bounded implies
that all the intervals for phi are bounded.
> > - I miss the point of the ill decoration as defined in Section 8.8.2,
> > since it is undecidable whether Dom(f) is empty for an arbitrary
> > real-valued function f ... Section
> It's equally undecidable whether *f is everywhere defined* on a given
> box, but I don't see you complaining about the "def" decoration on
> that account!
Sure, both of them are undecidable, but there is a major difference
between the two of them. For all the arithmetic and elementary functions
provided by the standard (+, *, /, sqrt, exp, sin, and so on), we will
mandate when they shall return "trv", "def", or "dac". Implementations
will not have any leeway.
But the empty-domain principle for "ill" will never apply to any part of
the standard nor will it ever matter for implementers. My point is that,
if this principle cannot be applied to the standard, there is definitely
something useless about it. Can you give even one example of a function
for which the standard will mandate to output "ill" while none of the
inputs were "ill"?
Note that I do not consider NaN to be an acceptable answer. Obviously,
we have a disagreement here since you think it is a fine function. But I
strongly believe that the standard should be kept simple and that
calling NaN a function with an empty domain does not achieve that goal.
> That's the maths. In addition there is a practical design decision:
> (*)
> At Level 2, an interval constructor always has to return
> *something*, i.e. a datum of the relevant interval type.
>
> - Therefore a failed constructor call such as
> text2interval("garbage")
> (of some decorated interval type DT) must return a DT-datum.
> - Which datum? The DT version of NaI seems a natural choice.
A constructor taking two numbers as inputs is not the extension of a
point-wise function, so whichever decoration is chosen (and I agree
"ill" is the correct choice for broken inputs) does not constitute an
argument in favor of a mathematical definition.
> This scheme looks pretty coherent to me. IMO, any contradictions that
> Nate or anyone else sees in it are due to making a mixture of Nate's
> definitions and assumptions with those of Motion 42. If anyone claims
> to have a contradiction, let's see the details.
Note that I did not say that the definition of "ill" was incoherent. I
said that defining "ill" as meaning that a point-wise function has an
empty domain is useless from the point of view of the standard.
> Further, anyone who thinks NaI should not exist: what do you propose to do about (*)?
I didn't say either that NaI should not exist. I am all for it and for
its propagation from input to output (Section 8.8.3). Again, what I am
saying is that trying to find a mathematical justification for NaI
(Section 8.8.2) is pointless since it will have no bearing on the
standard except for obfuscating it.
Best regards,
Guillaume