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

P1788: Summary, M0031.01 Level 1 text

To: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
Subject: P1788: Summary, M0031.01 Level 1 text
From: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
Date: Sat, 5 May 2012 16:12:11 +0000
Accept-language: en-US
Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
Delivered-to: mhonarc@xxxxxxxxxxxxxxxx
List-help: <https://listserv.ieee.org/cgi-bin/wa?LIST=STDS-1788>, <mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO%20STDS-1788>
List-owner: <mailto:STDS-1788-request@LISTSERV.IEEE.ORG>
List-subscribe: <mailto:STDS-1788-subscribe-request@LISTSERV.IEEE.ORG>
List-unsubscribe: <mailto:STDS-1788-unsubscribe-request@LISTSERV.IEEE.ORG>
Sender: stds-1788@xxxxxxxx
Thread-index: AQHNKtnTVLwwFBFpsUSd0JbY8rA+pA==
Thread-topic: P1788: Summary, M0031.01 Level 1 text

P1788,

Motion M0031.01 Midpoint was passed, 39 - Yes to 5 - No.  Here is my attempt to summarize the discussions.

Our Policies and Procedures say that a vote of NO shall be considered a motion to amend.  Hopefully, the Technical Editors can use this summary to formulate amendments.


Begin forwarded message:

> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Motion M0030 and M0031: YES and NO
> Date: March 30, 2012 9:15:39 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> 
> I vote YES on Motion M0030 Level 1 Constructors because invalid construction
> should be treated as undefined operation. However my support is provisional,
> since the motion as currently written is incompatible with a standard for
> Kaucher/modal intervals.
> 
> I vote NO on Motion M0031 Level 1 standard text. I would vote yes if the
> "natural interval extention" and "interval extention" are instead defined in
> terms of f* and and Semantic Theorem for f* along the lines sketched out in
> the attached PDF.
> 
> Best regards,
> 
> Nate Hayes
> Sunfish Studio, LLC

Attachment: P1788modalsketch.pdf
Description: P1788modalsketch.pdf




Begin forwarded message:

> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: NO on Motion P1788/M0031:Level_1_standard_text
> Date: March 30, 2012 8:36:50 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-03-29 21:58:21 +0200, Jürgen Wolff von Gudenberg wrote:
>> Dmitri, Vincent, all of you
>>  sorry for the confusion.
>>   version 4.4 is now accessible under motion 31 or under the P1788
>> document.
> 
> I vote NO on Motion P1788/M0031:Level_1_standard_text.
> 
> 5.6.8. Numeric functions of intervals. I think there was an agreement
> to have inf(Empty) = +oo and sup(Empty) = -oo at least. See the mail
> "Table 4 proposal version 0.2..." from Dan Zuras on 29 Feb 2012.
> 
> About Boolean functions of intervals (5.6.9) and the empty set, I sent
> a mail "Motion 31 (proposed Level 1 text V04.2) and Boolean functions"
> on 27 Jan 2012 14:30:52 +0100, but AFAIK, I got no replies. The current
> text disagrees with Motion 13.04, and the behavior on the empty set
> should be reconsidered. Also, I've just noticed that Motion 13.04 (and
> 31) disagrees with both the Vienna proposal and the standard topology
> definition <http://en.wikipedia.org/wiki/Interior_%28topology%29>; for
> instance, Entire should be interior to itself.
> 
> Some suggested changes (mostly editorial):
> 
> First line of 5.1: "in addition" should start with a capital letter.
> 
> 5 lines below: "An interval's members are finite numbers, but its bounds
> can be infinite." -> "The members of an interval are finite numbers, but
> its bounds (if the interval is non empty) can be infinite." (because an
> empty interval doesn't have bounds).
> 
> Next sentence: "Finite or infinite numbers can be input to interval
> constructors, as well as output from operations, e.g., the interval
> width operation." -> input*s* / output*s* (?)
> 
> -- 
> 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: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>
> Subject: Motion 31
> Date: April 3, 2012 2:01:31 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> Dear P1788 members,
> 
> on March 26, 2012 I sent you the attached remarks concerning denotations of motion 31.  If the denotations have not been changed since my vote on Mogtion 31 is NO!
> 
> Ulrich Kulisch

Attachment: Notation1.pdf
Description: Notation1.pdf


Begin forwarded message:

> From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
> Subject: Re: Motion 31
> Date: April 3, 2012 10:29:05 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> Ulrich et al,
> 
> We can take your notational comments into consideration when 
> writing the actual standards text.  Also, it is in general a good
> idea to use our agreed upon notation in position papers.  However,
> I view motion 31, as a position paper, as providing guidance 
> for actual writing the standards text, so the meaning in motion 31 is
> what is of primary importance.  That is, even if Motion 31 passes,
> we can still use your notation in the text.
> 
> Best regards,
> 
> Baker
> 
> On 04/03/2012 12:01 PM, Ulrich Kulisch wrote:
>> Dear P1788 members,
>> 
>> on March 26, 2012 I sent you the attached remarks concerning denotations of motion 31. If the denotations have not been changed since my vote on Mogtion 31 is NO!
>> 
>> Ulrich Kulisch
> 


Begin forwarded message:

> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 31
> Date: April 5, 2012 8:02:39 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-04-03 22:29:05 -0500, Ralph Baker Kearfott wrote:
>> Ulrich et al,
>> 
>> We can take your notational comments into consideration when 
>> writing the actual standards text.  Also, it is in general a good
>> idea to use our agreed upon notation in position papers.  However,
>> I view motion 31, as a position paper, as providing guidance 
>> for actual writing the standards text, so the meaning in motion 31 is
>> what is of primary importance.  That is, even if Motion 31 passes,
>> we can still use your notation in the text.
> 
> I agree. If I understand correctly, Motion 31 is about Level 1 text
> (Section 5). Sections 3 and 4 are there for the context (to be able
> to understand Section 5).
> 
> -- 
> 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: Jürgen Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 31
> Date: April 6, 2012 6:51:29 AM CDT
> To: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> Baker
> I would not call the level 1 draft a position paper, but I agree that notation can be changed
> Juergen
> 
> Am 04.04.2012 05:29, schrieb Ralph Baker Kearfott:
>> Ulrich et al,
>> 
>> We can take your notational comments into consideration when
>> writing the actual standards text.  Also, it is in general a good
>> idea to use our agreed upon notation in position papers.  However,
>> I view motion 31, as a position paper, as providing guidance
>> for actual writing the standards text, so the meaning in motion 31 is
>> what is of primary importance.  That is, even if Motion 31 passes,
>> we can still use your notation in the text.
>> 
>> Best regards,
>> 
>> Baker
>> 
>> On 04/03/2012 12:01 PM, Ulrich Kulisch wrote:
>>> Dear P1788 members,
>>> 
>>> on March 26, 2012 I sent you the attached remarks concerning denotations of motion 31. If the denotations have not been changed since my vote on Mogtion 31 is NO!
>>> 
>>> Ulrich Kulisch
>> 



Begin forwarded message:

> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Subject: Re: Proposed revision to Level 1 comparisons
> Date: April 9, 2012 9:11:36 AM CDT
> To: Jürgen Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Cc: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
> 
> Juergen, P-1788,
> 
> On 04/09/2012 08:56 AM, Jürgen Wolff von Gudenberg wrote:
>> Baker
>> I suggest to restart the voting on that motion , give John some time to fill in all the tiny improvements and changes in notation.
>> It is our first vote on the final text so we should not make a formal mistake
> 
> George, John, and I had decided off-line to let the vote proceed, to
> gather other problems people might find, then to submit all of these either
> as amendments (in the case of passage), or as modifications (in the
> case of failure).  John can make modifications in parallel.  Our guess
> is that this would reduce the total number of iterations (and time elapsed)
> until we get a document with which we all are happy.  However, if
> you strongly feel this is either improper or not the best way,
> we can stop the vote.  In the mean time, I request that people
> continue to vote.
> 
> Best regards,
> 
> Baker



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 M0031.01 Level 1 text
>>  Current tally: Yes: 19; No: 3; Required for quorum: 31; 2/3 majority required to pass
>>  Voting by rules for STANDARD WORDING
>>  Voting closes Tuesday, April 17
> 
> My vote is NO.  My rationale is that the standard must provide an
> efficient mechanism for a user of an 1788-compliant implementation to
> distinguish underflow from zero and a mechanism for distinguishing
> overflow from infinity.  If such mechanisms were incorporated into the
> proposed standard text my vote would be YES.
> 
> Lee Winter
> Nashua, New Hampshire
> United States of America



Begin forwarded message:

> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 4, 2012 7:10:16 AM CDT
> To: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> Dmitry & P1788
> 
> At last I'm catching up on recent discussions. 
> 
> First let me say I agree with criticisms I've seen of the Motion 13 Comparisons text in §5.6.9. They *need* definitions from first principles in terms of sets, rather than endpoints. If we don't have that then how they act on empty and unbounded inputs is likely to be ad-hoc and possibly contradictory. I'm just discussing with Vincent on revised text.
> 
> On 20 Mar 2012, at 11:59, Dmitry Nadezhin wrote:
>> 1) p.10. Section 4.1. ... "Level 2 arithmetic normally acts on intervals of a given type
>> to produce an interval of the same type."
>> 
>> Is this important ?
>> The level 2 draft defines level 2 interval operations op_T(x, y) = hull_T(op(x, y)).
>> So definition
>> op: T1 X T2 -> T
>> is as easy as definition
>> op: T X T -> T
> 
> I'm not so interested in how easy it is to *define* as how easy it is to *implement*. I should hate to implement, in "tightest" mode, something like
> op: decimal64 X binary32 -> binary64 
> (meaning infsup in each case) let alone operations involving several exotic implicit types.
> 
>> Could we omit this phrase or append to it something like this :
>> "... , but interval operations that act on intervals of types other than the result type are always possible".
> But I'ld accept this amendment. 
> 
> IMHO the only mixed type operations that should be *mandated* by Level 2 are where
> - Types T1, T2 and T are inf-sup types derived from IEEE754 formats
> - of the same radix
> - such that the underlying implementation supports "formatOf" for the
>  corresponding point operations, in the needed rounding modes;
> because these essentially come for free (I believe).
> 
>> 2) p.12. Section 5.2. "Excluding Empty is indicated by the notation I, e.g. \underline{I}R or \underline{I}(R), the nonempty closed intervals with
>> (finite) real bounds.
>> 
>> Maybe "Excluding Empty, Entire and semi-infinite intervals ... " is more precise ?
> 
> Yes, I'll do that.
> 
>> 3)p. 18 Table 2 and p.20. Table 3. "recip" or "inv" ?
>> Table 2 names inverse function as "recip" and Table 3 names it "invRev".
> 
> Good point. I think I'll go for "recip" since someone, Juergen I think, would like to rename the "reverse" functions as "inverse" functions.
> 
> John Pryce



Begin forwarded message:

> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 4, 2012 10:51:24 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> 
> John Pryce wrote:
>> First let me say I agree with criticisms I've seen of the Motion 13
>> Comparisons text in §5.6.9. They *need* definitions from first principles
>> in terms of sets, rather than endpoints. If we don't have that then how
>> they act on empty and unbounded inputs is likely to be ad-hoc and possibly
>> contradictory.
> 
> I remember the discussions surrounding this issue during the Motion 13
> discussion period. Before too much time is invested rehashing the same
> topic, I would recommend re-reading some of those threads.
> 
> In a nutshell, the issue as I recall boiled down to "unbounded" vs.
> "overflown" intervals. To paraphrase Arnold Neumaier's distinction between
> these two concepts:
> 
>   -- The "unbounded" interval [7,+Inf] is a single interval (set of real
> numbers) with an upper endpoint that is not bounded.
> 
>   -- The "overflown" interval [7,+OVR] on the other hand is a family of
> intervals. There are an infinite number of intervals in the family, but each
> element of the family is closed and bounded.
> 
> The correct definitions and/or interpretations of the comparison operations
> depend on these distinctions. For example, from a purely mathematical
> perspective the comparison of unbounded intervals
>   [7,+Inf] \interior [1,+Inf]
> is true; however as pointed out by Arnold the comparison of "overflown"
> intervals
>   [7,+OVR] \interior [1,+OVR]
> is necissarily false.
> 
> So if one interprets the comparision operations in Motion 13 in the light of
> overflown intervals, then those endpoint formulas are correct.
> 
> There was a great deal of dissucssion at the time about what the endpoint
> formula should be for unbounded intervals, instead, and this all led to very
> complicated and slow implementations.
> 
> In my opinion, P1788 should consider restricting Level 1 to bounded
> intervals and introduce "overflown" intervals at Level 2. After the recent
> discussion on midpoint, it seems the committee is already leaning in this
> direction anyways. It also means the formulas in Motion 13 which are very
> simple and efficient could still be used for implementations.
> 
> Nate



Begin forwarded message:

> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 5, 2012 8:17:58 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-04-04 13:10:16 +0100, John Pryce wrote:
>> IMHO the only mixed type operations that should be *mandated* by Level 2 are where
>> - Types T1, T2 and T are inf-sup types derived from IEEE754 formats
>> - of the same radix
>> - such that the underlying implementation supports "formatOf" for the
>>  corresponding point operations, in the needed rounding modes;
>> because these essentially come for free (I believe).
> 
> I don't think any mixed type operations should be mandated for
> interval arithmetic on such a system. Or are they really useful
> in practice? I think that a recommendation is sufficient: if
> they come for free, they will be implemented anyway (there may
> be some issues at the language level).
> 
> -- 
> 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 31 draft text V04.4, extra notes
> Date: April 5, 2012 8:38:53 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-04-04 10:51:24 -0500, Nate Hayes wrote:
>> In a nutshell, the issue as I recall boiled down to "unbounded" vs.
>> "overflown" intervals. To paraphrase Arnold Neumaier's distinction between
>> these two concepts:
>> 
>>   -- The "unbounded" interval [7,+Inf] is a single interval (set of real
>> numbers) with an upper endpoint that is not bounded.
>> 
>>   -- The "overflown" interval [7,+OVR] on the other hand is a family of
>> intervals. There are an infinite number of intervals in the family, but each
>> element of the family is closed and bounded.
> 
> By "overflown" interval, I suppose you meant interval as an element
> of some datatype, because mathematically, it is not an interval,
> but a family of intervals (with the semantics being that the "true"
> interval is an element of this family).
> 
> Anyway P1788 deals with "unbounded" intervals, not with "overflown"
> intervals (which would have been much more complex, IMHO, e.g. for
> \interior below).
> 
>> The correct definitions and/or interpretations of the comparison operations
>> depend on these distinctions. For example, from a purely mathematical
>> perspective the comparison of unbounded intervals
>>   [7,+Inf] \interior [1,+Inf]
>> is true; however as pointed out by Arnold the comparison of "overflown"
>> intervals
>>   [7,+OVR] \interior [1,+OVR]
>> is necissarily false.
> 
> There could be several ways to specify the latter case (you have two
> families of intervals, several ways to choose the quantifiers...);
> "false" is not a canonical answer.
> 
>> So if one interprets the comparision operations in Motion 13 in the light of
>> overflown intervals, then those endpoint formulas are correct.
> 
> P1788 should stick to a single choice: "unbounded" intervals or
> "overflown" intervals. Mixing choices is a very bad idea.
> 
>> There was a great deal of dissucssion at the time about what the endpoint
>> formula should be for unbounded intervals, instead, and this all led to very
>> complicated and slow implementations.
>> 
>> In my opinion, P1788 should consider restricting Level 1 to bounded
>> intervals and introduce "overflown" intervals at Level 2. After the recent
>> discussion on midpoint, it seems the committee is already leaning in this
>> direction anyways. It also means the formulas in Motion 13 which are very
>> simple and efficient could still be used for implementations.
> 
> I don't see the discussion on midpoint changing anything about such
> 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: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 5:24:14 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-04-05 15:35:18 -0500, Nate Hayes wrote:
>> Vincent Lefevere wrote:
>>> I agree. But there will be no "overflown" intervals at Level 2.
>>> AFAIK, the Level 2 choice for the midpoint on unbounded intervals
>>> has been done for practical reasons, not because of some notion
>>> of "overflown" intervals (if this is what you meant).
>> 
>> Nope. That's not what I meant.
>> 
>> What I meant is that at Level 1 there is no definition of midpoint for
>> unbounded intervals. So why include unbounded intervals in the Level 1
>> model?
> 
> because the midpoint is not the only function. For instance:
> 
>  1 / [0,1] = [1,+oo]
> 
> at Level 1 and Level 2 (+ some decorations).
> 
>> Especially when a similar treatment at Level 2 of "overflown"
>> intervals can provide the same practical benefits? IMO the Level 1
>> model is then cleaner and simpler.
> 
> I disagree: without unbounded intervals, you wouldn't have a closed
> arithmetic (except by introducing some form of NaI, but it wouldn't
> even be part of the set theory, and problems you could find with
> unbounded intervals would occur with NaI anyway).
> 
> -- 
> 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: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 8:46:42 AM CDT
> To: Vincent Lefevre <vincent@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> 
> Vincent Lefevre wrote:
>> On 2012-04-05 15:35:18 -0500, Nate Hayes wrote:
>>> Vincent Lefevere wrote:
>>> >I agree. But there will be no "overflown" intervals at Level 2.
>>> >AFAIK, the Level 2 choice for the midpoint on unbounded intervals
>>> >has been done for practical reasons, not because of some notion
>>> >of "overflown" intervals (if this is what you meant).
>>> 
>>> Nope. That's not what I meant.
>>> 
>>> What I meant is that at Level 1 there is no definition of midpoint for
>>> unbounded intervals. So why include unbounded intervals in the Level 1
>>> model?
>> 
>> because the midpoint is not the only function. For instance:
>> 
>> 1 / [0,1] = [1,+oo]
>> 
>> at Level 1 and Level 2 (+ some decorations).
> 
> We don't actually perform arithmetic in a computer at Level 1, and at
> Level 2 with overflow one has
>   1 / [0,1] = [1,+OVR]
> 
>> 
>>> Especially when a similar treatment at Level 2 of "overflown"
>>> intervals can provide the same practical benefits? IMO the Level 1
>>> model is then cleaner and simpler.
>> 
>> I disagree: without unbounded intervals, you wouldn't have a closed
>> arithmetic
> 
> It seems academic to me: we don't perform arithmetic in a computer at
> Level 1, (and the overflown arithmetic is closed at Level 2, btw).
> 
> When restricted to bounded intervals, the Level 1 arithmetic is closed and
> cancellative for addition, subtraction, multiplication and division with 0
> not in the denominator. This is the oldest interval arithmetic of Ramon
> Moore, etc. and has withstood the test of time already. IMO this is better than the current P1788 model with unbounded intervals.
> 
> Nate



