[tombouctou]

A follow-up to #2050 (part of #2047). Independent of #2051 and the PRs on top of it: this one is against master.

Since #2050, a sum or product that held an inexact zero took the old path. A zero's "precision" is its accuracy, and that path read it as a precision. Now, as in WMA:

• Plus: a zero adds its absolute error, 10^-accuracy, like any other term. A sum of zeros is a zero with the combined accuracy.
• Times: a product with inexact zeros is a zero. Its accuracy is the sum of theirs, minus Log10 of the other factors.
• Times: an exact 0 times arbitrary-precision numbers is an exact 0.

Input	master	this PR	WMA 15
Precision[1.5`20 + 010]``	10.	10.1761	10.1761
Precision[010 + 2]``	10.	10.301	10.301
Precision[10^-10 + 030]``	30.	20.	20.
Accuracy[010 + 020]	15.	10.	10.
Accuracy[1.5`20 - 1.5`20 + 030]``	15.	19.5229	19.5229
Accuracy[1.5`20 * 010]``	15.	9.82391	9.82391
Accuracy[010 * 020]	15.	30.	30.
0 * 1.5`20	0.`15.*^-15	0	0

Tests

test_inexact_zero_plus_times in test/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

[rocky]

lowercase tuple please. And I guess it should be removed elsewhere in this file wherever it appears. Thanks.

[tombouctou]

Done in 5d3395d: tuple[...] and list[...] throughout numeric.py, and the typing imports of Tuple and List are gone. The comments that named those types were updated too. mypy is clean on the file.

[rocky]

@tombouctou

With the code in this PR, I see:

In[4]:= SetAccuracy[0, 20] * 1.5`20
Out[4]= 0.×10^-20

WMA 13 gives 0.10^-19. Is this correct?

Possible additional pytest:

@pytest.mark.parametrize(
    ("str_expr", "str_expected"),
    [
        # exact zeros that are syntactically different from the literal 0
        ("(1 - 1) * 1.5`20", "0"),
        ("(1/2 - 1/2) * 1.5`20", "0"),
        ("SetPrecision[0, Infinity] * 1.5`20", "0"),
       # whatever the right test is for above example.
    ],
)
def test_exact_zero_propagates_through_equivalent_zero_forms(str_expr, str_expected):
    """An exact zero that is constructed internally must still force an exact zero."""
    check_evaluation(str_expr, str_expected)    

[tombouctou]

Good catch — the value was right but the display was wrong. SetAccuracy[0, 20] * 1.520 has accuracy 19.8239, the same as in WMA (0``19.823908740944322). WMA shows an inexact zero as 0.×10^-Floor[accuracy]`, so that gives `0.×10^-19`. We took the exponent from the rounded accuracy and got `-20`. This bug was already on master and shows up for any zero whose accuracy is not a whole number.

Fixed in 9081be6 (mathics/format/box/numberform.py). The exponent is now -Floor[accuracy], and never positive, so 0``-2.3 shows as 0. as it does in WMA. Values compared with WMA 15:

Input	before	now	WMA 15
0``20	0.×10^-20	0.×10^-20	0.×10^-20
0``20.5	0.×10^-20	0.×10^-20	0.×10^-20
0``19.5	0.×10^-20	0.×10^-19	0.×10^-19
SetAccuracy[0, 20] * 1.520`	0.×10^-20	0.×10^-19	0.×10^-19
0``-2.3	0.0	0.	0.

I added your suggested test test_exact_zero_propagates_through_equivalent_zero_forms (all three cases already gave 0), plus test_inexact_zero_output_form for the display.

Not changed here: zeros with a small accuracy (0``2.5 shows 0.00, WMA shows 0.), and the precision mark in InputForm (0.19.*^-19where WMA writes0``19.1`). Both behave the same as on master.

🤖 Generated with Claude Code

[mmatera]

LGTM