search

vukics / Wigner_Time

Timeline creation and management for open-loop control in AMO experiments and beyond.
Boost Software License 1.0
0 stars 0 forks source link

ramp needs a separate `duration` #16

Open light-matters opened 1 week ago

light-matters commented 1 week ago

My tests with ramp fail because the specified time seems to be different from the duration keyword? 

ramp(lockbox_MOT__V=[1.0, 1.0], fargs={"time_resolution": 0.2})

fails because there is no duration, but I assumed that was the second argument of lockbox... etc.

vukics commented 1 week ago

This is a problem of your failing test :)

ramp is not a replacement of next and shift because the latter two had erroneous logic, so they were not suitable to implement our experimental timeline.

(Starting) time and duration of a ramp are conceptually different things and cannot be switched between by a boolean argument. We need to have them separately. Starting time can be absolute or relative.

light-matters commented 1 week ago

Well... strictly speaking this is erroneous logic :).

Starting time and duration are indeed conceptually different things; it is the end time and the duration which were switched on a flag, which is sensible, if not desired, because they are the same when t0=0. This was in keeping with the previous request for the 'create' and 'next' call signatures to be as similar as possible. The next function had the option for relative starting and ending times and so is a superset of the new ramp function. This should have been clearer though.

The question of having flags to change the meaning of t vs having two kwargs that can't both be used at the same time always plagued me though...

For posterity, I was zealous to distinguish time and duration in the previous parameters so I agree with the general point.