| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788, Motion M0032.01 Midpoint was defeated, 12 - Yes to 30 - No. Here is my attempt to summarize the discussions. Begin forwarded message: > From: Vincent Lefevre <vincent@xxxxxxxxxx> > Subject: I vote NO on: Motion P1788/M0032:midpoint > Date: April 2, 2012 7:04:22 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > I vote NO on: Motion P1788/M0032:midpoint > > The main problems (mentioned in my mail on 15 Mar 2012 15:51:29 +0100) > are: > > * "At level 1: mid(X) = (inf(X) + sup(X))/2" > > This should be for non-Empty, bounded intervals (the motion says > "non-Empty, non-Entire"). There's an amendment about that, but it > is still slightly incorrect: its title is "The midpoint function > for bounded, non-Empty intervals", but unbounded intervals are > still considered at Level 2, making the motion ambiguous. > > * "to be the smallest representable intervals" > > It seems that Dan Zuras uses "smallest" to mean here a minimal element > for the partial order. I don't think the wording is correct, making > the motion ambiguous. See the different notions here: > > http://en.wikipedia.org/wiki/Partially_ordered_set#Extrema > > Note that "smallest" or any minimality notion is useless here > (if the properties are true for X1 and X2, they remain true for > any supersets of X1 and X2). So, > > "to be the smallest representable intervals" > > could be replaced by "to be any representable intervals". > > BTW, the motion is a bit difficult to read due to the use of "&". > It could be replaced by "and". > > -- > 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: Vincent Lefevre <vincent@xxxxxxxxxx> > Subject: Re: I vote NO on: Motion P1788/M0032:midpoint > Date: April 2, 2012 7:26:02 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 2012-04-02 14:04:22 +0200, Vincent Lefevre wrote: >> * "to be the smallest representable intervals" >> >> It seems that Dan Zuras uses "smallest" to mean here a minimal element >> for the partial order. I don't think the wording is correct, making >> the motion ambiguous. See the different notions here: >> >> http://en.wikipedia.org/wiki/Partially_ordered_set#Extrema >> >> Note that "smallest" or any minimality notion is useless here >> (if the properties are true for X1 and X2, they remain true for >> any supersets of X1 and X2). So, >> >> "to be the smallest representable intervals" >> >> could be replaced by "to be any representable intervals". > > In fact the whole part > > X \subset (X1 \union X2) > [inf_F(X),mid_F(X)] \subset X1 (trivially) > [mid_F(X),sup_F(X)] \subset X2 (trivially) > mid_F(X) \element-of (X1 \intersect X2) > > doesn't depend on the definition of the midpoint: this remains true > for any mid_F function such that: > > inf_F(X) <= mid_F(X) <= sup_F(X) > > (and if this property were not true, writing [inf_F(X),mid_F(X)] and > [mid_F(X),sup_F(X)] would be meaningless). So, I think that it would > be better to remove this part from the motion, and perhaps replace it > by the more important property: inf_F(X) <= mid_F(X) <= sup_F(X), as > I've already mentioned in my 2012-03-15 mail. > > -- > 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: Vincent Lefevre <vincent@xxxxxxxxxx> > Subject: Re: I vote NO on: Motion P1788/M0032:midpoint > Date: April 2, 2012 8:04:28 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 2012-04-02 14:04:22 +0200, Vincent Lefevre wrote: >> I vote NO on: Motion P1788/M0032:midpoint >> >> The main problems (mentioned in my mail on 15 Mar 2012 15:51:29 +0100) >> are: > [...] > > A third problem I've just noticed (this one is new): the motion says > that for any X and Y that live at Level 2, > > "X \subset Y ==> if (inf_F(X)==inf_F(Y)) then mid_F(X) <= mid_F(Y)" > > However I don't think one necessarily wants mid_F(X) <= mid_F(Y). > This inequality is not satisfied on the following counter-example > anyway. > > Let F be a radix-10, 1-digit precision floating-point system. > Let the interval type be based on a triplex representation > <mid,rad1,rad2>. Let's choose: > > X = <20,-5,-3> = [15,17] > Y = <20,-9,-3> = [11,17] > > One has: "X \subset Y and inf_F(X) = inf_F(Y) = 10, so that the > conditions of the properties are satisfied. > > Then: > mid_F(X) = round2Nearest_F(mid(X)) = round2Nearest_F(16) = 20, > mid_F(Y) = round2Nearest_F(mid(Y)) = round2Nearest_F(14) = 10. > > The inequality mid_F(X) <= mid_F(Y) doesn't hold! Actually, I don't > see anything wrong by having mid_F(X) > mid_F(Y) here, since X >= Y. > > The problem comes from the fact that the midpoint is based on a > Level 1 definition (then mid(X) is rounded) while the property > is based on Level 2 lower bounds of the intervals. > > -- > 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: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: Re: Motion P1788/M0032.01:MidpointMeaning -- discussion period begins > Date: April 5, 2012 9:23:06 AM CDT > To: Michel Hack <mhack@xxxxxxx> > Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > Michel & P1788 > > On 15 Mar 2012, at 15:40, Michel Hack wrote: >> With regard to midpoint for implicit formats, >> Dan Zuras wrote, replying to Vincent Lefèvre: >>>> In particular, these requirements are valid for: >>>> X1 = hull_T([inf_F(X),mid_F(X)]) >>>> X2 = hull_T([mid_F(X),sup_F(X)]) >>>> if a hull_T function is defined. >>> >>> Also a fair point. Is hull any more unique >>> among the implicits than the "smallest" >>> superset in question? >> >> I seem to recall that part of the *definition* of an implicit format >> is an explicit hull function that is THE hull function by definition, >> precisely because there may not be a unique "natural" hull. >> >> For variable-precision formats there may indeed not be a "smallest", > or indeed a "minimal" >> at least in a practical sense. (An item that consumes the remainder >> of the address space may well be a tightest enclosure in any given >> situation, but would be useless since there would be no resources to >> continue with the computation.) > > That's why I explicitly say in my draft Level 2 text that such an interpretation of "variable-precision" is incompatible with P1788. To conform with IEEE 1788, a VP interval system must interface in such a way that at any moment it is working with intervals of a given precision. I.e., it supports a potentially infinite family of interval types T_d, parameterized by some measure d of the number of digits of precision. Not a single type that is the union of these. > > I suspect this will be unpopular with the authors of some VP systems, but it is a simple way to cut that Gordian knot; in fact the only way that I can see at present. > > John Begin forwarded message: > From: Vincent Lefevre <vincent@xxxxxxxxxx> > Subject: Re: Motion P1788/M0032.01:MidpointMeaning -- discussion period begins > Date: April 5, 2012 9:42:11 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 2012-04-05 15:23:06 +0100, John Pryce wrote: >> That's why I explicitly say in my draft Level 2 text that such an >> interpretation of "variable-precision" is incompatible with P1788. >> To conform with IEEE 1788, a VP interval system must interface in >> such a way that at any moment it is working with intervals of a >> given precision. I.e., it supports a potentially infinite family of >> interval types T_d, parameterized by some measure d of the number of >> digits of precision. Not a single type that is the union of these. >> >> I suspect this will be unpopular with the authors of some VP >> systems, but it is a simple way to cut that Gordian knot; in fact >> the only way that I can see at present. > > I don't think there would be any problem with MPFR-based IA systems, > because with MPFR, the user must specify the precision of the result > (e.g. this is done when initializing the target object or by changing > its precision). So, basically, the user specifies the parameterized > type. It could be a problem with systems that dynamically chooses the > precision of the result (e.g. from the internal error bound, which > is calculated dynamically); but I think that it should be OK, except > that the notion of "tightest" (and "accurate"?) will no longer be > usable. > > -- > 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: I vote NO on Motion M0032.02 Midpoint > Date: April 10, 2012 7:51:23 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > Hi, > > I vote NO. > > The reason for my vote is that the text of the motion is a bit too > complicated, and as shown by Vincent, this has some adverse effect with > respect to the intuitive properties one can expect from the midpoint. > > Note that I am perfectly fine with the idea of choosing an arbitrary > value lying in the input interval (that is, zero for entire intervals, > extremal values for half-infinite intervals) with some best effort > mandated for the finite case : returning the mathematical midpoint > rounded to nearest whenever this value lies in the input interval. So my > vote would become YES once the text of the motion is improved. > > Best regards, > > Guillaume Begin forwarded message: > From: Jean-Michel Muller <Jean-Michel.Muller@xxxxxxxxxxx> > Subject: I vote NO on Motion M0032.02 Midpoint > Date: April 10, 2012 8:32:43 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > Dear all, > > I full agree with Vincent and Guillaume's arguments, and I vote NO on Motion M0032.02 Midpoint. > > Best regards > > Jean-Michel > -- > Jean-Michel Muller, directeur de recherches CNRS > Lab. LIP, ENS Lyon, 46 allée d'Italie, 69364 Lyon Cedex 07, France > Phone (+33) 4 72728229 - Fax (+33) 4 72728806 > Jean-Michel.Muller@xxxxxxxxxxx http://perso.ens-lyon.fr/jean-michel.muller Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: I vote NO on: Motion P1788/M0032:midpoint > Date: April 6, 2012 10:11:36 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx> > > On 2 Apr 2012, at 13:04, Vincent Lefevre wrote: >> I vote NO on: Motion P1788/M0032:midpoint > > I also vote NO, for the reasons Vincent has given, and some others. > > First, even the latest version of the motion says >> Coercion to level 2: For some implicit or explicit IFbar >> based on a some floating-point system F we have that ... > which, using the terminology I've used in the draft text, would read > "For some implicit or explicit interval type T > based on a some number format F we have that ..." > > P1788 currently does not define a meaning for "T based on F" here, for general types T. Such a meaning is of course defined for inf-sup types, but even for my (unofficial) definition of a mid-rad type, the midpoint and radius need not use the same number format. This vagueness conceals pitfalls, as Vincent's recent counter-example (2 April 2012 14:04:28) shows. > > What I *have* proposed in the Level 2 draft is the reverse: that there should be a particular "F associated with T" for each T. Some people have disagreed with this, some are sympathetic. Some, including Vincent, have proposed some basic properties such an F be required to possess. I hope Vincent will make a motion on this soon. If we get a suitable set of properties (maybe of T's as well as their F's), possibly we can eliminate counterexamples such as Vincent's. > > Second. > Dan has been most eloquent in arguing that NaN is inherently dangerous, and that 1788 will be a better platform for reliable computing if the operations that convert interval inputs to floating point results create as few NaNs as possible, preferably none at all. > > I accept there are areas of software where "choose a number -- any number" gives a safer return-value than a NaN. Maybe one of these is control of embedded systems. But even there, the case studies Dan has told me of suggest that a value tailored to the application is what is needed (e.g. "stick at the maximum, or minimum, allowed"), not a single catch-all value. > > So I remain unconvinced. IMO this should NOT drive our philosophy of how to handle the interval-to-floating-point interface. > If the rocket blows up and the media scream "'Secure' computer arithmetic loses taxpayer a billion dollars", we should stick to our guns and say "It wasn't IEEE 754, it was poor software production, probably for the usual reasons of faulty analysis and design, poor house-rules for coding, inadequate testing, and trying to do too much in too little time". Being human, in other words. > > I regret being at odds with Dan, but I believe that for most numerical computation, it is *easier* to make it secure if, when some real function has an undefined value at Level 1, it returns a NaN at Level 2. That's what NaN was designed for. > > My suggestions, which I think accord fairly well with Arnold's and some other folk's, are > > a. Level 2 midpoint, with input an X of some interval type T, returning m of some number format F, should compute > m = roundToNearest_F(exact midpoint of X) > when X is nonempty and bounded and the resulting m is finite; and NaN otherwise. (So F must support NaN.) > It is of course possible that X is nonempty and bounded, but m isn't finite, e.g. with the triplex representation of Vincent's 2nd April example, since this can exactly represent X=[2*realmax,2*realmax] for instance. In that case I feel m=NaN is better than m=Inf. > > b. A "median" function, for splitting intervals in branch-and-bound (or similar) applications, has different requirements from "midpoint" -- such as that, for any nonempty X, it should *always* return a finite value m that is "useful". > > c. P1788 should offer one "median" function in the set of Recommended Functions, for user convenience. > > Regards > > John Pryce > > --------------------P.S.------------------ > I am still waiting for someone to produce an implementation of the Michel/Arnold median function based on "convert to sortable". Meantime, attached, I offer SMEDIAN2, a hardened-up Matlab version of my > m = smedian(a,b) = sinh( (asinh(a)+asinh(b))/2 ) > > Level 2 properties (I believe): > - Just uses the operations + - * / sqrt() and hypot(). > - For all finite a,b it returns a finite result m that is within > a few ulps of the exact result and is *always* between a and b. > - If either input is NaN it returns NaN. > - Else, if either input is infinite it treats it as a "Level 2 > special case" as shown in this table, where H denotes the > largest representable real, realmax. > \ b= > a= \ -inf finite +inf | > -------+--------+--------+--------+ > -inf | -inf -H 0 | > finite | -H n/a +H | > +inf | 0 +H +inf | > -------+--------+--------+--------+ > Thus if a and b are the bounds of any nonempty representable > interval, it returns a finite value that lies in the interval. > - It is also vectorized. > > At Level 1, SMEDIAN2 is monotone, i.e. > a1<=a2, b1<=b2 ==> smedian2(a1,b1) <= smedian2(a2,b2). > Sadly this isn't true for my code, it can fail "by a few ulps". I don't know how to achieve it without using extra precision. > > Please try to break this code. >
Attachment:
smedian2.m
Description: smedian2.m
Begin forwarded message:
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: I vote NO on: Motion P1788/M0032:midpoint
> Date: April 8, 2012 5:19:46 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>
> I jump on the NO bandwagon for the same reasons, though I'd really like to thank Dan for all his efforts as well as the tremendous amount of time he's invested in offline discussions with me on the subject. I've learned a great deal.
> Nate
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: I vote NO on: Motion P1788/M0032:midpoint
> Date: April 11, 2012 8:56:09 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2012-04-06 16:11:36 +0100, John Pryce wrote:
>> What I *have* proposed in the Level 2 draft is the reverse: that
>> there should be a particular "F associated with T" for each T. Some
>> people have disagreed with this, some are sympathetic. Some,
>> including Vincent, have proposed some basic properties such an F be
>> required to possess. I hope Vincent will make a motion on this soon.
>
> FYI, I currently have a draft, but before submitting it, I first need
> to do some verifications and finish to read other stds-1788 mail in
> case I forgot something. Perhaps later today.
>
>> If we get a suitable set of properties (maybe of T's as well as
>> their F's), possibly we can eliminate counterexamples such as
>> Vincent's.
>
> My current text doesn't eliminate this one, and it could be artificial
> to eliminate it. I think that the property
>
> X \subset Y ==> if (inf_F(X)==inf_F(Y)) then mid_F(X) <= mid_F(Y)
>
> is just bad because it mixes Level 1 and Level 2. The problem is
> the following one. One may have:
>
> [--- X ---]
> [---- Y ----]
>
> with F such that inf_F(X) == inf_F(Y). Note that this is not possible
> with an inf-sup format, because inf_F(X) = inf(X) and ditto for Y.
>
> Note: here mid_F(X) <= mid_F(Y) would mean in practice that one has
> the equality mid_F(X) == mid_F(Y).
>
> So, if around inf(X) and inf(Y), F is sparse enough (so that
> inf_F(X) == inf_F(Y)) and around mid(X) and mid(Y), F is dense enough,
> then one won't be able to have mid_F(X) <= mid_F(Y) all the time. With
> a floating-point format, this problem is more likely to occur in high
> radices when inf(X) and inf(Y) are negative and mid(X) and mid(Y) have
> a smaller exponent.
>
> --
> 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: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0032:midpoint -- voting period begins YES
> Date: April 11, 2012 11:42:12 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES for the motion M0032.
>
> This motion:
> 1) repeats Level 1 definition of mid(X) from John's Level 1 draft
> that was defined for nonempty bounded intervals and undefined otherwise;
>
>>> At level 1: mid(X) = (inf(X) + sup(X))/2
>
> I agree.
>
> 2) it formulates Level 2 definiton of mid(X) for nonempty bounded and unbounded intervals;
>
>>> Coercion to level 2: For some implicit or explicit IFbar
>>> based on a some floating-point system F we have that
>>>
>>> mid_F(X) = if ((inf(X) == -\infty)&& (sup(X) == +\infty)) then 0
>>> else if (round2Nearest_F(mid(X)) == +\infty)
>>> then nextDown_F(+\infty)
>>> else if (round2Nearest_F(mid(X)) == -\infty)
>>> then nextUp_F(-\infty)
>>> else round2Nearest_F(mid(X))
>>>
>>> Note that midpoint has been generalized to include Entire via
>>> the means of the arbitrary choice of zero as its midpoint.
>>> This choice is part of this motion. Midpoint is still not
>>> defined for Empty& any generalization to include Empty is
>>> not part of this motion.
>
> My opinion is that Level 2 definition should pick some arbitrary number for unbounded intervals
> though I understand arguments of thos who consider that the result should be NaN.
> The choices of 0, F_max, -F_max in the definition (2) seems the best for me.
> So I agree with meaning of (2) too. The wording could of (2) be other:
> "For any floating-point system T and for any interval type T"
> This doesn't break the definition, it extends it.
>
> 3) also the motion contains some properties of Level 1 and Level 2 definition.
>
> The properties for Level 1 are fine;
> The current formulation of properties for Level 2 was broken by Vincent's example,
> but I know how to reformulate them.
>
> I consider that this motion is about semantics of mid(X), not about of exact wording in the standard.
> The semantics is good for me.
> The wording could me as small as a line in a table and a remark below the table.
>
> So I would like that this motion was accepted as semantic Level 2 definition on nonempty intervals.
> The Level 2 definition of mid(Empty) is a topic of future discussion.
> The exact wording in Level 2 part of the standard also could be discussed later.
>
> -Dima
Begin forwarded message:
> From: Lee Winter <lee.j.i.winter@xxxxxxxxx>
> Subject: Re: P1788: PLEASE VOTE on Motions 30.02, 31.01, and 32.01
> Date: April 12, 2012 11:04:22 PM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Cc: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> On Thu, Apr 12, 2012 at 8:30 AM, Corliss, George
> <george.corliss@xxxxxxxxxxxxx> wrote:
>> P1788,
>> Motion M0032.02 Midpoint
>> Current tally: Yes: 9; No: 11; Required for quorum: 31
>> Voting by rules for position papers
>> Voting closes Tuesday, April 22
>
> My vote is NO. My rationale is that I do not believe in use cases
> wherein a user confronted with a simple mean of a bounded
> representation will be confused by a result of overflow.
>
> Lee Winter
> Nashua, New Hampshire
> United States of America
Begin forwarded message:
> From: Michel Hack <mhack@xxxxxxx>
> Subject: Motion P1788/M0032.02: I vote NO
> Date: April 15, 2012 10:49:20 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on M0032.02 -- the main issue for me being that the Level 2
> midpoint might not be a member, so the mention of [inf_F(X),mid_F(X)]
> might be meaningless.
>
> I would excuse the "bounded" (used to be "non-Entire") in the title
> as a misdemeanor; the inclusion of Entire being explicitly "part of
> this motion" -- this would be an easy fix (the restriction to bounded
> intervals only applies to Level 1 and should be mentioned thus).
>
> I don't see "smallest" as a problem -- I interpret it as the intersection
> of all intervals satisfying the constraint -- though this could be empty,
> and we would have a problem.
>
> I would prefer to return NaN when no member of a bounded interval can be
> found that is the Level 1 midpoint rounded to a Level 2 datum. I don't
> mind the Level 2 choices made for unbounded intervals.
>
> Some of these difficulties might be cleared up if we firm up what counts as
> a legitimate number format and a legitimate interval format. For example,
> must we support off-center intervals [a+b,a+c] with b and c of the same sign?
>
> Michel.
> ---Sent: 2012-04-16 04:22:19 UTC
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0032.02: I vote NO
> Date: April 16, 2012 1:05:29 AM CDT
> To: Michel Hack <mhack@xxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> P1788
>
> On 16 Apr 2012, at 04:49, Michel Hack wrote:
>> I vote NO on M0032.02 -- the main issue for me being that the Level 2
>> midpoint might not be a member...
>>
>> Some of these difficulties might be cleared up if we firm up what counts as
>> a legitimate number format and a legitimate interval format. For example,
>> must we support off-center intervals [a+b,a+c] with b and c of the same sign?
>
> On this last Q, I would say No, why should we, seeing what troubles they seem to cause? I would support the kind of restrictions on number format that Vincent, Dmitry and others are proposing.
>
> Dmitry's idea "every nonempty interval of any type must contain a singleton interval of the same type" is different, being a restriction on interval types T rather than on number formats. I'm a bit dubious, because (a) it may be quite tricky to check for a given proposed T, (b) if you treat the singletons as defining a number format F=myFormat(T), it may be tricky for it to interoperate with ordinary FP formsts. However, both those are really the problem of whoever invents T, not of 1788, so I could be convinced.
>
> John Pryce
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0032.02: I vote NO
> Date: April 16, 2012 9:39:34 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2012-04-15 23:49:20 -0400, Michel Hack wrote:
>> I vote NO on M0032.02 -- the main issue for me being that the Level 2
>> midpoint might not be a member,
>
> a member of what?
>
>> so the mention of [inf_F(X),mid_F(X)] might be meaningless.
>
> Could you give an example? AFAIK, [inf(X),mid_F(X)] can be meaningless,
> but [inf_F(X),mid_F(X)] is a valid interval, as pointed out by Dmitry
> in a recent discussion.
>
> --
> 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: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0032.02: I vote NO
> Date: April 16, 2012 9:53:30 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2012-04-16 07:05:29 +0100, John Pryce wrote:
>> P1788
>>
>> On 16 Apr 2012, at 04:49, Michel Hack wrote:
>>> I vote NO on M0032.02 -- the main issue for me being that the Level 2
>>> midpoint might not be a member...
>>>
>>> Some of these difficulties might be cleared up if we firm up what
>>> counts as a legitimate number format and a legitimate interval
>>> format. For example, must we support off-center intervals
>>> [a+b,a+c] with b and c of the same sign?
>>
>> On this last Q, I would say No, why should we, seeing what troubles
>> they seem to cause? I would support the kind of restrictions on
>> number format that Vincent, Dmitry and others are proposing.
>
> I don't think they (as intervals) cause any specific trouble.
> You need to make the difference between:
> 1. The troubles caused by some interval type.
> 2. The troubles caused by the relation between some interval type
> and some number type.
>
> The mentioned problems in recent discussions fall in (2), not in (1).
>
>> Dmitry's idea "every nonempty interval of any type must contain a
>> singleton interval of the same type" is different, being a
>> restriction on interval types T rather than on number formats.
>
> Yes.
>
>> I'm a bit dubious,
>
> Me too.
>
>> because (a) it may be quite tricky to check for a given proposed T,
>
> I'm not so sure.
>
>> (b) if you treat the singletons as defining a number format
>> F=myFormat(T), it may be tricky for it to interoperate with ordinary
>> FP formsts.
>
> I agree. Actually I see some theoretical interest in Dmitry's idea.
> But in practice, I'm wondering... Would there any algorithm use his
> idea?
>
>> However, both those are really the problem of whoever invents T, not
>> of 1788, so I could be convinced.
>
> Yes. But problems are specific to some operations and/or algorithms.
> And some operations and/or algorithms do not necessarily make sense
> with some types. For instance, users of mid-rad probably use it for
> approximations with guaranteed results, and are not interested in
> splitting.
>
> --
> 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: Michel Hack <mhack@xxxxxxx>
> Subject: Re: Motion P1788/M0032.02: I vote NO
> Date: April 16, 2012 10:03:44 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Vincent Lefèvre a écrit:
>> On 2012-04-15 23:49:20 -0400, Michel Hack wrote:
>>> I vote NO on M0032.02 -- the main issue for me being that the Level 2
>>> midpoint might not be a member,
>>
>> a member of what?
>
> A member of the interval whose "midpoint" is being taken. This can
> happen for certain off-center "implicit" formats.
>
>>> so the mention of †inf_F(X),mid_F(X)¨ might be meaningless.
>>
>> Could you give an example? AFAIK, †inf(X),mid_F(X)¨ can be meaningless,
>> but †inf_F(X),mid_F(X)¨ is a valid interval, as pointed out by Dmitry
>> in a recent discussion.
>
> Ah yes, that subtlety had escaped me! I apologise. To some extent this
> means that my objections become more an issue of comfort than substance.
>
> It does however require including Dmitry's (who btw signs "Dima" -- in
> Russian (and Spanish too) colloquial first names often look quite different
> from corresponding formal names) definition of inf_F and sup_F based on
> the hull_t() function required of implicit types. Motion 19 on implicit
> types did not define inf_F and sup_F (because the concept of _F had not
> yet been exposed).
>
> So I would vote YES if the definitions of inf_F and sup_F were included,
> still being uncomfortable however about reporting a "midpoint" that is
> outside the interval (as I said, I would prefer NaN in this case).
>
> Another issue bothered me slightly: the use of round2Nearest(Level1mid).
> I wonder if thered might be cases where this rounding yields an exterior
> point, whereas rounding in the other direction (by more than half an ulp)
> would yield an interior point. Upon reflection however this cannot
> happen for bounded intervals, so I don't have to worry about this.
>
> Michel.
>
Begin forwarded message:
> From: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0032.02: I vote NO
> Date: April 17, 2012 5:49:09 PM CDT
> To: <vincent@xxxxxxxxxx>, J D Pryce <j.d.pryce@xxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
>
>>> (b) if you treat the singletons as defining a number format
>>> F=myFormat(T), it may be tricky for it to interoperate with ordinary
>>> FP formsts.
>>
>> I agree. Actually I see some theoretical interest in Dmitry's idea.
>> But in practice, I'm wondering... Would there any algorithm use his
>> idea?
>
> For now I know only one application of myFormat(T). This is centered point algorithm.
>
> Center form solves the problem:
> Input: f(x) - expression for f; g(x) - expression for df/dx ; interval X.
> Output: Interval extension of f(X).
>
> The mathematical (Level 1) formulation of centered form algorithm is
> (1) return f(mid(X)) + (X - mid(X))*g(X)
> Here f(mid(X)) is a point calculation of f.
>
> Computer implementation of centerd form actually uses another formulation
> (2) C = [mid_F(X),mid_F(X)]; return f(C) + (X - C)*g(X)
> f(C) is an interval calculation of f that takes into account rounding errrors.
> So computer implementations already use singleton C of datatype T.
> We can consider it as value of myFormat(T).
>
> The (2) works only when mid_F(X) \in X .
> This condition \m in X may fail for offcenter intervals X=[a+b,a+c], where a, b, c \in F.
>
> Is it necessary to switch from interval X of datatype T to number format mid_F(X) and
> then return again to T-interval [mid_F(X),mid_F(X)] ?
> We can use instead
> (3) C = cent_T(X); return f(C) + (X - C)*g(X).
> where cent_T(X) is an operation that maps T-interval X to T-singleton closest to level 1 mid(X).
>
> We can consider cent_T(X) as mid_{myFormat(T)}(X) .
>
> The cent_T([a+b,a+c]) will return T-singleton [a+roundNearest_F((b+c)/2),a+roundNearest_F((b+c)/2)]
> for offcenter intervals X=[a+b,a+c], where a, b, c \in F .
> The "point a+roundNearest_F((b+c)/2)" is contained in X so (3) is correct.
> This solves the issue with offcenter intervals.
>
> -Dima
>
>
> ----- Исходное сообщение -----
> От: vincent@xxxxxxxxxx
> Кому: stds-1788@xxxxxxxxxxxxxxxxx
> Отправленные: Понедельник, 16 Апрель 2012 г 18:54:24 GMT +04:00 Абу-Даби, Маскат
> Тема: Re: Motion P1788/M0032.02: I vote NO
>
> On 2012-04-16 07:05:29 +0100, John Pryce wrote:
>> P1788
>>
>> On 16 Apr 2012, at 04:49, Michel Hack wrote:
>>> I vote NO on M0032.02 -- the main issue for me being that the Level 2
>>> midpoint might not be a member...
>>>
>>> Some of these difficulties might be cleared up if we firm up what
>>> counts as a legitimate number format and a legitimate interval
>>> format. For example, must we support off-center intervals
>>> [a+b,a+c] with b and c of the same sign?
>>
>> On this last Q, I would say No, why should we, seeing what troubles
>> they seem to cause? I would support the kind of restrictions on
>> number format that Vincent, Dmitry and others are proposing.
>
> I don't think they (as intervals) cause any specific trouble.
> You need to make the difference between:
> 1. The troubles caused by some interval type.
> 2. The troubles caused by the relation between some interval type
> and some number type.
>
> The mentioned problems in recent discussions fall in (2), not in (1).
>
>> Dmitry's idea "every nonempty interval of any type must contain a
>> singleton interval of the same type" is different, being a
>> restriction on interval types T rather than on number formats.
>
> Yes.
>
>> I'm a bit dubious,
>
> Me too.
>
>> because (a) it may be quite tricky to check for a given proposed T,
>
> I'm not so sure.
>
>> (b) if you treat the singletons as defining a number format
>> F=myFormat(T), it may be tricky for it to interoperate with ordinary
>> FP formsts.
>
> I agree. Actually I see some theoretical interest in Dmitry's idea.
> But in practice, I'm wondering... Would there any algorithm use his
> idea?
>
>> However, both those are really the problem of whoever invents T, not
>> of 1788, so I could be convinced.
>
> Yes. But problems are specific to some operations and/or algorithms.
> And some operations and/or algorithms do not necessarily make sense
> with some types. For instance, users of mid-rad probably use it for
> approximations with guaranteed results, and are not interested in
> splitting.
>
> --
> 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: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Subject: Motion P1788/M0032.01:Midpoint NO
> Date: April 17, 2012 6:20:28 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on this motion.
>
> I would much prefer to see a function that is less arbitrary for
> choosing the midpoint. For example, a two-argument version of the
> function mid_F(x) would allow the *user* to specify the returned
> midpoint intelligently if the endpoints were infinities.
>
> I am also concerned that returning the floating-point values closest
> to infinity (i.e. nextDown_F(+\infty) ) when splitting has a high
> probability of creating floating-point problems. A midpoint value
> specified by the user would again eliminate this problem.
>
> --
> Alan Eliasen
> eliasen@xxxxxxxxxxxxxx
> http://futureboy.us/
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail