Repository navigation
ArcSin, ArcCos, ArcTan, ArcCot, ArcSec, ArcCsc: precision from the condition number, as in WMA - #2055
Conversation
1620c8a to
3e3ef84
Compare
38d35ea to
a59edde
Compare
3e3ef84 to
866f038
Compare
a59edde to
c1efce4
Compare
866f038 to
86dc366
Compare
c1efce4 to
694522f
Compare
| @pytest.mark.parametrize( | ||
| ("str_expr", "str_expected", "msg"), | ||
| [ | ||
| ("Precision[ArcSin[0.3`20]]", "19.9863", None), |
There was a problem hiding this comment.
As in another PR, decide if you want to add something like a test using various kinds of 0, e.g. 020, 0.020.
There was a problem hiding this comment.
Added, with WMA 15 values. 020is an exact0and0.020 a machine 0., so ArcSin gives 0 and 0.; both were already right. 020(an arbitrary-precision zero) gets its error from how much the function changes near 0 (#2054):ArcSin[020] is 020, ArcCos[020] is Pi/2 with precision 20.1961.
Your suggestion on #2056, about formulas that divide by Sqrt[1 - x^2], applies here too, and it found a real bug: ArcSin[1.`20], ArcCsc[1.`20] and ArcSec[-1.`20] raised ZeroDivisionError. #2054 now has a fallback for where the condition factor does not exist: the error is how much the function changes within the error of its argument, leaving out a side where it has no real value. That gives ArcCos[1.`20] = 09.849andArcSec[-1.20]`` precision 10.3466, as in WMA, and the same next to 1. One deliberate difference: WMA gives ``ArcSin[1.20]precision `20.1961`, which does not agree with its ownArcCos[1.20]`` or ``ArcSin[0.999999999999999999920]`` (10.8465). Here it gets `10.0456`; the test notes it.
|
LGTM - decide if you want more tests. Merge when you feel ready. |
694522f to
48907e4
Compare
…ndition number Part of step 6 of #2047 (MATH-227), on top of the trig PR. As in WMA, the relative error of x is multiplied by Abs[x f'[x] / f[x]]: x / (Sqrt[1 - x^2] ArcSin[x]) for ArcSin, x / ((1 + x^2) ArcTan[x]) for ArcTan, and so on. ArcTan[x, y] gets its precision through its rules. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…tions As asked in review: mpmath numbers in and out, as for Power. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ArcSin, ArcTan, ArcCos and ArcCot of 0``20 get their error from how much they change near 0, as in WMA. ArcCot jumps at 0, and gets the error of the side where it is continuous. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
As suggested in review: where the formulas divide by Sqrt[1 - x^2] or by the value. ArcSin[1.`20] raised ZeroDivisionError; with the fallback in #2054 its error is how much it changes within the error of 1, as WMA does for ArcCos[1.`20] (0``9.849) and for ArcSin just below 1. Also 0`20 (an exact 0) and 0.0`20 (a machine 0.). WMA gives ArcSin[1.`20] and ArcCsc[1.`20] precision 20.1961, which does not agree with its own ArcCos[1.`20] or ArcSin[0.9999999999999999999`20]; here they get 10.0456. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
As suggested in review, edge cases next to poles and where the formulas divide by the value or by Sqrt[1 - x^2]. As in WMA: - Where the condition factor does not exist (a division by zero, an infinite factor, or a value of 0), the error is how much f changes within the error of its argument, as was already done for an inexact zero argument; a side where f has no real value is left out. This is what the inverse functions need at the ends of their domain (#2055, #2056), where ArcSin[1.`20] raised ZeroDivisionError. - A function with poles gives ComplexInfinity when no digit is left: Tan[N[Pi/2, 20]] and Tan[1.5707963`5] (was 0.`1.). Tan, Sec, Cot and Csc set has_poles. - A bounded function has an error no larger than its bound: Sin[1.`20*^30] is 0``0. Sin and Cos set value_bound. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
48907e4 to
58715b3
Compare
Part of step 6 of the outline in #2047. On top of the trigonometric PR, #2054: this diff is against its branch.
ArcSin,ArcCos,ArcTan,ArcCot,ArcSec,ArcCscget their precision from the condition numberAbs[x f'[x] / f[x]], as WMA does:x / (Sqrt[1 - x^2] ArcSin[x])forArcSin,x / ((1 + x^2) ArcTan[x])forArcTan, and so on.ArcTan[x, y]gets its precision through its rules.Precision[ArcSin[0.99`20]]20.19.308919.3089Precision[ArcCos[0.99`20]]20.18.304718.3047Precision[ArcTan[25.`20]]20.21.583621.5836Precision[ArcSec[-1.5`20]]20.20.410320.4103Precision[ArcTan[1.5`20, 2.5`20]]20.20.067420.0674A complex result, like
ArcSec[0.5`20], keeps the path it took before.Zeros
With the rule from #2054 for an inexact zero argument, as in WMA 15:
ArcSin[020]andArcTan[020]are020, andArcCos[020]andArcCot[020]`` arePi/2with precision `20.1961`. `ArcCot` jumps at 0, so its error comes from the side where it is continuous. Tested in `test_arctrig_real_valued_precision`.Tests
test_arctrig_real_valued_precisionintest/builtin/atomic/test_numbers.py, with WMA 15 values. 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