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

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





--- Comment #17 from Michael Kay <mike@saxonica.com>  2010-07-19 14:07:19 ---
Concerning points 1-5 in the original bug report, the WG accepted the editor's
assurance that he had fixed the spec along the lines suggested.

Concerning points 6-7 in the original bug report, the WG decided to specify the
functions such as sin(), cos(), sqrt() etc by reference to the IEEE 708
specification, allowing latitude (for example, different rounding modes,
different overflow behavior) where the IEEE specification allows latitude. The
concept of returning the value "either side of" the mathematical result will
therefore disappear from the spec.

Concerning comment #6 raised by myself, the WG decided to add the following
functions: exp, exp10, log, log10, pow, powr, and atan2, defined in terms of
the IEEE 708 specification. This decision was supported by informal discussion
of use cases. There was no specific direction on how the functions should be
named. 

* exp, log, log10, and atan2 exist under those names in both Java and .NET as
well as in IEEE, so there seems no reason to use a different name, despite the
fact that ln is possibly more familiar to mathematicians. 

* powr is available under the name pow in Java and .NET. I propose that we
define the two IEEE functions as overloads of a single pow() function in F+O,
using the semantics of pow when the second argument is an integer, and powr
otherwise. (IEEE defines pow only for floating point. We could argue that given
our type system, pow(10, 6) should return an integer. However, on some
implementations integer arithmetic will quickly overflow. A possible solution
is to define pow(double, double)->double, and ipow(int, int)->int where the
second argument is required to be non-negative.

* exp10 does not appear to be directly supported in Java or .NET. The function
call exp10(x) is equivalent to pow(10, x) except possibly in the exact type or
precision of the result. In our environment I suspect most use cases for exp10
are better handled with decimal arithmetic rather than binary floating point,
so I propose to leave this one out.

It was noted in discussion that we don't make the constant e available
directly, but that the mathematically literate will be comfortable with writing
exp(1).

As no positive resolution of this bug is contained in the draft minutes of the
meeting, I'm leaving the status as NEW until such a resolution is confirmed.

-- 
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, 19 July 2010 14:07:22 UTC