Re: Level 2 query, number 2 -- after review of Motion 19
John,
I think I see somewhat more clearly now what you were asking. It
appears our recent previous responses to your query were dealing with ways to
implement the specifications put down in Motion 19
(and corresponding revisions to the standard document),
right?
Is my following interpretation of Motion 19 OK, or did I miss something?:
1. In 3.5, point 9, in the main body, I find the statement
"Sets and operations are to be specified at a mathematical level,
e.g. specify the set as `all things having a certain property,' or by
giving a rule to decide whether a given thing belongs to the set" a
bit vague. I'm not sure an implementer would know what "mathematical level"
means, even with your example. It seems, combined with 3.2, this would
comprise no more than the "containment only" restriction that was
recently withdrawn. (That is, it appears this part of Motion 19
would make Motion 28 superfluous, except for the fact that, if I recall
correctly, we require at least one inf-sup type, whereas Motion 28 does not.
In other words, it appears we are allowing ``containment only'' data types,
but additionally require another data type with more closely specified structure.)
2. There don't seem to be restrictions on actually what the representation in IT is,
so the IT representation would not need to remind users at all of any mathematical
structure of the corresponding ID object. Thus, even though it is required to document
the conversion, the implementer could make the actual scheme arbitrarily difficult
to understand. What is actually implemented thus would depend on the motivations
of the implementer. Also, what would a validation test suite for such an implementation
look like, and who would be responsible for producing it?
That said, I find Motion 19 very accommodating of implementers desiring guidance for
a wide variety of innovative interval data types, I find it a clever way of doing so,
and I do not see how the language can be tightened or clarified without eliminating
at least some conceivable possibilities. Does someone have an idea of how to
clarify what is meant by "specified at a mathematical level?" Also, I was thinking
we could eliminate IT and stick with ``containment only'', but IT is what makes
it machine-independent. Is this correct?
Baker
On 9/5/2011 3:18 AM, John Pryce wrote:
Michel, Baker, George etc.
On 4 Sep 2011, at 23:37, Michel Hack wrote:
1. Every (bare) interval type T must have a loss-free way to write
any datum (i.e. interval) in T as text, and to read that text
back to recover the original datum exactly.
Assuming we're going back to the same representation (e.g. on the same
platform). Even then it needs the concept of recovery conversion
With respect, I think Michel's reply, and subsequent ones from Baker& George, are transverse to the main question I asked. For one thing they relate mainly to my "solution 5b"; not 5a or 5c. In fact isn't 5b a sort of encryption of the binary data? It's only because of our decimal heritage that we don't consider it weird.
We have chosen to lumber ourselves with... delete that, I know it is for a good reason -- chosen to support ... interval types beyond basic IEEE754 inf-sup. My basic point is philosophical with legal overtones:
Is the (documented) text representation of some exotic interval
type a sufficient basis for a "contract" between the supplier and
the user of that type?
(Maybe a figurative contract, but possibly a real one: I buy your
special interval hardware and you warrant it does X, Y, Z.)
Enabling data interchange between machines is useful but secondary. If what I ask for is done -- i.e. if there is an algorithm to convert text string to mathematical interval and back -- it is NECESSARILY possible, even from my laptop to a base 7 machine implemented by little green men on Mars scribbling on slates.
Inward versus outward rounding seems, to me, a complete red herring. Suppose I'm talking about FP datums whose internal format is 3-bit binary and I map the numbers 0, 0.125, 0.25, 0.375, ..., 0.875, 1, by round-to-nearest, to 1-digit decimal strings "0", ".1", ".3", ".4", ..., ".9", "1". Then I think converting back to 3-bit binary using round-to-nearest recovers the original numbers in each case.
Using the same method for intervals in the obvious way, xx = [0.25,0.625] converts to "[.3, .6]" converts back to xx. The fact that the interval [.3, .6] doesn't enclose xx is irrelevant. This particular text representation wasn't intended to be interpreted that way.
My question is about a "contract". Maybe not well expressed, and I hope someone can say it better.
John
--
---------------------------------------------------------------
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
---------------------------------------------------------------