Fix dependent parameter division expressions triggering infinite recursion

[Copilot]

Dependent parameter expressions like "jump_length / angstrom" fail with AttributeError: 'NoneType' object has no attribute 'value' while mathematically equivalent expressions like "1/angstrom * jump_length" work correctly.

angstrom = DescriptorNumber("angstrom", 1e-10, unit="m")
jump_length = Parameter(name="jump_length", value=1.0, unit="angstrom")

a = Parameter(name='a', value=1.0)
a.make_dependent_on(
    dependency_expression="jump_length / angstrom",  # Fails
    # dependency_expression="1/angstrom * jump_length",  # Works
    dependency_map={"jump_length": jump_length, "angstrom": angstrom},
)

Root Cause

The __truediv__ and __rtruediv__ methods in both Parameter and DescriptorNumber had unnecessary lines restoring operand values after reading them:

other_value = other.value  # Read
# ... calculations ...
other.value = other_value  # Restore (unnecessary, triggers @notify_observers)

Since the value setter has @notify_observers, this triggered _update() on dependent parameters mid-evaluation, causing infinite recursion.

Changes

• parameter.py: Remove other.value = other_value from __truediv__ and self.value = original_self from __rtruediv__
• descriptor_number.py: Remove other.value = original_other from __truediv__ and clean up unused variable
• test_parameter.py: Add regression test covering both expression orderings

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Weird error with dependent parameters depending on order of operations</issue_title>
<issue_description>```
from easyscience.variable import DescriptorNumber, Parameter

angstrom = DescriptorNumber("angstrom", 1e-10, unit="m")

jump_length = Parameter(
name="jump_length",
value=float(1.0),
fixed=False,
unit="angstrom",
)

expression = "1/angstrom * jump_length"

expression = "jump_length / angstrom"

map = {
"jump_length": jump_length,
"angstrom": angstrom,
}

a = Parameter(name='a',value=1.0)
a.make_dependent_on(
dependency_expression=expression,
dependency_map=map,
)

The above code produces this error
<img width="1297" height="346" alt="Image" src="https://github.com/user-attachments/assets/d84bfb43-58c6-43d5-b051-eb93c65e9efe" />

but using `expression = "1/angstrom * jump_length" `, which is the same math, does not lead to this error.</issue_description>

<agent_instructions>Fix the issue. Create a PR with the fix, citing this issue. Don't forget to add unit tests. Do not generate any .md files.</agent_instructions>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes Weird error with dependent parameters depending on order of operations #190

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[github-actions]

This pull request does not contain a valid label. Please add one of the following labels: ['[scope] bug', '[scope] enhancement', '[scope] documentation', '[scope] significant', '[scope] maintenance']

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.80%. Comparing base (af7f27b) to head (ea5e4f5).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #191   +/-   ##
=======================================
  Coverage   80.80%   80.80%           
=======================================
  Files          52       52           
  Lines        4261     4256    -5     
  Branches      739      739           
=======================================
- Hits         3443     3439    -4     
+ Misses        633      632    -1     
  Partials      185      185           

Flag	Coverage Δ
unittests	80.80% <100.00%> (+<0.01%)	⬆️

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

Files with missing lines	Coverage Δ
src/easyscience/variable/descriptor_number.py	89.80% <100.00%> (+0.22%)	⬆️
src/easyscience/variable/parameter.py	90.46% <ø> (-0.04%)	⬇️

[rozyczko]

good solution.

[rozyczko]

I'd actually question whether restoration is needed at all. Reading .value shouldn't modify it: these are pure read operations followed by arithmetic. The only scenario where restoration would matter is if the getter has side effects that modify state, or some intermediate step in the calculation mutates the operand. This is highly unlikely.

[henrikjacobsenfys]

Agreed

[damskii9992]

I could swear this restoration was there for a reason, but I can't for the love of me figure out what that reason was . . .
But I guess we have unit tests and they don't fail after this change, so it must be fine? Right????

[rozyczko]

DON'T QUESTION THE AI OVERLORDS

[rozyczko]

This probably should be reparented to develop, unless we want to make an immediate patch?

[damskii9992]

This probably should be reparented to develop, unless we want to make an immediate patch?

Yeah, I don't think it is urgently required, @henrikjacobsenfys?