Parameter improvements #600
Description
Working with parameters, I have noticed there are some features missing that I think could be a useful addition.
I have listed them below.
The suggested improvements are mainly in the StandardParameter and the CombinedParameter.
Please let me know what suggestions you agree/disagree with, and possible ways (and pitfalls!) of implementing it.
General
Add get/set modifier
The val_mapping functionality is useful, because it allows the input to be transformed before performing the actual set/get.
The limitation here is that val_mapping must be a dict, and an enhancement would be to also accept functions for getting/setting.
This could be especially useful for the CombinedParameter, where it would allow you to use a single value to set a linear combination of several parameters.
Move delay to BaseParameter
Parameters other than the StandardParameter might need a delay.
It would therefore be good to standardize the set method to always perform a delay if the attribute is not set to None.
This could furthermore be used for inter_delay (see below).
I'm not sure what would be the best approach for this.
One idea would be to add it to the BaseParameter, which then decorates the set and get commands to include delays etc.
Another way is to create a method such as _set_with_delay or _set_decorated_, which is triggered by call(), and which then calls a set and performs delays.
Parameter
Default slice step
Being able to use the slice notation for parameters is very useful, as it is a quick way to create an np.arange list.
Currently, the slice notation requires three inputs: [start:stop:step].
However, both the default slice notation and np.arange don't need the step argument, and use the default value 1.
To mimick this behaviour, I suggest we also use 1 as a default value for step.
Accept numpy arrays for sweep points
When creating sweep values for a parameter (param[val_list]), val_list must be a list.
Often one would like to use values through numpy functions, such as arange or linspace.
Currently, parameters do not accept numpy arrays for sweep values, and so these arrays must first be converted to lists.
I suggest we also allow numpy arrays as sweep values.
As a side question, would this then need to be converted to a list internally?
StandardParameter
Replacing methods by dependent properties
Several methods are strongly related to getting/setting attributes (e.g. get_delay, set_delay).
These can be replaced dependent attributes (via the @Property decorator).
This results in more readible code, and less methods cluttering up the namespace.
Useless max_delay
From looking at the code, it seems to me that max_delay is not doing anything.
I've done some testing, and could not come up with a situation where max_delay actually changes something.
It is also not clear to me from the documentation what its use is.
Is someone using it, or does someone understand its use?
If not I suggest we remove it.
Change delay to post_delay, and add inter_delay
Currently, the attribute delay results in a delay after every set operation.
The main use of this is to let the system settle after such a set operation.
In some cases, a different type of delay can be useful, namely to ensure that two set operations are not performed too rapidly after each other.
One possible reason for this is that sending visa commands too rapidly could freeze up a device.
In this case, the current delay results in an unnecessary delay after each set operation.
To illustrate this, assume an instrument parameter that can only process one command per second.
After setting the parameter, an acquisition can be performed, which we assume also takes a second.
If we use the current delay, it will ensure that no two commands are sent within a second after each other.
However, setting a parameter and then subsequently performing an acquisition will take a total of two second instead of one.
This is because it will sleep for a second after setting the parameter, while it should be able to perform the acquisition straight away.
I suggest we change the current delay to post_delay, indicating that it will perform the delay after the set operation.
Adding a second inter_delay can be used to ensure that set operations are not performed too rapidly after each other.
This delay is not performed right after each set, but instead occurs when a subsequent set is performed too rapidly.
In this case, the system sleeps until inter_delay has passed, after which it will perform the subsequent set.
Change _validate_and_set and _validate_and_sweep to set
The two methods have a lot of overlapping code.
Furthermore, adding validate to the method name seems unnecessary (the ManualParameter.set does this implicitly)
I think it would be better to combine these two methods in the set method, which starts with checking if delay is None
CombinedParameter
Make CombinedParameter an actual parameter
Instead of being a Parameter, the CombinedParameter seems to have an attribute called parameter that somehow mimicks the behaviour of a parameter.
I'm not seeing why it can't simply be a parameter, either a subclass of Parameter, MultiParameter, or BaseParameter.
The comments of @giulioungaretti say that it's a hack, so could you explain why this hack is needed?
I suggest we transform it into a parameter.
We could then create a separate SweepValues class for the CombinedParameter.
Default value for name
The CombinedParameter currently requires a name.
This means that when using combine(param1, param2, ...), it is always necessary to also include a name.
Since the name usually refers to the parameters that are combined, we can have name as an optional argument, and have a default name.
This could be '{param1.name}{param2.name}...' or 'combined({param1.name}, {param2.name})' or something similar.
Add get method
There is no get method for the CombinedParameter, while in many cases this would be useful.
For instance, if you have two voltage gates which you want to treat as one.
There are several ways in which a get method can be implemented.
I think the best solution would be to by default return a set containing values for each of the parameters.
This default behaviour can be overridden by a get_modifier (see above).
Add allow_scalar
One useful feature of the CombinedParameter is to treat several parameters as one.
To this end, it would be useful to be able to set multiple parameters through a single value, i.e. combined_parameter(val) would set each of its parameter to val.
We could therefore add a flag allow_scalar, which for safety reasons should be set to False by default
Remove _aggregate method
We should be able to simplify this by simply using self.aggregate = aggregator
Modify set to receive values instead of index
By doing this, we can use the CombinedParameter while not necessraily in a loop
Add __getitem__ notation
This probably ties in with making the CombinedParameter a parameter.
This way, we won't have to use the combined_parameter.sweep() method, which isn't necessary for other parameter types.