Re: Constructors motion 30 Version 2.
On 2012-02-06 13:31:21 +0000, John Pryce wrote:
> 1. I have become more convinced that *at Level 1* an operation, at
> input(s) where it does not have a natural value, should simply
> be undefined -- in a Level 1 algorithm "f is undefined at x"
> makes unambiguous sense. I think Vincent agrees, maybe others.
> Of course, at the implementation levels, a value must be
> returned.
Yes.
> 2. I agree with those (Arnold, Dan, ...) who say there should only
> be constructors of *decorated* intervals, not of bare intervals.
> This makes constructors secure by default, in the sense that if
> a programmer wants to discard a decoration that signals
> construction failure, they must do so *explicitly*.
I agree.
> 3. Any decorated interval resulting from construction failure I'll
> call a NaI. (Not "the NaI". I agree with Nate there may be
> various flavours.) For now, I assume the interval-part of any
> NaI is Empty, but that's a design decision, not an essential.
> I'm skeptical of arguments such as Vincent (2012 Jan 4)
> (a) ... if nums2interval(l,u) fails, i.e. in the case l > u
> or l = +oo or u = -oo, then { x in R | l <= x <= u } is still
> mathematically defined and is the empty set.
>
> The semantics might have been defined as
> (b) "the intersection of the reals with the smallest extended-real
> interval containing l & u",
> which makes nums2interval(3,2) = [2,3]. Or
> (c) alter "containing l & u" to "containing those of l & u that are
> extended-real numbers" (like 754's usage of max and min), which makes
> for instance, nums2interval(3,NaN) = [3,3].
>
> All of (a,b,c) are bad design IMO. Constructors should be
> maximally unforgiving, with the smallest domain in the Level 1
> sense (= set of "OK" inputs) needed to provide the desired
> facility. This makes it more likely programmers are forced to
> think about what they really want.
OK, perhaps a constructor error is safer.
> [E.g. suppose u decreases below l in nums2interval(l,u). In a Kaucher
> system that can be regarded as happening nice and continuously, but
> *not* in a set-based system. Does the programmer really want Empty in
> this case? A constructor error is best IMO.]
Actually it depends on the meaning/context of u and l. For instance,
the user may have computed an upper bound and a lower bound of some
result, and u < l basically means that the problem has no solutions,
in which case Empty is what one expects. However the user could do
l <= u ? nums2interval(l,u) : Empty.
> I seem to recall Arnold had interesting ideas on combating the
> problem of a programmer writing num2interval(0.1) when what's needed
> is text2interval("0.1"). Arnold, I've lost this, please remind me.
I'd say that num2interval(expr) should fail unless expr is evaluated
exactly (this notion being partly covered by IEEE 754), otherwise the
risk of bug would be too high, IMHO. And it is not allowed to fail if
expr is a literal that can be represented exactly.
--
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)