Bug fix for complex division of numpy.complex

[KarsKnook]

No description provided.

[jorgensd]

Could you add a regression test for this bug?

[pbrubeck]

I think it is hard to add a pure UFL test for this bug, as it would be caused by UFL subclasses that can carry data, such as a Firedrake Constant. As far as I understand, the only objects that can carry data are ComplexValue, but they immediatly cast the data to a complex.

[jorgensd]

I think it is hard to add a pure UFL test for this bug, as it would be caused by UFL subclasses that can carry data, such as a Firedrake Constant. As far as I understand, the only objects that can carry data are ComplexValue, but they immediatly cast the data to a complex.

Could you refer to a test in firedrake that exposed this but then and is fixed with the branch?

[pbrubeck]

Here's the test failing without this PR https://github.com/firedrakeproject/firedrake/actions/runs/13138641306/job/36660067475#step:7:13510

And we are passing after this PR
https://github.com/firedrakeproject/firedrake/actions/runs/13139851956/job/36664113488?pr=4010#step:7:4354

[jorgensd]

@pbrubeck wouldn't this be resolved in firedrake if firedrake.Constant would inherit from ScalarValue rather than ConstantValue (https://github.com/firedrakeproject/firedrake/blob/ecac12bc9763f0e37e62bf5e32d5bff17d6067cd/firedrake/constant.py#L42) as that would then hit: https://github.com/FEniCS/ufl/blob/main/ufl/algebra.py#L225-L231 instead?
Or am I missing some motivation here?
Edit:
Ignoring this potential simplification/change in firedrake, I've made a native test with a PR into this branch at: firedrakeproject#59

[pbrubeck]

A firedrake.Constant is a rather complicated object, I defer to @connorjward. From the discussion in firedrakeproject/firedrake#2376 I think this PR should go through regardless.