It turns out that m$calculate(c('y[1]','y[1]')) for scalar y[i]s and similarly m$calculate(c('y[1]','y[2]')) for multivariate y[1:2] will duplicate calculation. Similarly m$getNodes(c('y[1]','y[1]')) (in the scalar case) and m$getNodes(c('y[1]','y[2]')) (in the mv case) will give duplicates.
This is inconsistent with nimble, so from that perspective we should fix it. Fixing will involve writing some functionality to intersect nodeRanges so we can remove overlaps. (Currently we just walk through the inputs and apply the relevant rules and collect/flatten the results.) We talked about needing this ability for setupMargNodes which needs to use intersect.
Fixing will also mean some additional processing as we will need to work in a pairwise fashion with all ranges for a given variable. Or perhaps we try to take the union of all of them at once in some fashion.
There may be an argument for not 'fixing' this. Namely if a user gives input such as above, one could say we are simply giving back the results corresponding to each of the inputs. That being said, the result is not always 1:1 with the length of the input.
I will note here, but probably discuss further in a separate issue, that aggregation is non-trivial. Consider that it is straightforward to aggregate y[1:5] with y[6:10], but aggregating when given y[1:5], y[11:15],y[6:10] (and processing in that order) is tricky. And of course if we have multiple indices, doing things so that the results are compact will be hard. Even if we fully expand, we then have the challenge of finding blocks that can be handled compactly.
It turns out that
m$calculate(c('y[1]','y[1]'))for scalary[i]s and similarlym$calculate(c('y[1]','y[2]'))for multivariatey[1:2]will duplicate calculation. Similarlym$getNodes(c('y[1]','y[1]'))(in the scalar case) andm$getNodes(c('y[1]','y[2]'))(in the mv case) will give duplicates.This is inconsistent with nimble, so from that perspective we should fix it. Fixing will involve writing some functionality to intersect nodeRanges so we can remove overlaps. (Currently we just walk through the inputs and apply the relevant rules and collect/flatten the results.) We talked about needing this ability for
setupMargNodeswhich needs to useintersect.Fixing will also mean some additional processing as we will need to work in a pairwise fashion with all ranges for a given variable. Or perhaps we try to take the union of all of them at once in some fashion.
There may be an argument for not 'fixing' this. Namely if a user gives input such as above, one could say we are simply giving back the results corresponding to each of the inputs. That being said, the result is not always 1:1 with the length of the input.
I will note here, but probably discuss further in a separate issue, that aggregation is non-trivial. Consider that it is straightforward to aggregate
y[1:5]withy[6:10], but aggregating when giveny[1:5],y[11:15],y[6:10](and processing in that order) is tricky. And of course if we have multiple indices, doing things so that the results are compact will be hard. Even if we fully expand, we then have the challenge of finding blocks that can be handled compactly.