We support both mutating and non-mutating propagators. Mutation is better for large Hilbert spaces. Non-mutation is better for small Hilbert spaces (StaticArrays!) or when trying to use automatic differentiation.
There are some subtleties in finding the correct abstraction. It is not as simple as using the built-in ismutable for states or operators and making decisions based on that: Anytime we use custom structs, unless that struct is explicitly defined as mutable, it is considered immutable. However, we can still use in-place propagation, mutating the mutable components of that struct.
Instead of overloading ismutable, we define the in-place or not-in-place interface explicitly via the required behavior guaranteed by the check_state, check_generator, and check_operator functions.
A new QuantumPropagators.Interfaces.supports_inplace function is available to check whether a given state or operator type is suitable for in-place operations.
We support both mutating and non-mutating propagators. Mutation is better for large Hilbert spaces. Non-mutation is better for small Hilbert spaces (
StaticArrays!) or when trying to use automatic differentiation.There are some subtleties in finding the correct abstraction. It is not as simple as using the built-in
ismutablefor states or operators and making decisions based on that: Anytime we use custom structs, unless that struct is explicitly defined asmutable, it is considered immutable. However, we can still use in-place propagation, mutating the mutable components of that struct.Instead of overloading
ismutable, we define the in-place or not-in-place interface explicitly via the required behavior guaranteed by thecheck_state,check_generator, andcheck_operatorfunctions.A new
QuantumPropagators.Interfaces.supports_inplacefunction is available to check whether a givenstateoroperatortype is suitable for in-place operations.