[tombouctou]

Stacked on #2066 (base complex-precision), which already reworks Log. Once #2066 merges, this PR's base moves to master.

In WMA, when the value of a function is 0, its error is the change of f within the error of each argument, with the other arguments held fixed, and these changes are summed. So Log[1.`20] is 020., and Log[b, 1.20]`` has accuracy P + Log10[Abs[Log[b]]]: ``Log[2, 1.20]is019.84 and Log10[1.`20] is 020.36. The error of the base does not change a zero value: Log[2.20, 1.25]`` has accuracy 24.8408.

• The change within an error is now the leading Taylor term c δ^p at the size of the error, as in WMA. The step is measured at δ 2^-40 and at half of that, and p is rounded to a multiple of 1/2. Before this PR the change was measured at the error itself, which is wrong at low precision. This fixes other functions too: Sin[01.5]now has accuracy 1.5 (it was 1.50007),Cos[02] 4.30103, ArcCos[1.`3] 1.34949 and Log[1.`3] 3. The test value for Accuracy[ArcCos[1.`5]] changes from 2.34948 to 2.34949, which is what WMA gives.
• Special points of Log. Before this PR, Log[1.`20, 1.`20] raised ZeroDivisionError inside mpmath, on master as well. Now, as in WMA:
  • an inexact 0 in either argument gives Indeterminate;
  • a base that is 1, or whose error covers 1 (machine 1. included), gives ComplexInfinity, or Indeterminate when x is or covers 1 too;
  • an exact x = 1 with any other base gives an exact 0: Log[2.`20, 1] is 0.
• MPMathFunction.special_point_value takes over the old indeterminate_at check, so a function can name its own special values; Log overrides it.

Tests are in test_log_zero_precision, next to test_real_valued_precision, and all the values come from WMA 15.

Left for later, as before this PR:

• complex cases such as Log[1.`20 + 020 I]andLog[-1.20, 1.20]``;
• Log[2.`20, 1.00000000000000000001`20], because the parser stores slightly different bits than WMA;
• Log[1.`0.5], because of the shared precision < 1 guard;
• Power of an inexact zero (Log[2, 1.`20]^2, Sqrt[03]``).

Locally, test_numbers.py, test/builtin/numbers, test/eval and the special-function tests give 1180 passed and 1 xfailed. black, isort and mypy report nothing.

🤖 Generated with Claude Code

[rocky]

@tombouctou: I'd be grateful if you would handle the merge conflicts. Thanks!

[rocky]

LGTM

[rocky]

@tombouctou and @mmatera : There is a lot of very, very useful information contained in the PRs regarding precision and accuracy.

This information should be collected and promoted somewhere to make this information more easily accessible.

One possibility is

mathics-core/mathics/doc/documentation/1-Manual.mdoc

Line 238 in 5312aab

<section title="Precision and Accuracy">

Another possibility is the developer's guide: https://mathics-development-guide.readthedocs.io/en/latest/

Thoughts?

[rocky]

And another possibility might be to create a Jupyter notebook with this kind of information.

And the same thing for matching rule and element order precedence

[tombouctou]

Thanks, good idea. I'd split it by reader:

• User-facing behavior goes in the Manual's "Precision and Accuracy" section, as you suggest. There every example is a doctest, so it stays checked against the code. That's Manual: how precision and accuracy carry through computations #2069: errors in sums and products, the condition number for functions, zero values and poles, complex numbers, machine numbers, N with $MaxExtraPrecision, SetPrecision/SetAccuracy. All values are from WMA 15.
• Internals (PrecisionReal's stored precision and 64-bit value, condition_numbers, special_point_value, the second pass of N) go in the developer's guide, in a separate PR there.

Rule matching and element order precedence would follow the same way, as a separate PR.

A notebook is a nice idea, but it isn't checked by CI, so I'd start with these two.