|
P1788.1,
I CERTAINLY can make mistakes, but the recent motions I show are
M0003.01 Decoration system
M0004.02 Clause 6
However, if there is any doubt about a Motion 5, it is better to err by having no Motion 5 than to err by having two.
Unless someone else can confirm NO motion 5, I suggest we call this one Motion 6 to avoid any (further) hint of confusion.
George Corliss
I thought we already had a P1788.1 Motion 5.1, below . . .
Should the new one be 6.1? Or was the old 5.1 renumbered? Or disappeared?
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
----- Forwarded by Ian McIntosh/Toronto/IBM on 2016-09-26 04:49 PM -----
From: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>
To: Ian McIntosh/Toronto/IBM@IBMCA
Date: 2016-08-08 02:45 AM
Subject: Re: Motion P1788.1/M005 to avoid non-conforming interval standards
I would like to suggest a solution for 1788.1 which is compatible
with sections 9.8 "Constructors" and 7.5.3 "Level 2 operations"
of the "General Requirements" part of the standard 1788.
1788 defines syntax of interval literal by grammar 9.7.6 .
Each interval literal matches the syntax.
However, there may be a string which matches the syntax but which is not an interval literal.
These are strings [l,u] where l and u are number literals but l > u.
The syntax for Interval literals in 1788.1 would be the same as in 1788.
However 1788.1 has a relaxed support for those strings which
contain rational literals or which are mixed-radix [l,u] strings
where one of l or u is a decimal literal and another is a hexadecimal literal.
If string s doesn't match the syntax of 1788 interval literals
level 1 constructor is undefined
1788.1 level 2 constructor must return Empty bare interval or NaI decorated interval.
If string s matches the syntax of 1788 interval literal and its support by 1788.1 is not relaxed
then 1788.1 must determine
either string s is an interval literal
or it is not an interval literal (when s=[l,u] and l>u).
If it is an interval literal and its level 1 value is x
then 1788.1 level 2 constructor must return hull(x).
If it is not an interval literal then 1788.1 level 2 constructor must return Empty or NaI.
If string s matches the syntax of 1788 interval literal and its support by 1788.1 is relaxed,
then:
a) if string s is an interval literal with level 1 value x.
1788.1 level 2 constructor may return any interval which contains x.
b) if string s = [l,u] is not an interval literal because l > u.
Level 1 constructor has not value.
1788.1 level 2 constructor may return
either Empty/NaI
or any interval which contains [u,l] .
Notice that the easiest behavior of 1788.1 level 2 constructor is to return Entire
when support of input string s is relaxed in 1788.1.
-Dima
----- Original Message -----
From: rbk5287@xxxxxxxxxxxxx
To: mhack@xxxxxxx,
stds-1788@xxxxxxxxxxxxxxxxx
Sent: Monday, August 8, 2016 2:18:26 AM GMT +03:00 Iraq
Subject: Re: Motion P1788.1/M005 to avoid non-conforming interval standards
What if it is stated in 1788.1 that the result of mixed radix interval
literal conversions is system dependent (i.e. not specified in 1788.1)?
Thus, if mixed radix interval literal conversions are not used in a
program, a program conforming to 1788.1 will run the same on a
1788-conforming system. This difference could be prominently
explained in the 1788.1 document. 1788.1 would then be a "subset" of
1788 in the sense that less is specified.
Correcting a possible error in 1788 might be another matter. However,
is it an actual error (i.e. and inconsistency) or a specification that
is inadvisable due to difficulty of implementation?
Baker
On 08/07/2016 05:09 PM, Michel Hack wrote:
> On Sun, 7 Aug 2016 14:21:21 -0700 (PDT), Dima wrote:
>> I believe that interval literal is the only topic where behavior is different.
>
> The big deal is that 1788 allows <lower,upper> to specified in mixed radices,
> and we want to avoid this in 1788.1 because determining whether lower<=upper
> is difficult -- and in any case, 754 does not support mixed-radix comparisons.
>
> We may have made a mistake in allowing mixed-radix interval literals in 1788.
>
> In general mixed-radix support is easier in an interval standard than in a
> pure numeric standard, because we can always enclose a result. It's even
> easy to support tightest mode for basic arithmetic, except possibly for
> the unlikely case where both decimal and binary mpfr-based types are used.
> There should be no prohibition of mixed-radix arithmetic. But literals
> are a different story, because text input is in fact unbounded-precision.
>
> So we have an explicit escape clause, "unable to decide whether interval
> exists", and I don't think we want that in 1788.1 -- it's complicated.
>
> Michel.
> ---Sent: 2016-08-07 22:25:25 UTC
>
--
---------------------------------------------------------------
Ralph 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
---------------------------------------------------------------
|