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

Re: Containment is necessary but not sufficient...

Yes, I do think we should be concerned in general about scope and focus,
in the interest of actually producing a standard in a reasonable amount
of time.  We also should be thinking about producing a test suite that
would certify compliance;  ideally, we would deliver that test suite
along with the standards document.

Best regards,

Baker

On 8/26/2011 8:08 AM, J. Wolff von Gudenberg wrote:

Dan, Nick, P1788
The problems discussed in the context of motion 28 -- mainly what must be specified by a standard and how --
were also topic of the face to face meeting in Tuebingen (see minutes on the Website). I started the meeting with the presentation of John's leveled structure, (see attached foils) and extended that for level 2 which contains implementable
data types.
We are currently mainly working in level 1 and I think that is good before we thus define a framework which specifies the common operations and can be instantiated for any arithmetic data type and representation on level 2

I think that we do not have the time to work on more than 1 concrete types and suggest that we proceed with the discussion of IEEE 754 (binary) interval in inf-sup representation, and drop all the others for specialists.

Nick's concern on implementing intervals on top of existng codes enters some language specific accuracy problems which have to be considered separately

Marco and Juergen

Am 26.08.2011 11:13, schrieb N.M. Maclaren:

On Aug 26 2011, Dan Zuras Intervals wrote:


Containment is necessary but not sufficient.

Not by a long shot.


I have omitted most of your remarks, which are correct but incomplete.
In addition to the requirements you state about a standard, there are
some even more important ones:

1) It must be sufficiently flexible to be useful for a significant
proportion of real, practical, scientific codes.

2) It must be sufficiently usable to deliver reasonable results
for the above set of codes.

3) It must be both specifiable and implementable, both in theory
and practice, for the above set of codes.

4) It must be compatible with the languages that people are going to
use it from, as those languages exist and are used.


If it fails on ANY of those, it will fail, just as 754 has failed to get
into programming languages; when the 754R project started, many people
had hopes that those problems would be addressed, but they weren't.

There are very good reasons that all languages in the past 50 years,
with the possible exception of Ada and the failed example of Java, have
produced what are the equivalent of 'containment-only' specifications
for their floating-point operations. Nobody knows how to do better, AND
meet all of the above requirements. That is not for lack of trying.

If you think that you can, fine. But let's see your horse before
agreeing to ride away on it. I think that you are specifying Pegasus.


Regards,
Nick Maclaren.





--

---------------------------------------------------------------
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
---------------------------------------------------------------