[tombouctou]

Part of step 6 of the outline in #2047. On top of #2053 (#2052, #2051): this diff is against #2053's branch.

Sin, Cos, Tan, Cot, Sec, Csc get their precision from the condition number Abs[x f'[x] / f[x]], as WMA does. Each function only adds its condition_numbers (see #2052). Where f[x] is small, the formula uses the value already computed, so the digits lost near a zero are measured at full precision.

Input	before	this PR	WMA 15
Precision[Sin[1.5`20]]	20.	20.9732	20.9732
Precision[Sin[100.`20]]	20.	17.7688	17.7688
Precision[Sin[3.14159265358979`20]]	20.	5.01319	5.01319
Precision[Cos[1.5`20]]	20.	18.6746	18.6746
Precision[Tan[100.`20]]	20.	17.6401	17.6401
Precision[Sec[0.3`20]]	20.	21.0324	21.0324

Zeros (added in review)

As in WMA 15. An exact zero stays exact (Precision[Sin[0]] is Infinity), and a result that cancels to zero keeps an accuracy (Accuracy[Sin[N[Pi, 20]]] is 19.5029); both were already right. Fixed here:

• An inexact zero argument has an absolute error only. Its error in the result is how much f changes within 10^-accuracy of 0: Sin[020]is020 (was 015), and Cos[020] is 1 with precision 40.301 (was 20.). This is in the shared helper from Power, Sqrt: precision from the condition number, as in WMA #2052. It takes the smaller change of the two sides, so a jump at 0, as ArcCot has, does not count. It applies to an accuracy of at least 1.
• Cot and Csc of an inexact zero (0. or 020``) are ComplexInfinity. They stayed unevaluated.

Tests: test_trig_zero.

Tests

test_trig_real_valued_precision in test/builtin/atomic/test_numbers.py, with WMA 15 values at three points per function. Full run on kimmy: doctests all pass. The pytest failures are the ones that depend on the order the tests run in; the failing files that touch numbers pass on their own.

🤖 Generated with Claude Code

[rocky]

Looks good, but please let's add type annotations for the new functions.

[rocky]

Looks good, but please let's add type annotations for the new functions.

Thanks for handling this suggestion.

[tombouctou]

Thanks. Added in 86dc366: each condition_numbers takes (x: mpmath.mpf, value: mpmath.mpf) and returns tuple[mpmath.mpf]. They stay mpmath numbers rather than floats, so that a tiny factor does not underflow to 0. (see the reply on #2053). The same annotations are now in #2052 (the hook and Power), #2053, #2055 and #2056. mypy is clean on these files.

With #2051 merged, the stack is rebased onto master: #2052 is now against master, and each PR above it against the one below.

[rocky]

Do we want to add checks for edge cases like when the numerator is 0?

In[1]:= Precision[Sin[0]]
Out[1]= Infinity

[tombouctou]

Thanks, I added the zero cases (c568255 and d4d90e4), checked against WMA 15:

Input	before	now	WMA 15
Precision[Sin[0]]	Infinity	Infinity	Infinity
Accuracy[Sin[N[Pi, 20]]]	19.5029	19.5029	19.5029
Accuracy[Sin[020]]``	15.	20.	20.
Precision[Cos[020]]``	20.	40.301	40.301
Cot[0.], Csc[0.]	unevaluated	ComplexInfinity	ComplexInfinity
Cot[020], Csc[020]	unevaluated	ComplexInfinity	ComplexInfinity

The first two were already right: an exact zero stays exact, and a result that cancels to zero keeps an accuracy. They are now tested.

The other two cases were wrong:

• Inexact zero argument. It has an absolute error but no relative one, so the condition number does not apply. As in WMA, its error in the result is how much f changes within 10^-accuracy of 0. So Sin[020]is020, and Cos[020]`` is 1 with precision 40.301, because `Cos` changes by only `(10^-20)^2/2`. This happens in the shared helper from Power, Sqrt: precision from the condition number, as in WMA #2052, so the inverse trigonometric and hyperbolic functions get it too; ArcSin, ArcCos, ArcTan, ArcCot, ArcSec, ArcCsc: precision from the condition number, as in WMA #2055 and Hyperbolic functions and their inverses: precision from the condition number, as in WMA #2056 have their own tests. I take the smaller change of the two sides: for a continuous function both sides agree, and `ArcCot` jumps at 0 on one side. The rule applies to an accuracy of at least 1; on a wider interval, looking at its ends would not bound `f`, so those keep the old path.
• Division by zero. Cot and Csc of 0. or 020`` stayed unevaluated. They now give ComplexInfinity through a rule `Cot[z_Real /; z == 0]`, as `Cot[0]` did already. In Hyperbolic functions and their inverses: precision from the condition number, as in WMA #2056, `Csch` gets the same rule; `Coth[0.]` already had one.

One case is left as it was: an inexact zero that gives a complex result, like ArcCosh[020]``. Complex results all still take the old path, and they are a separate item.

[rocky]

LGTM. Decide if you want to add the divide by 0 cases which report Infinity. Then feel free to merge.

[tombouctou]

One more commit since your LGTM (78a0b39), from the edge cases you suggested on #2056:

• Poles: Tan[N[Pi/2, 20]] and Tan[1.5707963`5] gave 0.`1.; they now give ComplexInfinity, as in WMA. Tan, Sec, Cot, Csc set has_poles.
• Bounds: Sin[1.`20*^30] is 00``: when no digit is left, a bounded function has an error no larger than its bound. Sin and `Cos` set `value_bound = 1.0`.
• Fallback where the condition factor does not exist (a division by zero, an infinite factor, or a value of 0): the error is how much the function changes within the error of its argument, as for a zero argument. This fixes the ZeroDivisionError that ArcSin[1.`20] raised in ArcSin, ArcCos, ArcTan, ArcCot, ArcSec, ArcCsc: precision from the condition number, as in WMA #2055.

All checked against WMA 15 and tested in test_trig_zero.