Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: M0030 -- Level 1 constructors

Vincent Lefevere wrote:

On 2011-12-03 11:41:05 +0000, Corliss, George wrote:

> E.g. text2interval("rubbish").

Hmmm.  Good question.

I THINK that at the LANGUAGE level, I'd like to raise an exception
so I cannot ignore the error. But that's not THIS standard.

Plan B: "Not an Interval". Empty is a valid interval, so returning
Empty is a lie. However, I understand your hesitation to introduce
"Not an Interval" at level 1.

I will listen with interest to the views of others.


I can see 3 solutions:

1. Introduce the notion of "Not an Interval" at Level 1.
  It would be an element of the set and could also be used
  as an input. It should be seen as an exception, that could
  potentially be trapped.

2. Introduce the notion of error at Level 1.
  Like (1), but this would not be an element of the set. The way(s)
  such an error could be handled should be specified at Level 2,
  possibly as implementation-defined (languages have their own way
  to deal with such errors). For instance, the empty set (with a
  decoration) could be generated.

3. Leave these cases unspecified at Level 1.

I would prefer (2), then (1).


Right.
Note that (1) and (2) don't necissarily need to be seen as mutually
exclusive, either. If the interval portion of the decorated interval
(Empty,ndf) you mention in (2) is thrown away by a forgetful operator
(either explicitly by the user or implicitly by some automatic conversion)
then the result is the bare decoration ndf, which by definition is "not an
interval" because it is not an element of overline-IR, the set of all
intervals.




On 2011-12-29 16:25:26 -0500, Lee Winter wrote:

To the extent that Level 1 is concerned witht he mathematical
propertiers of the system, math already has a concept of "undefined",
"error", or "invalid construction".  So representing those concepts in
Level 1 is appropriate.  Leaving them out is not appropriate.


Yes, I tend to agree.

Me too, FWIW.



> In the interest of moving forward and making progress, though, and
> since
> decorations are still yet to be settled (and controversial), I don't
> have
> any problem to say that for *bare intervals* an invalid construction
> simply
> returns Empty. This is what Motion 5 does, for example, which says that
> for
> bare intervals 1/[0,0] = Empty.

I disagree.  Hiding errors or potential errors) is not a venial sin
(in the von Neuman sense).  It is a mortal sin.


I am fine with Empty and don't see it as an error. One just has:

 f(X) = { f(x) | x in X and x in D(f) }

At least 1/[0,0] shouldn't be treated differently from sqrt([-0.01,17])
where the -0.01 could have been obtained due to rounding but would
have been 0 with an exact arithmetic. Decorations could be used to
detect potential errors.


That summarizes my view, as well.
More specifically, I believe Definition 7 in the attached paper can catch
the relevant potential errors. Possibly a decoration for unboundedness may
be added, although that seems complicated and I still haven't seen any
reason for it, e.g., a practical algorithm that would require information
about boundedness in a decoration to prove something that couldn't already
be proven with P1788's unbounded intervals. But if someone gave an example
I'd be interested to look at this closer.
Nate

Attachment: hayesdsm.pdf
Description: Adobe PDF document