Re: Motion 30, Constructors
Dear P1788
I'm hopefully getting back to work after a bug that has laid me low for two weeks. I asked Baker to defer the voting period a bit. Here are comments on some of the discussion on this motion.
(A) Status of modal (Kaucher) intervals
---------------------------------------
I know some people would like the standard to have no provision for modal intervals, but they ARE of commercial significance as Sunfish's applications show, and deserve respect. Strategically, I continue to believe that they should be an optional extra, and that a natural place for their specification is in an Annex (appendix) labeled as "informative".
I think they should have the same status as the Recommended Arithmetic Operations, and any other specification in P1788 that we call "informative". I believe this is:
- A conforming implementation needn't implement this feature.
- If it does, it needn't do so exactly as described.
- But it's probably dumb, NOT to do it exactly as described.
We COULD invent some other status, such as "you don't have to implement this, but if you do it as described, your implementation conforms to P1788-PLUS" (or whatever). By the Occam's Razor principle -- an aspect of K.I.S.S. -- I prefer not to do such things, or not till we reach a final tidying up phase of P1788. Dan Zuras, can you advise?
Alexandre Goldsztejn may be preparing a "modals: in or out?" motion, which would help settle this.
(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.
I don't really agree with those (George I think; Arnold has said similar) who say it must be (a) on the grounds that
The returned interval must be "the set of real x such that some
condition holds". In the case of failure there are no such x, so
the result must be the empty set.
That's a design decision, not a "must be". Some constructor calls -- certainly text2interval("*£$?!") and possibly nums2interval(3,NaN) -- are surely meaningless rather than specifying the empty set?
My case for (c) instead of (b) is basically Occam's razor again. If we insist a failed constructor call must return a NaI value, why are we happy that a failed point-elementary-function call, such as sqrt(x) with x<0, is simply "undefined" instead of returning NaN? (Recall this is all at Level 1.)
Let's be consistent, in order to make the text of Level 1 simpler.
Lee Winter: you argued against this, but I felt you objected to my wordy math reasoning rather than to the conclusion. Suppose one just says there is a boolean test: at Level 1, a function is either defined at a point, or not; if defined, it has a unique value there, otherwise it's, well, undefined. At Level 2 onward, "undefined" translates to returning some value that indicates this. Do you still object that this obscures things for the user or implementer?
Personally I am fairly easy between (b) and (c), but increasingly dislike (a).
(C) text2interval?
------------------
On 3 Dec 2011, at 17:41, Michel Hack wrote:
> As for John's question about text2interval("rubbish"): As long as text
> strings are not Level 1 objects (which I believe is the case so far),
> this does not belong here, so the point is moot. But excluding text
> intervals removes the possibility of specifying intervals containing
> exact numbers, and yet those can only be specified at level 1, so I
> think we have to add "text strings representing level 1 intervals"
> as a level 1 type. But once we do that we get to the sad fact that
> it is in principle undecidable whether a text string represents an
> interval (at level 1; at level 2 we can specify a syntax that, if
> sufficiently restrictive, can avoid that problem).
Good points. Well, strings shouldn't be forbidden just because we forgot to say they are Level 1 objects. Let's say so now, and I'll add it to the draft Level 1 text.
As for the syntax, you are right that at Level 1 one can write silly things like
text2interval("The widest finite interval [-x,x] that can be described in at most 80 characters")
I don't think we should get hung up on that. My sentence in the motion
> Since Level 1 is mainly for human-human communication, any
> understandable t is acceptable, e.g. "[3.1,4.2]" or "[2\pi,\infty]”.
could be improved, e.g. to say the writer of an algorithm is requested to specify informally what an acceptable text string is.
(D) Summary
-----------
The motion specifies three bare interval constructors, and their argument lists. If anyone sees more that seem essential at Level 1, now is the time to say.
I *expect* each bare interval constructor will have a corresponding decorated interval constructor, which will give a default decoration depending on the interval. But that decision must wait.
Whether modal intervals are included in an annex as per (A) above, or excluded, doesn't affect this motion as far as I can see.
As for (B) above, should we have a separate motion, or an amendment to this one, making the choice between my options (a) to (c)?
This motion does NOT exclude the possibility that we follow Dan's lead and only support decorated interval constructors, which may make the above choice moot.
I shall offer revised wording of the motion in a few days, to reflect discussion on points (A) to (C) above and any others in this thread. Please look out for important points I may have missed.
Regards
John Pryce