Upper limit of sweep range about qcodes HOT 6 CLOSED

I think it makes sense to stick to default python behaviour.
I can understand why it would be more intuitive for people coming from different programming languages, however the price of having multiple defaults within the same program (i.e. the one you propose in addition to regular slices) will result in very confusing behaviour.

As far as I understand this is there to emulate python slice behaviour, if this is the case it should not act slightly different.

from qcodes.

I agree that it might be confusing but I feel like the current syntax would
lead to a lot of sweeps with the last point missing. I suppose it's just a
question of deciding which is worse.
Den 31/03/2016 14.00 skrev "Adriaan" [email protected]:

I think it makes sense to stick to default python behaviour.
I can understand why it would be more intuitive for people coming from
different programming languages, however the price of having multiple
defaults within the same program (i.e. the one you propose in addition to
regular slices) will result in very confusing behaviour.

As far as I understand this is there to emulate python slice behaviour, if
this is the case it should not act slightly different.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
qdev-dk-archive#65 (comment)

from qcodes.

I do agree that the current syntax might lead to sweeps with the last point missing. I strongly feel however that we should not change default python behavior as it makes the entire project very confusing which would be worse in my opinion.
To solve the problem of the last point missing, a new syntax might be devised that does not involve slicing, but is based on (e.g.) numpy.linspace

from qcodes.

Right, I've discussed this with various individuals in the past so it's nice to collect it all in one issue :)

The slice syntax is nice and compact but it's such a deeply ingrained feature of Python that we cannot alter its behavior. But I wouldn't be opposed to adding a new option with function-call syntax, that we strongly encourage users to write with keywords. That way the user wouldn't need to convert between number of points and step, or increment the endpoint manually. Then we could support many forms (matching numpy.linspace but with additional flexibility), all of which would give [1, 2, 3, 4, 5]:

p(start=1, stop=5, step=1)
p(start=1, stop=5, num=5)
p(start=1, stop=6, step=1, endpoint=False)
p(start=1, stop=6, num=5, endpoint=False)
p(start=1, step=1, num=5)  # endpoint=True/False is irrelevant in this form

I wrote this as if we bind to Parameter.__call__, which is currently unused, is very compact, and doesn't seem ambiguous, but might not be intuitive. We could instead use Parameter.sweep or something.

As an aside, note that slice notation allows arbitrary extra arguments, so you can combine several linear sweeps in one call. But with either syntax you can do this by adding the resulting SweepFixedValues objects:

# all of these give [1, 2, 3, 4, 5, 7, 9, 11, 13]
p[1:5:1, 5:15:2]  # multiple slices in one call
p[1:5:1] + p[5:15:2]
p(start=1, stop=4, step=1) + p(start=5, stop=13, step=2)

from qcodes.

Actually we destroyed the option for this functionality with #76 #78 and #91. too bad I dint read, and realize this earlier.

I implemented it here locally now as a p.sweep(start, stop, step, num, revert) which works great.

What are peoples comments on this? I guess its not too late to revert the other idea. I dont like merging the two into one, that would lead to a lot of confusion.

from qcodes.

We now have .sweep() closes the issue.

from qcodes.