Begin forwarded message:

> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 9:44:54 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-04-11 08:46:42 -0500, Nate Hayes wrote:
>> Vincent Lefevre wrote:
>>> On 2012-04-05 15:35:18 -0500, Nate Hayes wrote:
>>>> Vincent Lefevere wrote:
>>>>> I agree. But there will be no "overflown" intervals at Level 2.
>>>>> AFAIK, the Level 2 choice for the midpoint on unbounded intervals
>>>>> has been done for practical reasons, not because of some notion
>>>>> of "overflown" intervals (if this is what you meant).
>>>> 
>>>> Nope. That's not what I meant.
>>>> 
>>>> What I meant is that at Level 1 there is no definition of midpoint for
>>>> unbounded intervals. So why include unbounded intervals in the Level 1
>>>> model?
>>> 
>>> because the midpoint is not the only function. For instance:
>>> 
>>> 1 / [0,1] = [1,+oo]
>>> 
>>> at Level 1 and Level 2 (+ some decorations).
>> 
>> We don't actually perform arithmetic in a computer at Level 1, and at
>> Level 2 with overflow one has
>>   1 / [0,1] = [1,+OVR]
> 
> This is wrong. At Level 1, 1 / [0,1] is defined as the smallest
> (closed) interval that contains { 1 / x | x in [0,1] and x <> 0 },
> and this is [1,+oo]. At Level 2, the interval must contain [1,+oo]
> entirely. If [1,+OVR] means some interval [1,K] with K finite (but
> we don't which one), the result is incorrect, because for any K,
> [1,K] does not contain [1,+oo].
> 
>>>> Especially when a similar treatment at Level 2 of "overflown"
>>>> intervals can provide the same practical benefits? IMO the Level 1
>>>> model is then cleaner and simpler.
>>> 
>>> I disagree: without unbounded intervals, you wouldn't have a closed
>>> arithmetic
>> 
>> It seems academic to me: we don't perform arithmetic in a computer at
>> Level 1, (and the overflown arithmetic is closed at Level 2, btw).
> 
> But from the Level 2 results, one can deduce Level 1 results. This
> is what matters.
> 
>> When restricted to bounded intervals, the Level 1 arithmetic is closed and
>> cancellative for addition, subtraction, multiplication and division with 0
>> not in the denominator.
> 
> This is not the definition of a closed arithmetic. If you can get
> an interval as a result, say [0,1], you mustn't remove it from the
> possible inputs of an operation.
> 
>> This is the oldest interval arithmetic of Ramon Moore, etc. and has
>> withstood the test of time already. IMO this is better than the
>> current P1788 model with unbounded intervals.
> 
> P1788 needs a closed arithmetic.
> 
> -- 
> 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: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 10:03:43 AM CDT
> To: Vincent Lefevre <vincent@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> 
> Vincent Lefevre wrote:
>> On 2012-04-11 08:46:42 -0500, Nate Hayes wrote:
>>> Vincent Lefevre wrote:
>>> >On 2012-04-05 15:35:18 -0500, Nate Hayes wrote:
>>> >>Vincent Lefevere wrote:
>>> >>>I agree. But there will be no "overflown" intervals at Level 2.
>>> >>>AFAIK, the Level 2 choice for the midpoint on unbounded intervals
>>> >>>has been done for practical reasons, not because of some notion
>>> >>>of "overflown" intervals (if this is what you meant).
>>> >>
>>> >>Nope. That's not what I meant.
>>> >>
>>> >>What I meant is that at Level 1 there is no definition of midpoint for
>>> >>unbounded intervals. So why include unbounded intervals in the Level 1
>>> >>model?
>>> >
>>> >because the midpoint is not the only function. For instance:
>>> >
>>> > 1 / [0,1] = [1,+oo]
>>> >
>>> >at Level 1 and Level 2 (+ some decorations).
>>> 
>>> We don't actually perform arithmetic in a computer at Level 1, and at
>>> Level 2 with overflow one has
>>>   1 / [0,1] = [1,+OVR]
>> 
>> This is wrong. At Level 1, 1 / [0,1] is defined as the smallest
>> (closed) interval that contains { 1 / x | x in [0,1] and x <> 0 },
>> and this is [1,+oo]. At Level 2, the interval must contain [1,+oo]
>> entirely. If [1,+OVR] means some interval [1,K] with K finite (but
>> we don't which one), the result is incorrect, because for any K,
>> [1,K] does not contain [1,+oo].
> 
> In my recent e-mails I've said that the interval [1,+OVR] should be
> considered as a family of intervals: the number of elements in the family is
> inifinite, but each element is closed and bounded.
> 
> 
>> 
>>> >>Especially when a similar treatment at Level 2 of "overflown"
>>> >>intervals can provide the same practical benefits? IMO the Level 1
>>> >>model is then cleaner and simpler.
>>> >
>>> >I disagree: without unbounded intervals, you wouldn't have a closed
>>> >arithmetic
>>> 
>>> It seems academic to me: we don't perform arithmetic in a computer at
>>> Level 1, (and the overflown arithmetic is closed at Level 2, btw).
>> 
>> But from the Level 2 results, one can deduce Level 1 results. This
>> is what matters.
>> 
>>> When restricted to bounded intervals, the Level 1 arithmetic is closed
>>> and
>>> cancellative for addition, subtraction, multiplication and division with
>>> 0
>>> not in the denominator.
>> 
>> This is not the definition of a closed arithmetic. If you can get
>> an interval as a result, say [0,1], you mustn't remove it from the
>> possible inputs of an operation.
> 
> At Level 2 its not.
> 
>> 
>>> This is the oldest interval arithmetic of Ramon Moore, etc. and has
>>> withstood the test of time already. IMO this is better than the
>>> current P1788 model with unbounded intervals.
>> 
>> P1788 needs a closed arithmetic.
> 
> The practice of interval arithmetic has thrived for over 50 years based on
> Moore's Level 1 model. Where is the evidence to support your claim to the
> contrary?
> 
> BTW, where is your answer to my original question about a concrete example?
> All your points seem really academic to me.
> 
> The arithmetic can be closed at Level 2, anyhow, with overflown intervals.
> 
> For me, it is more important that the Level 1 arithmetic is cancellative,
> and the current P1788 model with unbounded intervals does not have this
> property.
> 
> Unbounded intervals are unnecessary.
> 
> Nate



Begin forwarded message:

> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 10:26:02 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-04-11 10:03:43 -0500, Nate Hayes wrote:
>> Vincent Lefevre wrote:
>>> On 2012-04-11 08:46:42 -0500, Nate Hayes wrote:
> [...]
>>>> We don't actually perform arithmetic in a computer at Level 1, and at
>>>> Level 2 with overflow one has
>>>>  1 / [0,1] = [1,+OVR]
>>> 
>>> This is wrong. At Level 1, 1 / [0,1] is defined as the smallest
>>> (closed) interval that contains { 1 / x | x in [0,1] and x <> 0 },
>>> and this is [1,+oo]. At Level 2, the interval must contain [1,+oo]
>>> entirely. If [1,+OVR] means some interval [1,K] with K finite (but
>>> we don't which one), the result is incorrect, because for any K,
>>> [1,K] does not contain [1,+oo].
>> 
>> In my recent e-mails I've said that the interval [1,+OVR] should be
>> considered as a family of intervals: the number of elements in the
>> family is inifinite, but each element is closed and bounded.
> 
> So, basically, you get something that is equivalent to an unbounded
> interval, but with a more complex definition!
> 
>>>> When restricted to bounded intervals, the Level 1 arithmetic is
>>>> closed and cancellative for addition, subtraction, multiplication
>>>> and division with 0 not in the denominator.
>>> 
>>> This is not the definition of a closed arithmetic. If you can get
>>> an interval as a result, say [0,1], you mustn't remove it from the
>>> possible inputs of an operation.
>> 
>> At Level 2 its not.
> 
> Do you mean that you have an operation at Level 2 with no
> corresponding operation at Level 1? This doesn't make sense.
> 
>>>> This is the oldest interval arithmetic of Ramon Moore, etc. and has
>>>> withstood the test of time already. IMO this is better than the
>>>> current P1788 model with unbounded intervals.
>>> 
>>> P1788 needs a closed arithmetic.
>> 
>> The practice of interval arithmetic has thrived for over 50 years based on
>> Moore's Level 1 model. Where is the evidence to support your claim to the
>> contrary?
>> 
>> BTW, where is your answer to my original question about a concrete example?
> 
> I've given an example in another mail.
> 
>> All your points seem really academic to me.
> 
> No, really, I need to compute ranges of functions (that can be defined
> by arbitrary expressions), and I need a correct answer.
> 
>> The arithmetic can be closed at Level 2, anyhow, with overflown intervals.
> 
> My point is that it must be closed at Level 1 too.
> 
>> For me, it is more important that the Level 1 arithmetic is cancellative,
> 
> It is cancellative on all the instances allowed by your model.
> So, you do not miss anything.
> 
>> and the current P1788 model with unbounded intervals does not have this
>> property.
> 
> Whatever model you choose, there are properties that will not be
> satisfied.
> 
>> Unbounded intervals are unnecessary.
> 
> for you.
> 
> -- 
> 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: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 11:43:46 AM CDT
> To: Vincent Lefevre <vincent@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> 
> Vincent Lefevre wrote:
>> On 2012-04-11 10:03:43 -0500, Nate Hayes wrote:
>>> Vincent Lefevre wrote:
>>> >On 2012-04-11 08:46:42 -0500, Nate Hayes wrote:
>> [...]
>>> >>We don't actually perform arithmetic in a computer at Level 1, and at
>>> >>Level 2 with overflow one has
>>> >>   1 / [0,1] = [1,+OVR]
>>> >
>>> >This is wrong. At Level 1, 1 / [0,1] is defined as the smallest
>>> >(closed) interval that contains { 1 / x | x in [0,1] and x <> 0 },
>>> >and this is [1,+oo]. At Level 2, the interval must contain [1,+oo]
>>> >entirely. If [1,+OVR] means some interval [1,K] with K finite (but
>>> >we don't which one), the result is incorrect, because for any K,
>>> >[1,K] does not contain [1,+oo].
>>> 
>>> In my recent e-mails I've said that the interval [1,+OVR] should be
>>> considered as a family of intervals: the number of elements in the
>>> family is inifinite, but each element is closed and bounded.
>> 
>> So, basically, you get something that is equivalent to an unbounded
>> interval, but with a more complex definition!
> 
> Exactly. The reasons for doing it this way are:
>   -- unbounded intervals are then completely unnecessary at any level
>   -- the absence of unbounded intervals at Level 1 means A = B
> when A + X = B + X
>   -- valid ranges for things like 1/[0,1]=[1,+OVR] can still be computed
> at Level 2 (which is where for a computational standard like P1788 it
> matters in the real world).
> 
>> 
>>> >>When restricted to bounded intervals, the Level 1 arithmetic is
>>> >>closed and cancellative for addition, subtraction, multiplication
>>> >>and division with 0 not in the denominator.
>>> >
>>> >This is not the definition of a closed arithmetic. If you can get
>>> >an interval as a result, say [0,1], you mustn't remove it from the
>>> >possible inputs of an operation.
>>> 
>>> At Level 2 its not.
>> 
>> Do you mean that you have an operation at Level 2 with no
>> corresponding operation at Level 1? This doesn't make sense.
> Sure it does.
> It all depends on the underlying axioms and definitions.
> 
> 
> 
>>> >>This is the oldest interval arithmetic of Ramon Moore, etc. and has
>>> >>withstood the test of time already. IMO this is better than the
>>> >>current P1788 model with unbounded intervals.
>>> >
>>> >P1788 needs a closed arithmetic.
>>> 
>>> The practice of interval arithmetic has thrived for over 50 years based
>>> on
>>> Moore's Level 1 model. Where is the evidence to support your claim to the
>>> contrary?
>>> 
>>> BTW, where is your answer to my original question about a concrete
>>> example?
>> 
>> I've given an example in another mail.
> Where?
> 
>> 
>>> All your points seem really academic to me.
>> 
>> No, really, I need to compute ranges of functions (that can be defined
>> by arbitrary expressions), and I need a correct answer.
> So do I. I can compute them at Level 2 with 1/[0,1]=[1,+OVR].
> I've never written a computer program that operates at Level 1. That's
> nonsense.
> 
> 
> 
>>> The arithmetic can be closed at Level 2, anyhow, with overflown
>>> intervals.
>> 
>> My point is that it must be closed at Level 1 too.
> Why? I haven't seen you give any compelling reason for this.
> 
>> 
>>> For me, it is more important that the Level 1 arithmetic is cancellative,
>> 
>> It is cancellative on all the instances allowed by your model.
>> So, you do not miss anything.
> So, it sounds to me you agree then that a Level 1 arithmetic that allows
> unbounded intervals is not cancellative.
> 
>> 
>>> and the current P1788 model with unbounded intervals does not have this
>>> property.
>> 
>> Whatever model you choose, there are properties that will not be
>> satisfied.
> At Level 1, I see it is a choice betwee closure and cancellation.
> IMO and experience, cancellation is the much more important property.
> 
>> 
>>> Unbounded intervals are unnecessary.
>> 
>> for you.
> 
> I'm still waiting for you or anyone else to show why they are *necessary*.
> So far I don't seen you've accomplished that.
> 
> Nate




Begin forwarded message:

> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 11:47:19 AM CDT
> To: Vincent Lefevre <vincent@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> 
> Nate Hayes wrote:
>>>> >>When restricted to bounded intervals, the Level 1 arithmetic is
>>>> >>closed and cancellative for addition, subtraction, multiplication
>>>> >>and division with 0 not in the denominator.
>>>> >
>>>> >This is not the definition of a closed arithmetic. If you can get
>>>> >an interval as a result, say [0,1], you mustn't remove it from the
>>>> >possible inputs of an operation.
>>>> 
>>>> At Level 2 its not.
>>> 
>>> Do you mean that you have an operation at Level 2 with no
>>> corresponding operation at Level 1? This doesn't make sense.
>> Sure it does.
>> It all depends on the underlying axioms and definitions.
> 
> BTW, in the current P1788 model, the midpoint operation is a prefect example of this because it is not defined at Level 1!
> 
> Nate



Begin forwarded message:

> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 4:43:32 PM CDT
> To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Cc: Vincent Lefevre <vincent@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
> 
> Nate, P-1788,
> 
> I'd like to point out that Motion 5, which passed 43 to 8,
> makes operations on unbounded intervals explicit.  The semantics
> are that the endpoints, i.e. -\infty and +\infty, are not
> actual numbers, but symbols used to describe an unbounded
> set of real numbers.  (As such, in some ways they are like
> numbers in the set, but in others, they are not.)  These
> semantics were pinned down in Motion 3, which passed 48 to 6.
> 
> If someone strongly disagrees with this, we can revisit the
> issue.  However, as acting chair, I'd like to discourage
> such churning, since we are already going to run into an
> extension of the working group's term, and I understand a
> second extension may be more difficult to obtain.  (That is,
> I'm a bit worried about finishing the document before IEEE gives
> up on us.)
> 
> Best regards,
> 
> Baker



Begin forwarded message:

> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 6:10:10 PM CDT
> To: <rbk@xxxxxxxxxxxxx>
> Cc: Vincent Lefevre <vincent@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> 
> Baker Kearfott wrote:
>> Nate, P-1788,
>> 
>> I'd like to point out that Motion 5, which passed 43 to 8,
>> makes operations on unbounded intervals explicit.  The semantics
>> are that the endpoints, i.e. -\infty and +\infty, are not
>> actual numbers, but symbols used to describe an unbounded
>> set of real numbers.  (As such, in some ways they are like
>> numbers in the set, but in others, they are not.)  These
>> semantics were pinned down in Motion 3, which passed 48 to 6.
> 
> I know. Didn't I address these things?
> 
> 
>> If someone strongly disagrees with this, we can revisit the
>> issue.  However, as acting chair, I'd like to discourage
>> such churning, since we are already going to run into an
>> extension of the working group's term, and I understand a
>> second extension may be more difficult to obtain.  (That is,
>> I'm a bit worried about finishing the document before IEEE gives
>> up on us.)
> 
> Baker:
> 
> I *do* want to do my best to help get a standard done on time, and I think
> I've contributed a lot to try and make that happen over the years. But I
> also want to do my best to make the standard something I would use in my own
> products and applications.
> 
> We all have something to learn just by being involved in the process. But I
> also worry about getting a standard done purely for the sake of getting it
> done. The best standard (and the truth) is probably hidden somewhere between
> those two worrisome ends of the spectrum.
> 
> For the record: I recognize it's not up to me what kind of standard the
> committe will produce, or for what reasons. I am just representing my
> individual point of view. Make of it what you will. I assume everyone is
> trying to make the best standard possible, whether they agree with me or
> not.
> 
> Nate



Begin forwarded message:

> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 6:15:29 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-04-11 11:43:46 -0500, Nate Hayes wrote:
>> Vincent Lefevre wrote:
>>> So, basically, you get something that is equivalent to an unbounded
>>> interval, but with a more complex definition!
>> 
>> Exactly.
> 
> I prefer a simple theory than a complex one.
> 
>> The reasons for doing it this way are:
>>   -- unbounded intervals are then completely unnecessary at any level
>>   -- the absence of unbounded intervals at Level 1 means A = B
>> when A + X = B + X
>>   -- valid ranges for things like 1/[0,1]=[1,+OVR] can still be computed
>> at Level 2 (which is where for a computational standard like P1788 it
>> matters in the real world).
> 
> Similarly, real numbers are unnecessary, because one can use
> sequence of rationals. The absence of irrational numbers means
> that one can write each rational under the form p/q. And one
> can still compute everything at Level 2 with rational numbers.
> Now I wonder why one uses real numbers in practice. :)
> 
>>>>>> When restricted to bounded intervals, the Level 1 arithmetic is
>>>>>> closed and cancellative for addition, subtraction, multiplication
>>>>>> and division with 0 not in the denominator.
>>>>> 
>>>>> This is not the definition of a closed arithmetic. If you can get
>>>>> an interval as a result, say [0,1], you mustn't remove it from the
>>>>> possible inputs of an operation.
>>>> 
>>>> At Level 2 its not.
>>> 
>>> Do you mean that you have an operation at Level 2 with no
>>> corresponding operation at Level 1? This doesn't make sense.
>> Sure it does.
>> It all depends on the underlying axioms and definitions.
> 
> A math problem is always expressed at Level 1, not at Level 2.
> 
>>> I've given an example in another mail.
>> Where?
> 
> The range of atan(1/x) over [0,1]. Could you give a complete proof
> of the result with your axioms and definitions?
> 
>>>> All your points seem really academic to me.
>>> 
>>> No, really, I need to compute ranges of functions (that can be defined
>>> by arbitrary expressions), and I need a correct answer.
>> So do I. I can compute them at Level 2 with 1/[0,1]=[1,+OVR].
>> I've never written a computer program that operates at Level 1. That's
>> nonsense.
> 
> for you only.
> 
>>>> The arithmetic can be closed at Level 2, anyhow, with overflown
>>>> intervals.
>>> 
>>> My point is that it must be closed at Level 1 too.
>> Why? I haven't seen you give any compelling reason for this.
> 
> Because it makes everything easier. Do you have a proof of the FTIA
> with your model?
> 
>> At Level 1, I see it is a choice betwee closure and cancellation.
>> IMO and experience, cancellation is the much more important property.
> 
> Silly. You're going nowhere with such claims: similarly I can say
> "I've never used cancellation, so IMHO, closure is the much more
> important property."
> 
> 2. Cancellation is still *valid* with the P1788 model when you do
> not use unbounded intervals (which is your case). So, I don't see
> why you're complaining.
> 
> BTW, cancellation is invalid at Level 2. That makes a good reason
> not to consider it.
> 
>> I'm still waiting for you or anyone else to show why they are *necessary*.
> 
> See my example (again). And the range of tan over [0,10].
> I want to use intervals, not useless complex things such as
> familly of 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: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 6:21:00 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-04-11 11:47:19 -0500, Nate Hayes wrote:
>> Nate Hayes wrote:
>>>>>>> When restricted to bounded intervals, the Level 1 arithmetic is
>>>>>>> closed and cancellative for addition, subtraction, multiplication
>>>>>>> and division with 0 not in the denominator.
>>>>>> 
>>>>>> This is not the definition of a closed arithmetic. If you can get
>>>>>> an interval as a result, say [0,1], you mustn't remove it from the
>>>>>> possible inputs of an operation.
>>>>> 
>>>>> At Level 2 its not.
>>>> 
>>>> Do you mean that you have an operation at Level 2 with no
>>>> corresponding operation at Level 1? This doesn't make sense.
>>> Sure it does.
>>> It all depends on the underlying axioms and definitions.
>> 
>> BTW, in the current P1788 model, the midpoint operation is a prefect
>> example of this because it is not defined at Level 1!
> 
> Not a good example:
> 
> 1. My preferred choice is to make it also undefined at Level 2 (NaN)
> on the cases it is undefined at Level 1.
> 
> 2. The midpoint function doesn't return an interval, meaning that
> the Level 2 result can be inexact, even when it is perfectly defined
> at Level 1. So, the user need to know that there are significant
> differences with Level 1 in many cases.
> 
> -- 
> 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: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 11, 2012 7:23:19 PM CDT
> To: Vincent Lefevre <vincent@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> 
> Vincent Lefever wrote:
>> On 2012-04-11 11:43:46 -0500, Nate Hayes wrote:
>>> Vincent Lefevre wrote:
>>> >So, basically, you get something that is equivalent to an unbounded
>>> >interval, but with a more complex definition!
>>> 
>>> Exactly.
>> 
>> I prefer a simple theory than a complex one.
>> 
>>> The reasons for doing it this way are:
>>>   -- unbounded intervals are then completely unnecessary at any level
>>>   -- the absence of unbounded intervals at Level 1 means A = B
>>> when A + X = B + X
>>>   -- valid ranges for things like 1/[0,1]=[1,+OVR] can still be computed
>>> at Level 2 (which is where for a computational standard like P1788 it
>>> matters in the real world).
>> 
>> Similarly, real numbers are unnecessary, because one can use
>> sequence of rationals. The absence of irrational numbers means
>> that one can write each rational under the form p/q. And one
>> can still compute everything at Level 2 with rational numbers.
>> Now I wonder why one uses real numbers in practice. :)
> 
> If you wish to simply admit you have a strong personal preference and opinion for unbounded intervals in the Level 1 model, I can accept and respect that. But in my view you fall flat on your face when you try to prove they are *neccessary*. :)
> 
> My model is another option. Maybe you don't like it, but that's not a scientific argument it is invalid or doesn't exist.
> 
> 
>> 
>>> >>>>When restricted to bounded intervals, the Level 1 arithmetic is
>>> >>>>closed and cancellative for addition, subtraction, multiplication
>>> >>>>and division with 0 not in the denominator.
>>> >>>
>>> >>>This is not the definition of a closed arithmetic. If you can get
>>> >>>an interval as a result, say [0,1], you mustn't remove it from the
>>> >>>possible inputs of an operation.
>>> >>
>>> >>At Level 2 its not.
>>> >
>>> >Do you mean that you have an operation at Level 2 with no
>>> >corresponding operation at Level 1? This doesn't make sense.
>>> Sure it does.
>>> It all depends on the underlying axioms and definitions.
>> 
>> A math problem is always expressed at Level 1, not at Level 2.
> A computer program can never truly be expressed at Level 1, but it can at Level 2.
> 
>> 
>>> >I've given an example in another mail.
>>> Where?
>> 
>> The range of atan(1/x) over [0,1]. Could you give a complete proof
>> of the result with your axioms and definitions?
> You've already agreed [1,+OVR] as an infinite family of intervals contains 1/[0,1].
> 
>> 
>>> >>All your points seem really academic to me.
>>> >
>>> >No, really, I need to compute ranges of functions (that can be defined
>>> >by arbitrary expressions), and I need a correct answer.
>>> So do I. I can compute them at Level 2 with 1/[0,1]=[1,+OVR].
>>> I've never written a computer program that operates at Level 1. That's
>>> nonsense.
>> 
>> for you only.
>> 
>>> >>The arithmetic can be closed at Level 2, anyhow, with overflown
>>> >>intervals.
>>> >
>>> >My point is that it must be closed at Level 1 too.
>>> Why? I haven't seen you give any compelling reason for this.
>> 
>> Because it makes everything easier.
> How? Please be specific!!
> 
>> Do you have a proof of the FTIA
>> with your model?
> No. But I know you will not help me do this because you have already made up your mind. So I will work on it with someone else.
> 
>> 
>>> At Level 1, I see it is a choice betwee closure and cancellation.
>>> IMO and experience, cancellation is the much more important property.
>> 
>> Silly. You're going nowhere with such claims: similarly I can say
>> "I've never used cancellation, so IMHO, closure is the much more
>> important property."
> Development of Kaucher arithmetic *requires* cancellation property!!!
> 
>> 
>> 2. Cancellation is still *valid* with the P1788 model when you do
>> not use unbounded intervals (which is your case). So, I don't see
>> why you're complaining.
> 
> There is a story about a Native American Shaman staring out into the bay as the first European ships of Christopher Columbus sat anchored on the horizon. Even though many people in his tribe stared directly at the ships they did not see them, because it was not something they were familliar with. But the Shaman sat on the shore. He stared for days, then weeks. Eventually he convinced himself they were real.
> 
> 
>> 
>> BTW, cancellation is invalid at Level 2.
> I already pointed that out just the other day.
>> That makes a good reason
>> not to consider it.
> There is no Kaucher arithmetic without cancellation property at Level 1. This is a fact. Perhaps that's not important to you. But if so, lets be clear about what we are really arguing about and stop all this nonsense.
> 
> Nate
> 



Begin forwarded message:

> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion 31 draft text V04.4, extra notes
> Date: April 16, 2012 9:27:35 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> 
> On 2012-04-11 19:23:19 -0500, Nate Hayes wrote:
>> My model is another option. Maybe you don't like it, but that's not a
>> scientific argument it is invalid or doesn't exist.
> 
> Anyway your supposed model (we have never seen any full specification)
> hasn't been chosen in the fist place. It is too late.
> 
>>> A math problem is always expressed at Level 1, not at Level 2.
>> A computer program can never truly be expressed at Level 1, but it can at
>> Level 2.
> 
> No, you're wrong (note: "expressed" != "implemented").
> 
>>>>> I've given an example in another mail.
>>>> Where?
>>> 
>>> The range of atan(1/x) over [0,1]. Could you give a complete proof
>>> of the result with your axioms and definitions?
>> You've already agreed [1,+OVR] as an infinite family of intervals contains
>> 1/[0,1].
> 
> No, I disagree. A family of intervals doesn't contain anything.
> Their union does. And the union is... an unbounded interval!
> 
>> Development of Kaucher arithmetic *requires* cancellation property!!!
> 
> The standard is not about the Kaucher arithmetic anyway.
> 
>>> BTW, cancellation is invalid at Level 2.
>> I already pointed that out just the other day.
> 
> + the fact that you do not want to work at Level 1, this makes it
> useless.
> 
> -- 
> 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)

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Prev by Date: Motion P1788/M0035.01:OverflowBeforeUnbounded -- discussion period begins
Next by Date: P1788: Summary, M0030.02 Constructors
Previous by thread: P1788: Summary, M0030.02 Constructors
Next by thread: Motion 0035 -- New levels 1 and 1a
Index(es):
- Date
- Thread