batch_assign: Dict[List] vs List[Dict]

[Roger-luo]

          or do we want to always let the user specify the value when using `batch_assign`? this seems to be a decision choice because both look good to me.

Originally posted by @Roger-luo in #131 (comment)

@weinbe58 let's move the discussion to here so we don't block that PR, I think we should merge the PR first, and make this design decision later.

[weinbe58]

or do we want to always let the user specify the value when using batch_assign? this seems to be a decision choice because both look good to me.

We need to split them up because, at the builder phase, we can't know what field belongs to a RunTimeVector vs. a Variable. For example, how can I know if a field is a List[Number] because its a RunTimeVector vs a batch for a Variable

I guess we can check against the register size but this becomes problematic if the size of the batch just happens to be the size of the register.

[weinbe58]

ok since you implement a check of this maybe let's use the current version first, I'm still skeptical on this because one can easily have a wrong input with just a typo.

I don't understand what you mean here, you mean with regards to the length of the parameters?

[Roger-luo]

Yes

This will get caught during code generation and it should have a specific name attached to what the missing field is.

so my point is

• List[Dict] prevents this type of error by construction - one will never hit such error, so user will not have a bug to fix
• Dict[List] will require an extra check, thus there will be an extra bug that causes an error, and will require fixing later.

but I see that Dict[List] has simpler syntax for our use cases in the whitepaper, this is why I approved the PR. I'd like to see how this play with the code in the long run tho.

[weinbe58]

I think the config file captures the more complicated scans. constructing a List[Dict] is typically pretty verbose.

Edit: Especially when you are dealing with long names for parameters, like "initial_detuning" etc.

[weinbe58]

We could provide something like itertools iterface for batches so you could have a zip_batch(...) which would act like a zip for all ther keys in that batch or a product_batch which acts like nested for loops for all the parameters. One simple way to do this is to say that every time you call batch_assign it acts like a nested for loop and if parameters are within the same batch_assign call they will be zipped together.

something like:

.batch_assign(a = a_list, b = b_list)
.batch_assign(c = c_list)

would lower to a loop like:

for a,b in zip(a_list,b_list):
    for c in c_list:
        vars =  {'a':a, 'b':b, 'c':c}

Edit: Ideally the two-dimensional structure will also move down to the task level as well so it is easy to do the analysis without having to know how to unravel the nested loop.