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

Re: Motion 30, Constructors



On 01/10/2012 05:41 PM, John Pryce wrote:

(B) Constructing bare or decorated intervals?
---------------------------------------------
I regard decorations, in whatever eventual form, as solidly in Level 1. A reason to have them there is that then, an interval algorithm written at the mathematical level *may* (but doesn't have to) express exceptional behaviour in terms of decorations, thus making it easier to transcribe to executable code.

A second reason is that Level 2 is basically about implementable, finite precision, algorithms. The decorations we shall probably (IMO) choose, e.g. "everywhere defined", have meaning whether are not precision is finite. So why lump them in to Level 2? (Compare IEEE 754, where 3 of the 5 flags are essentially about finite precision.)

Then, a *decorated interval* constructor at Level 1 can handle failure (i.e., invalid data) with no bother -- we return some decorated object that indicates this, which we may choose to call NaI. It may come in more than one flavour.

However, failure of a *bare interval* constructor is what raised my question:
On 3 Dec 2011, at 09:12, John Pryce wrote:
When a constructor call "fails", should the call
(a) return Empty, as currently written;
(b) return a "Not an Interval" value, which must then exist at Level 1; or
(c) not return any value, i.e. the function is simply undefined at this input argument?
Another option, which Dan has favoured: Bare interval constructors don't exist, one can only construct decorated intervals.

The latter option, let us call it
   (d) Bare interval constructors don't exist
is the only safe option, since without it a naive user will be able to create unintended nonsense, and all the care coded into the decorations will be for nothing.

But there should be an operation bare(xx), that takes a decorated interval and extracts the undecorated part. Those who want to use undecorated intervals can then get it as bare(interval(a,b)), etc., thereby indicating that they are deliberately going beyond naive usage, with all the consequences that this entails.