Fix: ufuncs with scalar-first arg now work on Variables (#486)

[gaoflow]

Fix: ufuncs with a scalar first arg now work on Variables

Fixes #486.

Problem

numpy ufuncs reach Variable subclasses via __array_priority__ = 100.0 and Variable.__array_wrap__, which preserves argument order: when the first argument is a scalar and the second is a Variable, __array_wrap__ wraps the scalar as a _Constant and calls _Constant._BinaryOperatorVariable(..., other=var). The result's class is then resolved by

baseClass = self._getArithmeticBaseClass(other)   # self = _Constant, other = var

…which returns None because neither isinstance(_Constant, CellVariable) nor isinstance(CellVariable, _Constant) holds. baseClass = None short-circuits _BinaryOperatorVariable to return NotImplemented, so every scalar-first ufunc call breaks:

>>> from fipy import Grid1D, CellVariable
>>> from fipy.tools import numerix
>>> import numpy as np
>>> mesh = Grid1D(nx=5)
>>> var = CellVariable(mesh=mesh, value=2.)

# All NotImplemented before this patch:
>>> numerix.fmax(0.1, var)
NotImplemented
>>> np.add(0.1, var)
NotImplemented
>>> np.subtract(0.1, var)
NotImplemented
>>> np.power(0.1, var)
NotImplemented
>>> np.minimum(0.1, var)
NotImplemented

# All work, even though the dispatch path is the same:
>>> numerix.fmax(var, 0.1)        # works
>>> 0.1 + var                      # works (goes through __radd__, not __array_wrap__)

The issue (#486, opened by @guyer) titles this "fmax with non-CellVariable" but the bug is much broader: every numpy ufunc with a scalar in the first slot — np.add, np.subtract, np.multiply, np.divide, np.power, np.minimum, np.maximum, np.fmin, np.fmax, … — fails the same way.

Fix

Apply the case @guyer sketched in the issue body:

elif isinstance(self, _Constant):
    return other._getArithmeticBaseClass()

When self is a bare _Constant wrapping a scalar/array, the result's class is dictated by other. The previously-handled cases (isinstance(self, other._getArithmeticBaseClass()) and isinstance(other, _Constant)) keep their original behaviour; this only fires when self itself is the _Constant.

Verification

All previously-broken ufuncs now produce CellVariable-typed results, with the correct non-commutative semantics preserved:

call	before	after
fmax(0.1, var=2.)	NotImplemented	[2, 2, 2, 2, 2]
fmin(0.1, var=2.)	NotImplemented	[0.1, 0.1, 0.1, 0.1, 0.1]
add(0.1, var=2.)	NotImplemented	[2.1, 2.1, 2.1, 2.1, 2.1]
subtract(0.1, var=2.)	NotImplemented	[-1.9, -1.9, -1.9, -1.9, -1.9]
divide(0.1, var=2.)	NotImplemented	[0.05, 0.05, 0.05, 0.05, 0.05]
power(0.1, var=2.)	NotImplemented	[0.01, 0.01, 0.01, 0.01, 0.01]

A doctest is added inline in Variable._getArithmeticBaseClass that exercises the _Constant._getArithmeticBaseClass(CellVariable) resolution and the numerix.fmax(scalar, var) == numerix.fmax(var, scalar) symmetry.

Test impact

$ python -c "import unittest, fipy.variables.test as t; \
              r = unittest.TextTestRunner(verbosity=0).run(t._suite()); \
              print(r.testsRun, len(r.failures))"
# baseline (master @ d8c21fd26):  112 27
# with this patch:                113 27

113 vs 112 = +1 doctest (the new one). 27 vs 27 = same baseline of pre-existing numpy-2.x repr drift in fipy/variables/* — none of those touch _getArithmeticBaseClass.

Scope

Only fipy/variables/variable.py: a four-line elif plus a doctest. No public API change.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}