Re: Motion 54 -- Level 2, Clauses 12.1-12.9
Michel, P1788
I'm playing catch-up, partly because Cardiff switched to a new email system. I only just got my laptop's Mail program re-configured, and some 70 messages flooded in. So I hope the Chair will forgive some minor changes being made to the text while voting is in progress.
On 2013 Nov 25, at 01:39, Michel Hack wrote:
> 12.1.3, Exception behaviour:
>
> "... a Level 2 operation always returns a value".
>
> Is this not a bit too strong? Are we ruling out implementations
> with unconditional exceptions that simply terminate the program?
>
> One way of looking at this is by applying the "observability" rule.
> If a program is terminated, it cannot observe the fact that the last
> operation did not return, so the point is moot.
That is roughly what I was thinking. I hope the text can be left unchanged.
> "...exceptions that may be signaled, causing a handler to be invoked."
>
> Somewhere we should say that the standard will not say much about
> how exceptions are handled, though perhaps an appendix can list some
> possibilities. The issues are whether the handler can return in-line
> with a substitute result, or whether it terminates some program unit
> like a C longjump, or perhaps terminates the program entirely. Also
> relevant is what information the handler may get: operation name and
> arguments, or perhaps a representation of the result in a different
> type that can express what the intended result type cannot. Such an
> exceptional-result type need not be a computational type; it could for
> example be something that describes which bound overflowed, or even by
> how much (754 has used wrapped exponents, scale factors, or wider types
> for this, for example).
Isn't this entirely outside the remit of 1788? It's an issue of language binding surely?
> Missing (though perhaps still under discussion): ContainmentFailure,
> for flavors that only have a partial hull operation.
Yes, will be added if Flavors motion 61 passes.
> 12.4, paragraph following the set of F-rules, typo:
> "possible +-0" -> "possibly +-0"
Either seems good, but changed.
> 12.5.1, near top of page 48:
> "Two types are comparable if either is wider than the other."
> "either" -> "one"
Dictionary says "either" = "one or the other of two people or things" so I think it's more correct than "one". Massachusetts railway fell into a different trap.
>
> Next paragraph, identification of NaI with (Empty, ill) is something
> that may need attention -- throughout the document.
Yes. I believe Ned is working on this with Wolfram Kahl. I still believe it is a valid identification at the level of formal logic, but we'll see.
> 12.6.2, bottom of page 48, mixed-type operations. As Vincent pointed
> out, the double-rounding problem addressed by 754-2008 is not an issue
> for directed rounding, and hence may not be an issue for inf-sup types.
> So I suggest adding:
>
> For inf-sup types this requirement may be met by implicit widening
> of inputs to a common widest format, as double rounding is not an
> issue for directed rounding.
Added as a Note, at end of 12.6.2.
John Pryce