Linspace bug follow up with no bugs #862
Conversation
| Increment(channel=0, value=0.01, dependency_key=DepKey(factors=(10000000,))), | ||
| Wait(duration=TimeType(1000000, 1)), | ||
| LoopLabel(idx=2, count=9), | ||
| #also here, an increment 0 may be helpful (at least to be able to force). |
There was a problem hiding this comment.
The increment is not emitted due to an optimization. Why would it be helpful?
There was a problem hiding this comment.
I would go further and replace loops that are constant by waits
There was a problem hiding this comment.
for wait it's not helpful. Just for other things, like WF scale, the program would need to know about the register it has to choose, which may work smoother if the corresponding Set command with the relevant DepKey is directly in front of it. Or maybe not, I dont' know.
There was a problem hiding this comment.
I think a scaled play should have a dependency key.
Test Results 3 files 3 suites 3m 9s ⏱️ Results for commit 98d2a01. |
| #however, i think this is what should happen (maybe also with an additional "Set" before, | ||
| #which might cause complications if omitted in other contexts like AWG amplitude: | ||
| #LoopLabel(idx=0, count=10), | ||
| #Set(channel=0, value=-1.0, key=DepKey(factors=(10000000,))), |
There was a problem hiding this comment.
This set statement is not required. because it is the same in every iteration and can be lifted out of the loop. Why should it happen? This is exactly one intended case the post != pre condition is supposed to detect and optimize.
There was a problem hiding this comment.
on further consideration, I think the issue that I saw when I first thought about this - that for long sequences that get repeated, this whole block is basically written twice in the sequence code, first for initial Setting, then forlooping n-1 times - is less of an issue overall if (what I did some time after that) e.g. for the HDAWG the entries for the CT can be recycled for the second code block.
There was a problem hiding this comment.
the thing is that it is required to do this twice because the initial state changes. I brooded over this quite a while I remember :D But it might still be that I am wrong...
There was a problem hiding this comment.
I don‘t think you‘re wrong; just in the very pathological case of repeating a sequence of 1000 pulses, where one element is just „Set“ with a Set command, one may want to prefer to have this codeblock only once and does not want that perceived optimization of omitting the Set command but having to write the repeated sequence twice.
But I don‘t think this is very relevant.
This is a rebase of #858 with includsion of VM based test.
The program and commands produced by the original code yield the correct result.