Script Generator: Control iterations via start, stop & step-size

[kjwoodsISIS]

As scientist using the Script Generator, I want to specify iterations as start, stop and step-size, because it is a more convenient way to define iterations with many steps.

Acceptance Criteria

1. The Script Generator allows me to define the start point of an iteration
2. The Script Generator allows me to define the end point of an iteration
3. The Script Generator allows me to define the step-size of an iteration.
4. The start point, end point and step size can be integers or floating point numbers (decimal or scientific notation).
5. The difference between the end and start points need not be an integral multiple of the step-size

Notes

1. This issue was raised in a discussion with the EMU scientists, but will apply to all scientists.
2. This way of defining an iteration is exactly analogous to using a for loop in most programming languages (e.g. for (x = start; x < end; x += step-size)).
3. The start point, end point and step size will often be variables (e.g. temperatures, magnetic fields, currents or voltages), so we need to accept more than just integers.
4. In general, the step size will be chosen for convenience. It will not necessarily cause the iteration to finish up at exactly the end-point. For example: start = 0.3K, end = 4.6K, step-size = 0.2K. We need to be clear to users how this will be translated into Python code. In the above example, will the iteration finish at 4.5K or 4.7K? It is merely a matter of choosing a convention and documenting it.
5. This could be implemented as a generator function in python this would allow the users to define there own loops which accept parameters they want. Would be a action which can have a sub action.
6. For a nice way of doing loops with floats look at numpy.linspace and numpy.arrange

[ChrisM-S]

Given this implies a possible floating point generated summation of the index, it would be wise to build in a "near equality" test of loop indices into the generated code, this avoids unexpected behaviour in the FP accuracy of a summed index by checking for near equality within a very small delta (rather than exact floating point equality). i.e.

for (x = start; neareq(x, end); x += step-size)

Note: that the user is NOT programming in python here, so good programming "hygiene" is the script generator's responsibility entirely, and should avoid unexpected surprises the user might not intend, like a missing iteration from "for 1.0 to 30.0 in step 1" giving too few steps.

(The alternative is to dynamically expand the loop index into separate steps in the interface where the error would then be obvious.)

[JamesKingWork]

Should include squish tests

[ThomasLohnert]

Not sure how this is different from defining parameters for start, end and step in your script definition.

Muon scientists say it would be great however to be able to see the list of inbetween steps as a tooltip.