[Tasks]: Make the computations of `leaf_dynamic` vectorized

[SarahAlidoost]

After merging #12 , we want to change the data array organization inside the module, see #18. For now, focus only on part A .

Requirements:

• The existing tests should pass.
• New tests should be implemented for vectorization.

Note:

Read related issues #20, #21, #22, #23

[ronvree]

I was thinking a bit more about the torch tensor shapes and am curious to hear your thoughts on this:

What if, instead of having a predefined tensor shape of (batch_size, n_parameter_sets, locations) we say that we always treat the last dimension as n_parameter_sets and impose no constraints on the number of dimensions. I think this would be a more elegant way to resolve this issue, except that it might add an extra implementation challenge. Do you think this would work/be worth implementing?

I still feel that, as long as all locations are considered independent, the locations dimension is completely redundant with n_data. If we do want to consider some spatial context in the future, data might be structured as a grid (i.e. two dimensions) instead of one, requiring flattening and restructuring the tensors which is kind of tedious and error prone.

[SarahAlidoost]

I was thinking a bit more about the torch tensor shapes and am curious to hear your thoughts on this:

What if, instead of having a predefined tensor shape of (batch_size, n_parameter_sets, locations) we say that we always treat the last dimension as n_parameter_sets and impose no constraints on the number of dimensions. I think this would be a more elegant way to resolve this issue, except that it might add an extra implementation challenge. Do you think this would work/be worth implementing?

I still feel that, as long as all locations are considered independent, the locations dimension is completely redundant with n_data. If we do want to consider some spatial context in the future, data might be structured as a grid (i.e. two dimensions) instead of one, requiring flattening and restructuring the tensors which is kind of tedious and error prone.

Sorry, issue #18 is pretty abstract, and there hasn’t been much explanation on how we’re developing the data organization. The idea is to change the crop model’s data structure so it can work with input arrays of any size, scalars, 1D, 2D, 3D, and so on. Ideally, the model should take in the parameters as ndarrays (or tensors) with the same length and return ndarrays (or tensors) in response. Hope this addresses your comment. Otherwise, let us know.

[ronvree]

Thanks a lot for the clarification! This is also what I had in mind in my previous comment. Does this mean the description in #8 is deprecated?

[SarahAlidoost]

Thanks a lot for the clarification! This is also what I had in mind in my previous comment. Does this mean the description in #8 is deprecated?

issue #18 is updated.