Fix gain_correct and flat_correct on a non-default device

[mwcraig]

Part of #971 (the gain_correct/flat_correct device= bucket, plus the multiply/divide uncertainty-propagation bucket that sits directly behind it).

On the strict job this takes the failure count from 54 to 41 on top of main (ba758f0), with no new failures. The two strict xfail markers in test_ccddata_wrapper_for_array_api.py that covered the propagation leak started XPASSing and are removed; the 5 remaining XPASSes are the same stale test_cosmicray.py markers as on main.

Three commits:

1. gain_correct/flat_correct create the gain and the flat normalization on the device of the data. xp.asarray(gain_value) / xp.asarray(flat_mean) had no device=, so the scalar landed on the default device and the multiply/divide failed with "arrays from two different devices" when the image is elsewhere (core.py:968, :1057). Also, a plain-number gain is now made a float first: gain_correct(ccd, gain=3) produced an int64 array and the array API standard does not promote that with float64 data.

2. The wrapper's uncertainty mixin owns _propagate_multiply_divide. Astropy's version uses np.abs/np.sqrt, which convert the operands to numpy — silently on a CPU array (the result then fails at xp.sqrt), and with a RuntimeError on a non-default device. The override is astropy's formula with the numpy calls replaced by the array namespace's, and _propagate_multiply/_propagate_divide now call it. This is what makes gain_correct on an image with an uncertainty work on a non-default device.

3. Test bodies. The flats in test_flat_correct, test_flat_correct_norm_value and test_flat_correct_deviation were built on the default device while the image is on the testing device; test_flat_correct_data_uncertainty used a numpy uncertainty and .all() (not in the standard); test_gain.py multiplied a numpy float64 from Quantity.value into the array and was missing the asserts on its two xp.all(...) checks.

The one gain/flat test still failing on strict, test_ccd_process_gain_corrected, stops at the ccd_process builtin-bool bucket (core.py:383), which is separate.

🤖 Generated with Claude Code

https://claude.ai/code/session_01S36ZzAAVXVm32vuTdtCQME

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.47%. Comparing base (280f32f) to head (8f36710).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #993      +/-   ##
==========================================
+ Coverage   97.44%   97.47%   +0.02%     
==========================================
  Files           9        9              
  Lines        1761     1781      +20     
==========================================
+ Hits         1716     1736      +20     
  Misses         45       45              

Flag	Coverage Δ
dask	96.61% <100.00%> (+0.03%)	⬆️
jax	96.67% <100.00%> (+0.03%)	⬆️
numpy	97.36% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mwcraig]

Codecov's 5 missing patch lines (from its line-level report for ffa9337, not the summary) were all inside the new _propagate_multiply_divide:

line	what	resolution in 0772348
351	result_data = result_data.value	removed — result_data isn't used by the formulae at all; the parameter stays for signature compatibility with astropy
364, 383	the two uncertainty-unit conversion branches	removed — unreachable through the wrapper, which nulls the uncertainty units in _arithmetic_wrapper before doing arithmetic (and the branch also needs a parent unit, which the wrapper has removed too)
393	left = 0 (no uncertainty on self)	new test test_wrapped_arithmetic_uncertainty_only_on_operand — 3 uncertainty types × 4 ops, against astropy's numpy result. This is the flat_correct(ccd_without_uncertainty, flat_with_uncertainty) path
396	correlated uncertainties	new test test_wrapped_arithmetic_correlated_uncertainty — 3 uncertainty types × multiply/divide with uncertainty_correlation=0.5, against astropy's numpy result

Local coverage on numpy now reports no misses in that function. Full matrix on 0772348: numpy 546 passed, dask 539, jax 538 (7 xfailed); strict still 41 failed with the same set as before, 5 XPASS (the stale test_cosmicray.py markers).

One thing found while writing the correlation test, not fixed here: correlated add/subtract still leaks, because the wrapper delegates those to astropy's _propagate_add_sub, whose correlation term is np.sqrt(this * other). Uncorrelated add/subtract is fine. Added as a bullet to #971.

— Written by Claude at @mwcraig's direction.

[mwcraig]

Needs a proper numpy-style docstring

[mwcraig]

Agreed — the current docstring is a prose note with no Parameters/Returns. Proposed replacement, following the numpy-style used by propagate above:

        """
        Propagate uncertainty for multiplication or division.

        This is astropy's
        ``_VariancePropagationMixin._propagate_multiply_divide`` with the
        NumPy calls replaced by their array-namespace equivalents; see the
        astropy version for the derivation of the formulae. Unlike astropy's
        version this does not convert the uncertainties between units,
        because ``_CCDDataWrapperForArrayAPI._arithmetic_wrapper`` removes
        the units from the uncertainties before doing the arithmetic.

        Parameters
        ----------
        other_uncert : `~astropy.nddata.NDUncertainty`
            The uncertainty of the other operand. Its ``array`` and
            ``parent_nddata.data`` must be in the same array namespace as
            ``self.array``.
        result_data : array-like
            Accepted only for signature compatibility with astropy; the
            formulae do not use it.
        correlation : float or array-like
            Correlation coefficient between the two operands, ``0`` for
            uncorrelated.
        divide : bool, optional
            ``True`` for division, ``False`` (default) for multiplication.
        to_variance : callable, optional
            Converts the stored uncertainty array to a variance. Defaults to
            the identity, i.e. the uncertainty is already a variance.
        from_variance : callable, optional
            Converts a variance back to the stored uncertainty type. Defaults
            to the identity.

        Returns
        -------
        array-like
            The propagated uncertainty array, in the same array namespace and
            on the same device as the inputs, in the representation of
            ``self`` (as determined by ``from_variance``).
        """

Not applied on the branch yet; say the word and I'll push it.

— Written by Claude at @mwcraig's direction.

[mwcraig]

Applied in 8f36710.

— Written by Claude at @mwcraig's direction.

[mwcraig]

Shorten this.

[mwcraig]

Agreed — at five lines it's the longest entry in the section. Proposed four-line version that keeps all three fixes (the integer-gain cast is real: array-api-strict refuses int_array * float_array, so gain_correct(ccd, 2) failed there before this PR):

- Fix ``gain_correct`` and ``flat_correct`` for images on a non-default
  device: put the gain and flat normalization on the device of the data, cast
  an integer gain to float, and keep the uncertainty propagation for
  multiplication and division out of NumPy. [#993]

Not applied on the branch yet.

— Written by Claude at @mwcraig's direction.

[mwcraig]

Applied in 8f36710.

— Written by Claude at @mwcraig's direction.