Technical debt: Possibly revisit immutable class design for fitting

[mducle]

We've chosen to make most of the classes which compose the spinw object immutable - e.g. Anisotropy and Coupling - so that when fitting in order to change the parameters of the spin wave model we would have replace these objects rather than just changing a number. This could cause a bottleneck in fitting, and should be revisited when we have fitting implemented.

[alexhroom]

one option is the way it's done in RAT/RasCAL-2: the classes get converted into simpler internal data objects like tuples etc. (which we're already doing for the spinwave calculation), then once the fit is completed the data objects are turned back into the actual classes and returned from the fit function. e.g. it looks like
results, new_experiment = experiment.fit()

this has some benefits and drawbacks:

• like I said we're already using simpler datatypes for the calculation - if we were directly fitting the user-facing class objects then we'd be converting back and forth every step of the fit which may be an even bigger bottleneck especially if we're using Rust
• we might have to convert our data classes to whatever the external fitting library uses anyway, e.g. to bumps Parameter classes or so on
• means we don't overwrite the user's original experiment when we run a fit

but:

• makes the data structures go a little abstract once we're in the internals
• hard to do without hardcoding the structure of the user-facing classes into the internal representations

[lucas-wilkins]

Overall, I think it's unlikely to be a problem with respect to speed, it's always going to be linear with the size of the system, whereas the main calculation is O(n^3) ish - if the calculation is slow, it won't be a big factor, if the calculation is fast, then it might be the bottleneck, but the calculation will be fast anyway. However, it might be annoying for users.

The following are things that we need to achieve/consider

1. keep everything synchronised, that is to say, make sure that changes to parameters update everything that they effect.
2. enable people to do complicated fits
3. good record keeping

Immutable structures are the easiest way of assuring synchronisation. The other option is a more reactive approach, have setters that are tasked with updating everything that needs to be updated.

Enabling complex fits would be implemented differently in the two cases, for the reactive case, we just hand things over to the user to update (though we could provide some extra functionality for simple cases). In the immutable case, we request a fitting object whose job it is to keep hold of the fit parameters, and return a copy of the system with the updated parameters.

Immutable strategy:
Pros:
Easy to maintain
Code is automatically self-consistent, because nothing ever updates
Easy FAIR compliance, keeping a record of every change is no problem
Undo functionality is easy

Cons:
A bit clunky to use
A highly unlikely possibility of code being too slow

Reactive strategy:
Pros:
If implemented correctly, it's transparent to the user
Potentially faster

Cons:
Difficult to maintain
Setters need to correctly maintain self-consistency of state, changes to code need to have corresponding changes to all relevant setters
Forgetting of previous state

[lucas-wilkins]

A further note about the immutable strategy: because objects are immutable, copies of objects can safely re-use references. This means that copying doesn't need the re-creation of lots of new objects, only everything lower (closer to the root) of the data tree.