-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mrc-3332 include output in info #105
Conversation
Codecov Report
@@ Coverage Diff @@
## master #105 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 7 7
Lines 1046 1067 +21
=========================================
+ Hits 1046 1067 +21
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had a think about the duplication in sorting out indices for output and variables, and have cooked up some suggestions on a PR into this branch (#108). There's still a bit of weirdness (especially around the length calculation) - see what you think.
It took a while to think through because I got quite confused - it turns out that there was an issue in the output indices generated here as the offset was correct only in the case of a single scalar output (see below for an example).
A failing test case
model <- quote({
initial(x) <- 1
deriv(x) <- 1
initial(y[]) <- 1
deriv(y[]) <- 1
dim(y) <- 10
output(a) <- 1
output(b[]) <- 1
dim(b) <- 5
})
The expected packing (odin sorts by variables then outputs, and within each sorts by rank).
1 2, ..., 11, 12, 13, ..., 17
x, y[1], ..., y[10], a, b[1], ..., b[5]
You can compare this way, but it's really ugly to do:
gen <- odin::odin(model)
mod <- gen$new()
mod$transform_variables(seq_len(11 + 6))
However, the code in this PR returns incorrect index for output because it's using the total length (17) as the offset to start all output variables at (the len
that is passed in).
gen <- odin_dust(model)
mod <- gen$new(list(), 0, 1)
mod$info()$index
Here you can see that we say that a
is in 17 and b
in 18:22
It's probably worth making a test out of an example like this to prevent regression.
Suggestions for review
Thanks, that was a silly bug 🤦 Have added your example as a test |
Co-authored-by: Rich FitzJohn <r.fitzjohn@imperial.ac.uk>
Calls to
mod$info()
should include details about output as well as internal state variables.