| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788 Motions 52, 54, 55, 56, and 57 all PASS Motion 52 - Clause 6 Expressions and the functions they define Yes - 40; No - 0; Needed for quorum - 30 Motion 54 - Std subclauses 12.1 - 12.9 Yes - 42; No - 0; Needed for quorum - 30 Motion 55 - Std subclauses 12.10 & 12.13 Yes - 42; No - 0; Needed for quorum - 30 Motion 56 - Std subclauses 12.12 intro &12.121-12.127 Yes - 42; No - 0; Needed for quorum - 30 Motion 57 - Std subclauses 12.12.8-12.12.13 Yes - 42; No - 0; Needed for quorum - 30 Voting currently is open through Monday, 6 January, on Motion 59 - Section 14 Level 3 description Current Tally: Yes - 32; No - 0; Needed for quorum - 30 PLEASE VOTE Motion 61 is under discussion. A digest of comments is below. George Corliss, P1788 Voting Tabulator Begin forwarded message: > From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx> > Subject: Four motions: Motions P1788/M0054:12.1-12.9, P1788/M0055:12.10&12.13, P1788/M0056:12.12intro&12.121-12.127, and P1788/M0057:12.12.8-12.12.13 -- voting period begins > Date: December 5, 2013 at 8:11:57 AM CST > To: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx> > Reply-To: <rbk@xxxxxxxxxxxxx> > > P-1788: > > The voting period for these four motions herewith begins. > The voting will proceed according to the rule for standard text > motions. > > You may cast your vote in one email, but please make it clear > what your vote is on each of the four motions. > > John will post final copies of the text for these motions, including > any minor changes, within 24 hours. > > Voting will continue until after Thursday, December 26. > > Thus, we how have these four motions under vote, as well as > Motion 61 (revised flavors) under discussion. Juergen will > update the on-line list as soon as he gets a chance. Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxx> > Subject: Re: Motion 54 -- Level 2, Clauses 12.1-12.9 > Date: December 6, 2013 at 1:55:48 AM CST > To: Michel Hack <mhack@xxxxxxx> > Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > 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 Begin forwarded message: > From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx> > Subject: Re: Motion 54 -- Level 2, Clauses 12.1-12.9 > Date: December 6, 2013 at 9:20:56 AM CST > To: John Pryce <j.d.pryce@xxxxxxxxxx>, Michel Hack <mhack@xxxxxxx> > Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > John, P-1788, > > On 12/06/2013 01:55 AM, John Pryce wrote: >> 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. > > Yes. I'll make sure people who have already voted will have > a sufficient opportunity to object if they are not in agreement > with the changes made. (I don't think people will object if it's > just a matter of crossing t's and dotting i's.) > > Best regards, > > Baker > Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxx> > Subject: Re: Motion 57 and decoratedEqual > Date: December 9, 2013 at 1:47:27 AM CST > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > P1788 > On 2013 Nov 20, at 01:00, Vincent Lefevre wrote: >> The decoratedEqual operation has been introduced in Motion 57. >> >> I wonder whether this operation would be useful in practice: >> ... > After a brief discussion in which Dmitry saw no strong reason to keep it, this operation has been removed. > John Pryce Begin forwarded message: > From: Richard Fateman <fateman@xxxxxxxxxxxx> > Subject: yes on 52 > Date: December 12, 2013 at 10:33:36 PM CST > To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx> > Reply-To: <fateman@xxxxxxxxxxxx> > > ok, 52 yes also. > > I'm not particularly keen on the complication of the proposal, > but as a definite latecomer to the process I don't > want to re-open discussion unnecessarily. > > The Christmas season seems to have caught me > unawares this year... > > Regards > RJF > > Begin forwarded message: > From: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx> > Subject: Re: PLEASE VOTE: Motion P1788/M0052 Clause 6 Text YES > Date: December 13, 2013 at 1:09:06 AM CST > To: <stds-1788@xxxxxxxxxxxxxxxxx> > > My vote is YES, > though the attached PDF is not the latest text from the repository. > > The text in the repository contains the exemption of NaI in subsection 6.4: > "The standard requires that at Level 2, for all interval types, all operations and all inputs other > than NaI, . . .". > So I beleive that the attached PDF is a little old and I vote for the text from the repository. > > -Dima Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxx> > Subject: Re: PLEASE VOTE: Motion P1788/M0052 Clause 6 Text YES > Date: December 13, 2013 at 1:46:18 AM CST > To: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx> > Cc: <stds-1788@xxxxxxxxxxxxxxxxx> > > P1788 > > On 2013 Dec 13, at 07:09, Dmitry Nadezhin wrote: >> My vote is YES, >> though the attached PDF is not the latest text from the repository. >> >> The text in the repository contains the exemption of NaI in subsection 6.4: >> "The standard requires that at Level 2, for all interval types, all operations and all inputs other than NaI, . . .". > Dmitry is right. When I have made changes (hopefully minor) during this voting period I have said that they have been done, and updated the repository, but not always circulated an updated PDF. > > I just updated the repository with suggested changes to Level 3 interchange format text: > - how endianness is mentioned; > - example that only representative of [0,0] is the pair (-0,+0). > > Maybe I should circulate current version of the complete document in a day or so? > > John Pryce Begin forwarded message: > From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx> > Subject: Motion P1788/M0052:Clause6Text (expressions) -- voting period begins > Date: November 30, 2013 at 6:22:52 AM CST > To: John Pryce <j.d.pryce@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Cc: Ralph Baker Kearfott <rbk@xxxxxxxxxxxxx> > Reply-To: <rbk@xxxxxxxxxxxxx> > > P-1788: > > The voting period for Motion 52 (latest revision > attached) herewith begins. > > Voting will continue until after Saturday, December 14. > Voting will proceed according to the rules for standard text > motions. > > Juergen: Please update the document and the corresponding > list of motions on the web site. > > Best regards, > > Baker > > On 11/28/2013 07:30 AM, John Pryce wrote: >> P1788 >> >> Questions such as >> >> - How much should the standard say about what an expression is? >> - What requirements, if any, should such text contain? Or should >> it consist purely of description and definition? >> - Should it be in the main standard or an annex? >> >> are important and have proved to be subtle and contentious. > The attached text of Clause 6 has benefited from careful scrutiny and > discussion, mainly by Dmitry, Michel and Vincent. No doubt it is not > perfect, but one must stop somewhere. >> >> The most significant change is an Oops! item. The definitions of > arithmetic operation and arithmetic expression had got lost from the > text at some stage. These are now in §6. That implies they apply to > all flavors, but they have flavor-defined aspects. >> >> There are minor changes to the definition of an expression. > Also to the descriptions of three alternative forms, to make them > more equivalent: e.g. to mention multiple vs single output > (vector vs scalar) for each of them. >> >> In 6.4 a phrase "other than NaI" is inserted. This issue remains > contentious. It relates to the "does NaI have an interval part?" question, > is being discussed separately from this motion, and may conceivably lead to > changes to 6.4 in due course. >> >> Chair, please will you start the vote on this text? > Webmaster, please update the web page. >> >> Regards >> >> John Pryce >> >> > > > -- > > --------------------------------------------------------------- > R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax) > (337) 482-5270 (work) (337) 993-1827 (home) > URL: http://interval.louisiana.edu/kearfott.html > Department of Mathematics, University of Louisiana at Lafayette > (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street) > Box 4-1010, Lafayette, LA 70504-1010, USA > ---------------------------------------------------------------
Attachment:
20131128Clause6Expressions.pdf
Description: Adobe PDF document
>
>
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
> Subject: Motion P1788/M0052 Clause 6 Text -- voting period EXTENDED
> Date: December 13, 2013 at 10:25:33 AM CST
> To: "Kreinovich, Vladik" <vladik@xxxxxxxx>, Vincent Lefevre <vincent@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
>
> P-1788,
>
> Due to confusion and mixed signals, the voting period for
> Motion 52 will not be restarted, but will be extended
> until December 26.
>
> Best regards,
>
> Baker
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Subject: Re: Motion 56 -- Level 2, Clauses 12.12.1-12.12.7
> Date: December 11, 2013 at 11:41:27 AM CST
> To: Michel Hack <mhack@xxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Michel, P1788
>
> I'm still playing catchup with emails, so I ask you again to excuse my breaching our procedures, at least technically, by making changes to the text while voting is in progress. I only do it if it is minor and there seems to be consensus.
>
> Here is a matter I'm unsure about:
>
> On 2013 Nov 25, at 04:48, Michel Hack wrote:
>> 12.12 intro, bottom of page 54 (P1788/D8.1 of Nov 15): As I pointed out
>> for 12.6.2 already, we don't need explicit mixed-type operations for
>> inf-sup types -- and 754-conforming types *are* inf-sup types.
>
> I feel this is wrong, but I defer to our experts on language binding issues.
> Using ib64 as short for the inf-sup binary64 type, etc., suppose a programmer writes an interval operation such as
> zz_ib64 = xx_ib32 op yy_ib128 (*)
>
> where "op" is one of the operations required to have "tightest" accuracy. As Vincent & Michel say, double-rounding isn't a problem for directed rounding, so the required effect is got *if* the program actually does
> 1. convert xx_ib32 to xx_ib128 (no error at this step),
> 2. do "op" in ib128 precision, returning zz_ib128,
> 3. take the ib64 hull of this to get the answer.
>
> But what's to say a given language will make this happen automatically?
> - (*) might cause an error at compile time.
> - Or, if a language *does* have rules that do this sort of automatic coercion for library datatypes (as well as native datatypes) what's to say they are the right rules? E.g., in (*) the default might be to coerce all inputs to the destination type ib64, and I don't think this guarantees the "tightest" result.
>
> So it seems to me the standard *needs* to make requirements about mixed-type operations. I've already inserted Michel's wording (**) below, end of 12.6.
>
>> I'll have to think about mid-rad types based on 754 arithmetic...
>> ... I conclude that we don't need this paragraph about mixed-type operations.
> If my point, above, is valid, it would apply to other types besides inf-sup.
>
>> 12.12.6, last paragraph (2nd bullet in Note, middl eof page 56):
>>
>> "An implementation should not, and for an inf-sup type need not, ..."
>>
>> Although "should not" is standard standard-speak, I don't get the
>> implication of "need not". I do understand the motivation.
>
> Ah. My point is that if a Level 2 result of cancelMinus, in an inf-sup type, overflows, it can only do so one-sidedly, i.e. the tightest Level 1 result is always of the form [a,oo] or [-oo,b]. So returning Entire, while "valid", shows laziness. Maybe you could check I have this correct, and suggest better wording. But it's only a Note. not normative text!
>
> John Pryce
>
> ------------------------------------------------
>
> On 2013 Nov 25, at 01:39, Michel Hack wrote:
>> 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.
>
> On 2013 Jun 12, at 13:08, Vincent Lefevre wrote:
>> I also find this less important for intervals. But note that the
>> double-rounding problem has a noticeable effect only for rounding
>> to nearest, not for the directed rounding modes used with inf-sup
>> interval types. Thus if
>> (1) T' is a superset of T;
>> (2) T -> T' tightest operations are implemented;
>> (3) T' -> T tightest hull is provided (this is required, isn't it?);
>> then the corresponding T -> T tightest operations are obtained by
>> composition of (2) and (3), so that I don't see any reason not to
>> provide these T -> T operations. But for a language not providing
>> them natively or in a library, saying "to get such an operation,
>> the programmer must write the composition explicitly" would be
>> a way to conform to the standard, IMHO, though languages should
>> define a shorter/simpler way to write these operations.
Begin forwarded message:
> From: Michel Hack <mhack@xxxxxxx>
> Subject: Re: Motion 56 -- Level 2, Clauses 12.12.1-12.12.7
> Date: December 12, 2013 at 8:45:02 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
>> On 2013 Nov 25, at 04:48, Michel Hack wrote:
>>> 12.12 intro, bottom of page 54 (P1788/D8.1 of Nov 15): As I pointed out
>>> for 12.6.2 already, we don't need explicit mixed-type operations for
>>> inf-sup types -- and 754-conforming types *are* inf-sup types.
>>
>> I feel this is wrong, but I defer to our experts on language binding issues.
>> Using ib64 as short for the inf-sup binary64 type, etc., suppose a programmer
>> writes an interval operation such as
>> zz_ib64 = xx_ib32 op yy_ib128 (*)
>> where "op" is one of the operations required to have "tightest" accuracy.
>>
>> As Vincent & Michel say, double-rounding isn't a problem for directed
>> rounding, so the required effect is got *if* the program actually does
>> 1. convert xx_ib32 to xx_ib128 (no error at this step),
>> 2. do "op" in ib128 precision, returning zz_ib128,
>> 3. take the ib64 hull of this to get the answer.
>>
>> But what's to say a given language will make this happen automatically?
>> - (*) might cause an error at compile time.
>> - Or, if a language *does* have rules that do this sort of automatic
>> coercion for library datatypes (as well as native datatypes) what's
>> to say they are the right rules? E.g., in (*) the default might be
>> to coerce all inputs to the destination type ib64, and I don't think
>> this guarantees the "tightest" result.
>
> Nothing to worry about! For correctly-rounded binary operations there
> is never a need to widen to more than the widest of source and target.
> (It would not be true for sums or products of three or more inputs --
> but we have the reduction operations for that.) Moreover, the standard
> is not concerned with infix (with implicit typing) vs functional notation
> (with implicit or explicit typing).
>
> One might worry about (*) being carried out in binary32 and then widened
> on assignment. THAT result would not be tightest in the wider format,
> but according to such a language, the programmer ASKED for this.
>
> The requirement that mixed-type (but same-radix) operations be supported
> is not going away. What I was proposing was that this could be satisfied
> without combinatorial explosion of conceptually explicitly-typed function
> types (the formatOf approach of 754-2008): it would be sufficient to have
> one homogeneous form per type, and inputs narrower than that type could
> safely be accomodated through input widening, without compromising even
> tightest evaluation.
>
> Michel.
> ---Sent: 2013-12-12 15:00:53 UTC
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Subject: Re: Motion 56 -- Level 2, Clauses 12.12.1-12.12.7
> Date: December 14, 2013 at 6:32:33 AM CST
> To: Michel Hack <mhack@xxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Michel
>
> On 2013 Dec 12, at 14:45, Michel Hack wrote:
>>> Using ib64 as short for the inf-sup binary64 type, etc., suppose a programmer
>>> writes an interval operation such as
>>> zz_ib64 = xx_ib32 op yy_ib128 (*)
>>> where "op" is one of the operations required to have "tightest" accuracy.
>> ...
>> ...
>>
>> One might worry about (*) being carried out in binary32 and then widened
>> on assignment. THAT result would not be tightest in the wider format,
>> but according to such a language, the programmer ASKED for this.
>>
>> The requirement that mixed-type (but same-radix) operations be supported
>> is not going away. What I was proposing was that this could be satisfied
>> without combinatorial explosion of conceptually explicitly-typed function
>> types (the formatOf approach of 754-2008): it would be sufficient to have
>> one homogeneous form per type, and inputs narrower than that type could
>> safely be accomodated through input widening, without compromising even
>> tightest evaluation.
>
> Avoiding a combinatorial explosion is obviously important. I'm probably showing my ignorance of programming languages here. Suppose 1788 is implemented by a class library. Suppose the library has "one homogeneous form per type" as you say. How does the library writer tell the compiler to widen a statement like (*) in the right way
> - in Fortran?
> - in C++?
> - in some other modern language, e.g. Python?
>
> John Pryce
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Motion P1788/M0052.3 Clause 6 Text: YES, with comments
> Date: December 16, 2013 at 8:18:11 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on Motion 52.3 (2013-11-28 version).
>
> However I think that the text concerning the computational graph could
> still be improved, as it is ambiguous. See below.
>
> A formalization of the equivalence between (a), (b) and (c), and the
> associated transformations, would be useful. This is not obvious, in
> particular with the corner cases (unused inputs, constant outputs,
> identities...). I've noticed at least a problem between (a) and (b).
>
> For instance, consider the following code lists. In the first example,
> one could regard the computational graph as having a single node, with
> no incoming and no outgoing edges. This is the one-variable identity.
>
> [m = 0, n = 1, p = 1]
> input v_0 = x_1
> output y_1 = v_0 = x_1
>
> But what happens to the computational graph when one adds an input
> that is not used, as in the following example? Since this input node
> has no outgoing edges (to some operation node), it could be regarded
> as an output, but actually it isn't!
>
> [m = 0, n = 2, p = 1]
> input v_{-1} = x_1, v_0 = x_2
> output y_1 = v_{-1} = x_1
>
> Now, let's add a second output: the same coordinate projection as the
> first one. Again, how can the difference be seen in the computational
> graph?
>
> [m = 0, n = 2, p = 2]
> input v_{-1} = x_1, v_0 = x_2
> output y_1 = v_{-1} = x_1, y_2 = v_{-1} = x_1
>
> To solve this problem with the computational graph, I can see two
> solutions:
>
> 1. Associate each node having no outgoing edges with a possibly empty
> set of output tags; these tags could be regarded as the integers i
> from 1 to p, meaning y_i in the code list.
>
> 2. Define specific output nodes (just like there are input nodes).
> These output nodes need an additional requirement: they must have
> a single incoming edge. So, a graph would have 3 kinds of nodes:
> - input nodes (with no incoming edges);
> - scalar operation (including constants) nodes;
> - output nodes (with a single incoming edge and no output edge).
>
> --
> 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)
Begin forwarded message:
> From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx>
> Subject: Motions 52, 54, 55, 56, 57: YES
> Date: December 26, 2013 at 4:49:08 AM CST
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on motions 52, 54, 55, 56, 57.
>
> I have noted a few things while reading the document, which might be worth tweaking at a later time:
>
> - The "tightest" mode is defined as returning the hull of the exact set (rather than just some minimal enclosure of the exact set). This is possibly too strong. Indeed, as 12.8 points out, the minimal enclosure is not unique for "implicit" types, so the hull is only one of the many possible minimal enclosures. This means that 12.10.1 requires that, if two exact sets are equal, then an implementation shall return the exact same minimal enclosure, irrespective of the actual values of the inputs. As a consequence, I believe it is impossible to design a conforming implementation. (It would be possible if only a minimal enclosure was required, which is what people actually expect from an implementation.)
>
> - Obviously, the same point holds for 12.12.7, 12.12.8, and 12.12.11. A simple fix might be to add a variant of "hull_T" that returns the set of all the minimal intervals, rather than a single one. So definitions would no longer be "... = hull_T(...)" but "... \in Hull_T(...)". Similarly, definitions would no longer be "the T-hull of ..." but "a T-hull of ...". Obviously, this only applies to places where T is not explicitly required to be a 754-conforming interval type.
>
> - In 12.12.9, the sentence about the rounding of zero is redundant with the way rounding is defined.
>
> Best regards,
>
> Guillaume
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Motions 54, 55, 56, 57: YES
> Date: December 26, 2013 at 8:30:19 PM CST
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on Motions 54, 55, 56, 57.
>
> Here are my comments for Motions 54 and 55. I'll send possible
> comments later for §12.12 (Motions 56 and 57).
>
> §12.1.1, last sentence: "It is language-defined whether the format or
> type of a datum can be determined at run time."
> Why language-defined, and not possibly implementation-defined?
> If the implementation is entirely provided by a library, then this
> will be implementation-defined.
>
> §12.3, paragraph 2: "double or float respectively, in C" is true in
> most C implementations, but not required by the ISO C standard.
>
> §12.3, concerning "equal as datums", how about the term "identical"
> as a synonymous (to avoid reusing "equal" for different meanings)?
>
> §12.5.1, "Each decorated interval type shall contain a “Not an Interval”
> datum NaI, identified with (∅, ill)." I think there's an open question
> related to that. See:
> --------
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: NaI vs (Empty,ill) (was: Motion 52: final "Expressions" text for vote)
> Date: Mon, 25 Nov 2013 00:45:09 +0100
> Message-ID: <20131124234509.GA30649@xxxxxxxxxxxxxxx>
> --------
>
> §12.5.2, paragraph 2 (on mid-rad): "Whether such a type also contains
> semi-bounded intervals is language- or implementation-defined."
> Since mid-rad is just an example of an implicit type (i.e. it is not
> part of specifications), I think it would be better to say something
> like: "Such a type may also contain semi-bounded intervals."
>
> §12.6.2, paragraph 1: "This eliminates the problem of double rounding
> in mixed-format work."
> In our context, this is not correct in general, where such a problem
> is nonexistent: as I've said last September, double rounding doesn't
> have any effect in directed rounding modes (assuming comparable
> formats/types, which is the case in general with 754-formats of same
> radix), i.e. double rounding gives the same value as single rounding.
> IMHO, in this context, the main gain from mixed-type operations could
> be faster code (if the corresponding formatOf 754-operations are
> implemented in hardware) without the need of specific optimizations.
> On the opposite, an implementation could say that T1-add(T2,T3) is
> provided by writing something like: (T1) add((Tmax) u, (Tmax) v),
> using C's cast notation, where Tmax is wider than T2 and T3.
>
> §12.7, paragraph 1: "floating-point" could be dropped here, as
> there are other kinds of multiple-precision systems. For instance,
> floating-point expansion systems (a.k.a. staggered arithmetic?)
> are such multiple-precision systems, but not multiple-precision
> floating-point systems.
>
> §12.8.1: It could be noted that the hull operation may inevitably
> transform a bounded set into an unbounded interval. The notion of
> overflow on intervals could be introduced here (though there is a
> bit in Section 8, on the decoration system).
>
> §12.10.1: Concerning Guillaume's remark about the "tightest" mode
> with implicit types, I would not disagree to relax the spec.
> Similarly, I also made a remark in quite old discussions, wondering
> why a particular minimal enclosure had to be chosen for the T-hull,
> and I don't remember if there was any good reason. One should notice
> that with some particular implicit types, a minimal enclosure may be
> much wider than other ones, but I see such issues as QoI (just like
> the choice of the precision for the interval types). However, later
> in Guillaume's remark: "As a consequence, I believe it is impossible
> to design a conforming implementation.", I don't think this is true;
> any example?
>
> §12.10.1, formula (35): the closing bracket is missing.
>
> --
> 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)
Begin forwarded message:
> From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx>
> Subject: Re: Motions 54, 55, 56, 57: YES
> Date: December 27, 2013 at 3:34:23 AM CST
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 27/12/2013 03:30, Vincent Lefevre wrote:
>
>> §12.10.1: Concerning Guillaume's remark about the "tightest" mode
>> with implicit types, I would not disagree to relax the spec.
>> Similarly, I also made a remark in quite old discussions, wondering
>> why a particular minimal enclosure had to be chosen for the T-hull,
>> and I don't remember if there was any good reason. One should notice
>> that with some particular implicit types, a minimal enclosure may be
>> much wider than other ones, but I see such issues as QoI (just like
>> the choice of the precision for the interval types). However, later
>> in Guillaume's remark: "As a consequence, I believe it is impossible
>> to design a conforming implementation.", I don't think this is true;
>> any example?
>
> Imagine you have two mathematical functions f1 and f2 and you are able to implement the interval versions so that they always return minimal enclosures. If you tell that "f1 is tightest", then you have a conforming library. If you tell that "f2 is tightest", then you also have a conforming library. But if you tell that "both f1 and f2 are tightest", do you still have a conforming library? The lack of modularity cannot be a good sign.
>
> As for an actual example, I guess it will have to be a bit farfetched. Consider cospi([0;0.25]) and sqrt([0.75;1]). (My trigonometry is a bit rusty, so bear with me if I got the inputs wrong.) What are the chances that the implementations return the exact same result for an implicit type? Any of these two functions could be tightest taken in isolation, but no longer when shipped together in a library.
>
> Perhaps a bit less contrived: on one side you perform (1,1) + (1+e,1) in mid-rad; one the other side you downgrade (2+e,2) from a larger format (where 2+e is representable). Even if both the addition and the conversion return a minimal enclosure, how do you guarantee that both functions are tightest?
>
> Best regards,
>
> Guillaume
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail