Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Addition of
step_warmup
#117Addition of
step_warmup
#117Changes from 9 commits
0987f5f
30c9f12
7faa73f
bd0bdc7
c620cca
572a286
6b842ee
ca03832
0441773
ea369ff
8e0ca53
6877978
b3b3148
ddc5254
ffbd32f
87480ff
76f2f23
c00d0c9
ef09c19
49b8406
f005746
9dccd8a
ff00e6e
7ce9f6b
3a217b2
de9bb2c
85d938f
0a667a4
91f5a10
7603171
ef68d04
25afc66
1886fa8
0ea293a
6e8f88e
44c55bb
3b4f6db
f9142a6
295fdc1
e6acb1f
2e9fa5c
366fceb
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 think nobody will look up the docstring for the unexported
mcmcsample
function, so it feels listing and explaining keyword arguments in https://turinglang.org/AbstractMCMC.jl/dev/api/#Common-keyword-arguments is the better approach? And possibly extending the docstring ofsample
?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.
Aaah I was totally unaware!
So I removed this, and then I've just added a section to
sample
to tell people where to find docs on the default arguments. I personally rarely go to the docs of a package unless I "have" to, so I think it's at least nice to tell the user where to find the info. I'm even partial to putting the stuff about common keywords in the actual docstrings ofsample
but I'll leave as is for now.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.
Is this correct? Shouldn't it just stay the same, possibly with some additional checks:
I thought we would do the following:
num_warmup = 0
, we just do the same as currently: Samplediscard_initial
samples that are discarded + theN
samples that are returned, possibly after thinning them.num_warmup > 0
, we still returnN
samples but depending ondiscard_initial
part of theN
samples might be samples from the warm-up stage. For instance:num_warmup = 10
,discard_initiial = 0
, andN = 100
, we would sample in totalN
samples and return them, whereof the first 10 are warm-up samples.num_warmup = 10
,discard_initial = 10
(the default if you just specifynum_warmup
), andN = 100
, then we would sampleN + discard_initial = 110
samples in total and return the lastN = 100
of them, so drop all warm-up samples.num_warmup = 10
,discard_initial = 20
, andN = 100
, then we would sampleN + discard_initial = 120
samples in total and return the lastN = 100
of them, so we would drop all samples in the warm-up stage and the first 10 samples of the regular sampling.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.
Ah sorry, yes this was left over from my initial implementation that treated
discard_initial
andnum_warmup
as "seperate phases".Agreed, but isn't this what my impl is currently doing? With the exception of this line above of course.
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 don't know, I stopped reviewing at this point and didn't check the rest 😄
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.
Haha, aight. Well, the rest is supposed to implement exactly what you outlined 😅
I'll see if I can also add some tests.
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.
Yes, this seems to match what I wrote above.
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 think these should be accounted for in the progress logger as well (as done currently).
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.
Should be good now 👍
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.
Wouldn't it be easier to do something along the lines of
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.
Well... Yes 🤦
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.
Ah actually, I now remember the reason for why I didn't do this: won't this make it type-unstable while the current implementation won't (if indeed
step_warmup
andstep
return the same type)?Whether we care is another thing.
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.
If
step_warmup
andstep
return the same types, both approaches should be type-stable, no? And if not, you're in trouble in both cases I assume?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.
My worry was that too many if-staments involving runtime information could confuse the type-inference, even in the case where the return-types of each branch is the same, but from your comments I'm assuming this was an irrational fear:)
Also, I just read a bit more https://juliahub.com/blog/2016/04/inference-convergence/ and my fears are indeed irrational 👍 I guess as long as each of the if-statement returns the same two types, i.e. the
Union
doesn't change, we're fine. IIRC Julia does union-splitting up to unions of length 4.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.
Any particular reason to switch to a
while
loop here?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.
Ah no! I'll revert it to for-loop 👍
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.
Can you add the same/similar error checks as above?
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.
Done 👍