| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Vincent, On 03/12/2013 11:08 AM, Vincent Lefevre wrote:
On 2013-03-12 10:30:12 -0500, Ralph Baker Kearfott wrote:Is this argument meant to help us come to a consensus on what accuracy (if any) we are to demand of the end points of enclosing intervals for the elementary functions in P-1788, i.e. what should be in the second column of Table 8, p. 43 of the draft John just passed around. Are we saying the "accurate" requirement for "sin" might be too strict?Perhaps, in particular because of the fact that the rounding direction is not necessarily honored mainly the math functions. But it may also not be available, e.g. in case of static rounding modes, in which case the arithmetic operations (+, -, *, /, sqrt) are affected too. So, the only requirements could be containment ("valid" accuracy mode) and other accuracy modes could be recommendations. But for 754-conforming P1788 implementations, you can add the associated "tightest" requirements for each supported function (this includes the required functions +, -, *, /, etc.).
Thank you. That helps a lot.
Acting as chair, I am concerned about getting a consensus among
ourselves on and DELIVERING A RATIFIED document within the
next 8 months or so. As such, I would feel I was remiss in my
duties if I didn't try to focus the discussion towards consensus on
the entire document. Although rehashing things we have already discussed
has educational value and general discussion can lead to new, good
results and constructs, the mission of this working group is to produce
an official standard.
Personally, I like the idea of accuracy as specified in Table 8 tied to
the 754 requirements the optional elementary functions,
for 754 data type; that is, if a function is provided for
a 754 data type, it shall be tight. For a general data type,
a simple containment requirement could suffice. If there are no objections
or controversy, I suspect John will write this into the draft
and we will vote directly on the wording. Otherwise, someone
should formulate and post motions.
I personally think having several levels of accuracy for general
data types could easily add complication and controversy and
thus derail the standard at this point, unless we can do it
clearly and simply.
A note from Juergen: A quality of implementation issue: It should
be possible to specify various accuracy levels.
(Juergen is presently sitting next to me.)
Best regards,
Baker
--
---------------------------------------------------------------
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
---------------------------------------------------------------