You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
loo.function should not require a r_eff argument #106
If the user is providing a function to calculate the log-likelihood contribution of each observation, why does the user also need to pass a call to relative_eff? This just seems unnecessary.
Actually, computing r_eff requires knowing which chain each posterior draw comes from. The chain id is not a required input to loo.function because LOO just needs all draws stacked together. In other words, dropping the r_eff argument would require adding a chain_id argument to loo.function or requiring a chain_id column in draws so that r_eff can be calculated internally.
Here are three possibilities:
# drop the r_eff argument and require a chain_id argument
loo.function(x, ..., data, draws, chain_id)
# drop the r_eff argument and require chain_id to be included in draws
loo.function(x, ..., data, draws) # checks internally for a chain_id column in 'draws'# keep the r_eff argument and add a chain_id argument so the user can # decide whether to compute r_eff and pass it in or provide chain_id and# let loo calculate r_eff
loo.function(x, ..., data, draws, r_eff, chain_id)
I would say (1) but is another option to require draws to be an array
rather than a matrix. Or at least if it is an array, do not error if
chain_id is left unspecified.
On Tue, Apr 16, 2019 at 12:30 PM Jonah Gabry ***@***.***> wrote:
Actually, computing r_eff requires knowing which chain each posterior
draw comes from. The chain id is not a required input to loo.function
because LOO just needs all draws stacked together. In other words, dropping
the r_eff argument would require adding a chain_id argument to
loo.function or requiring a chain_id column in draws so that r_eff can be
calculated internally.
Here are three possibilities:
# drop the r_eff argument and require a chain_id argument
loo.function(x, ..., data, draws, chain_id)
# drop the r_eff argument and require chain_id to be included in draws
loo.function(x, ..., data, draws) # checks internally for a chain_id column in 'draws'
# keep the r_eff argument and add a chain_id argument so the user can # decide whether to compute r_eff and pass it in or provide chain_id and# let loo calculate r_eff
loo.function(x, ..., data, draws, r_eff, chain_id)
Anyone have a preference or other suggestions?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#106 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADOrqnHlbuX8DeQ0z8kyGdZM5fhrwCc0ks5vhfqlgaJpZM4cyqJe>
.
Yeah if draws is an array then we don’t need the chain_id. I don’t think we should require it to be an array, but we could go with option (1) above but only requiring chain_id if draws is not an array.
Now that we have posterior package, we have chain and iteration info often, and could compute r_eff based on those, and maybe then for the arrays/matrices without that info assume no r_eff computation unless additional information is provided?
Bumping this as I'm now in favor of reducing the need to enter r_eff. I would be fine with that r_eff=1 unless we do get chain and iteration information via draws object, and in those cases estimate r_eff internally
I am closing this issue as #235 addresses the need to provide r_eff as requested in the issue description. Furthermore, the handling of r_eff in loo is being further developed in the refactoring PR #363. However, I am happy to reopen this issue if it is considered unresolved and still relevant.
Activity
jgabry commentedon Apr 16, 2019
It does seem unnecessary. We can drop that and calculate it internally.
jgabry commentedon Apr 16, 2019
Actually, computing
r_effrequires knowing which chain each posterior draw comes from. The chain id is not a required input toloo.functionbecause LOO just needs all draws stacked together. In other words, dropping ther_effargument would require adding achain_idargument toloo.functionor requiring a chain_id column indrawsso thatr_effcan be calculated internally.Here are three possibilities:
Anyone have a preference or other suggestions?
bgoodri commentedon Apr 16, 2019
jgabry commentedon Apr 16, 2019
Yeah if draws is an array then we don’t need the chain_id. I don’t think we should require it to be an array, but we could go with option (1) above but only requiring chain_id if draws is not an array.
@avehtari and @paul-buerkner any preference here?
avehtari commentedon Mar 24, 2023
Now that we have posterior package, we have chain and iteration info often, and could compute r_eff based on those, and maybe then for the arrays/matrices without that info assume no r_eff computation unless additional information is provided?
avehtari commentedon Nov 29, 2023
Bumping this as I'm now in favor of reducing the need to enter
r_eff. I would be fine with thatr_eff=1unless we do get chain and iteration information via draws object, and in those cases estimater_effinternallyavehtari commentedon Feb 17, 2024
#235 reduced the need to provide
r_eff. @bgoodri does that solve your problem?florence-bockting commentedon Jun 8, 2026
I am closing this issue as #235 addresses the need to provide
r_effas requested in the issue description. Furthermore, the handling ofr_effinloois being further developed in the refactoring PR #363. However, I am happy to reopen this issue if it is considered unresolved and still relevant.