[Bug 10073] Problems with the definitions of the trigonometric functions (math:)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10073





--- Comment #2 from Michael Kay <mike@saxonica.com>  2010-07-05 12:29:54 ---
1. (trigonometric/trigonometrical) Fixed. My dictionary has both adjectives,
but I will accept your advice that the shorter is to be preferred.

2. the entry in the table is a copy of the "Summary" of the function. It's
intended to give some useful information about the function without being a
complete specification. I think it's useful to say for sin/cos/tan that the
argument is in radians, it's not useful for these to say what the range is
since there's no doubt about the matter. For asin/acos/atan, it's useful to say
that the result is in radians, and since the range is in some sense arbitrary,
it's useful to say what range we have chosen.

3. ("range") fixed. (In most cases the limits of the range are some multiple of
pi, so it's clearly exclusive; in the one case where one of the bounds was
zero, the range is clearly inclusive at that end.)

3. (pi) fixed.

4. (sqrt) fixed. I have also changed the specification so that the square root
of negative zero is positive zero as this seems more consistent, but I'm open
to persuasion on this.

6, 7. I took input here from the Java and .NET specifications. Java states "The
computed result must be within 1 ulp of the exact result. Results must be
semi-monotonic". A ulp is defined as "The ulp of a specific real number value
is the distance between the two floating-point values bracketing that numerical
value". Apart from the requirement to be semi-monotonic, I believe my
formulation is equivalent, and that it can be implemented by using the usual
iterative-approximation approaches with a sufficiently small epsilon. I believe
I also found some material on the precision guaranteed by the .NET methods, but
I can't now find it. This input is probably what led me to the idea of offering
a guaranteed precision only for inputs in some range; I suspect the original
logic was to permit an implementation that started by taking the input value
modulo 2*pi, and then getting the nearest value, despite the fact that this
two-step approach may increase the error. I agree there's more work needed
here.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 5 July 2010 12:29:55 UTC