P-1788,
Do I have someone to formally move what is proposed here? If someone
moves it,
the actual wording to be posted would be as follows, whereas the rationale
(including the correspondence from other schemes) could be taken from
the portion of the same email from Arnold preceding leading up to this
actual proposal.
(If this is moved and seconded, I will postpone voting on Motion 22, so
the voting can run simultaneously. This is consistent with various
suggestions.)
Sincerely,
Baker
P.S. It seems all of the discussion about decorations is beginning to pay
off.
We are beginning to see some clear alternatives.
On 10/10/2010 06:15, Arnold Neumaier wrote:
Nate Hayes wrote: [Re: Discussion paper: what are the level 2 datums?]
Arnold Neumaier wrote:
Nate Hayes wrote:
Arnold Neumaier wrote:
Nate Hayes wrote:
Arnold Neumaier wrote:
.
.
.
========================================================================
It is proposed that precisely the following five decorations shall be
available:
dec = 0: safe = everywhere defined, continuous, and bounded)
dec = 1: everywhere defined
dec = 2: possibly everywhere defined
dec = 3: nowhere defined
dec = 4: not valid
In all interval exchange formats, a decoration is encoded by an
unsigned integer dec taking one of the values 0, 1, 2, 3, or 4.
The encoding in a datatype is left to the implementor.
The following unary predicates shall be provided for bare decorations
and for decorated intervals of any supported idatatype:
isValid dec<4
possiblyNonempty dec<3
everywhereDefined dec<2
isSafe dec<1
notValid dec>3
isEmpty dec>2
possiblyUndefined dec>1
notSafe dec>0
======================================================================
Since this is not fully compatible with Motion 22, it would preferably be
decided
> simultaneously with the latter.
Arnold Neumaier
A portion of the rationale:
> If the d&c bit is replaced by a d&c&b bit, the match is perfect, with
> domain = (d1,d2) and d&c&b = d3:
>
> dec d1 d2 d3 v d c b
> 0 T F T + + + + (safe =
> (everywhere defined, continuous, and bounded)
> 1 T F F + + 0 0 (defined)
> 2 T T F + 0 0 0 (possibly defined)
> 3 F T F + - 0 0 (nowhere defined)
> 4 F F F - 0 0 0 (not valid)
>
> Remarkably, the encoding of these decorations by a single uint3 gives
> simple tests for those decoration properties that are important for
> algorithmic tests:
>
> isValid dec<4 d1||d2||d3 v
> possiblyNonempty dec<3 d1 v & d>=0
> everywhereDefined dec<2 d1 && ~d2 v & d
> isSafe dec<1 d3 v & d & b & c
>
> notValid dec>3
> isEmpty dec>2
> possiblyUndefined dec>1
> notSafe dec>0
>
> Thus the encoding into d1-d3 or v d b c or any other scheme can be left
> to the implementor, whereas the uint3 representation should be required
> as an interchange format.
>
> The resulting scheme is simple, easy to understand, easy to encode, and
> serves all practical purposes that are important for optimiztion,
> equation solving, and ODEs. (One extra sign bit would easily fit in by
> using int4 in place of uint3, should someone really need more.)
>
>
> If someone likes this scheme, here is a proposed wording for a possible
> motion:
>
--
---------------------------------------------------------------
R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
(337) 482-5270 (work) (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------