Updates for Regression and Other Stories #432

jgabry · 2020-04-27T16:28:14Z

@bgoodri and others: this PR isn't ready to merge yet because it's still missing changes to the default prior mean (due to issues in sorting out how to do that coherently). So far I have just changed the scaling so that:

autoscale defaults to FALSE in functions like normal(), student_t(), etc.
but autoscale is set to TRUE when those functions are used for default priors so that default priors continue to get autoscaled like before.
The default prior scale for the intercept before autoscaling is 2.5 instead of 10, which was deemed to be way too wide after autoscaling

This means that informative priors don't require explicitly setting autoscale=FALSE, as requested by @andrewgelman and @avehtari for RAOS.

* default to FALSE in functions for setting priors * explicitly set to TRUE in default prior usage to keep autoscaling by default

jgabry · 2020-04-27T22:55:48Z

Ok, I've also now added a preliminary version of default_prior_intercept() and default_prior_coef()

bgoodri · 2020-04-28T05:14:12Z

R/priors.R

@@ -562,7 +561,22 @@ R2 <- function(location = NULL, what = c("mode", "mean", "median", "log")) {
  list(dist = "R2", location = location, what = what, df = 0, scale = 0)
 }

+#' @rdname priors
+#' @export
+default_prior_intercept = function() {


I think default_prior_* should take a family argument and then stan_glm, etc. should default to default_prior(family). This will give us more flexibility to change things in the future.

Ok. What about for functions like stan_lmer(), stan_glm.nb(), stan_glmer.nb(), where there's no family argument?

That is, for stan_glmer() we can have

stan_glmer(..., prior_intercept = default_prior_intercept(family))

but for stan_lmer() and others should we just fill in the family like this?

stan_lmer(..., prior_intercept = default_prior_intercept(family=gaussian())) stan_glmer.nb(..., prior_intercept = default_prior_intercept(family=neg_binomial_2())) stan_glm.nb(..., prior_intercept = default_prior_intercept(family=neg_binomial_2()))

Or some other option?

jgabry · 2020-04-28T16:00:18Z

Comments from discussion:

add a slot to returned list that includes version number
add a slot for the modeling function name

we will have to make this a method of a S3 generic function at some point

jgabry · 2020-05-11T17:40:27Z

we will have to make this a method of a S3 generic function at some point

@bgoodri @paul-buerkner Can you remind me, was the plan to release a posterior_epred() generic in rstantools before changing to it in rstanarm and brms or to transition to using the generic later? If the former, then should we go ahead and release an rstantools shortly?

jgabry · 2020-05-14T16:04:04Z

I've added the family argument (for future use) as well as the version number in the returned list

jgabry · 2020-05-14T21:20:28Z

Removed posterior_epred generic, importing it from rstantools now. bumped rstantools in DESCRIPTION to >= 2.0.0.9000 (latest version on GitHub that includes posterior_epred generic).

[ci skip]

don't use range(x) anymore

into new-default-prior

[ci skip]

jgabry · 2020-06-26T21:46:24Z

@bgoodri I just pushed some more stuff and I think that's pretty much everything I have. RAOS is supposedly being released in less than a month (July 23rd) so we need to have this branch on CRAN by then at the latest. We’ll need both rstan and rstantools on CRAN before then.

[ci skip]

avehtari

I went through the changes and provided some comments. I tested that code runs.

avehtari · 2020-06-29T08:48:53Z

R/posterior_linpred.R

 #' @export
 #' 
 #' @templateVar stanregArg object
 #' @template args-stanreg-object
 #' @param transform Should the linear predictor be transformed using the
 #'   inverse-link function? The default is \code{FALSE}, in which case the
-#'   untransformed linear predictor is returned.
+#'   untransformed linear predictor is returned. The non-default behavior
+#'   of \code{TRUE} is somewhat deprecated since \code{posterior_epred}


What does "somewhat deprecated" mean? Is it possible to be more specific?

Good question. @bgoodri by "somewhat deprecated" did you just mean that we don't recommend it anymore but we're not going to throw a warning (I think it's just a message currently not a warning)? Is there a reason not to deprecate it with a proper warning?

R/posterior_linpred.R

avehtari · 2020-06-29T08:51:19Z

R/posterior_linpred.R

@@ -102,6 +112,11 @@ posterior_linpred.stanreg <-
    } else {
      colnames(eta) <- rownames(newdata)
    }
+
+    if (isTRUE(transform)) {
+      message("transform = TRUE is somewhat deprecated. ",


I don't like use of "somewhat"

Yeah "somewhat" is a bit strange. I think the idea was to distinguish between a message and warning, but I'm not sure. @bgoodri Are you ok if we change this message to a warning and get rid of "somewhat"?

vignettes/priors.Rmd

[ci skip]

bgoodri · 2020-06-30T05:01:55Z

I don't know if we'll ever get rid of the option but posterior_epred is preferable.

…

On Mon, Jun 29, 2020, 1:20 PM Jonah Gabry ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In R/posterior_linpred.R <#432 (comment)>: > #' @export #' #' @templateVar stanregArg object #' @template args-stanreg-object #' @param transform Should the linear predictor be transformed using the #' inverse-link function? The default is \code{FALSE}, in which case the -#' untransformed linear predictor is returned. +#' untransformed linear predictor is returned. The non-default behavior +#' of \code{TRUE} is somewhat deprecated since \code{posterior_epred} Good question. @bgoodri <https://github.com/bgoodri> by "somewhat deprecated" did you just mean that we don't recommend it anymore but we're not going to throw a warning (I think it's just a message currently not a warning)? Is there a reason not to deprecate it with a proper warning? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#432 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ2XKUUGPQKJH4FE34O4HLRZDEMFANCNFSM4MSCIJ4A> .

jgabry · 2020-06-30T15:44:10Z

How about we say that it is "deprecated" instead of "somewhat deprecated" but we keep it a message instead of a warning?

bgoodri · 2020-06-30T22:22:57Z

I think deprecated means the argument is going away, which I am not sure of

…

On Tue, Jun 30, 2020, 11:44 AM Jonah Gabry ***@***.***> wrote: How about we say that it is "deprecated" instead of "somewhat deprecated" but we keep it a message instead of a warning? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#432 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ2XKXEIQK2EDDKCW4OVYDRZIB5TANCNFSM4MSCIJ4A> .

jgabry · 2020-06-30T23:06:31Z

Ok in that case why don't we just say in the message that we recommend using posterior_epred instead (we don't need to say "deprecated" or "somewhat deprecated" at all). How about this?

message(
  "Instead of posterior_linpred(..., transform=TRUE) please call posterior_epred(), ",
  "which provides equivalent functionality."
)

bgoodri · 2020-06-30T23:40:44Z

ok

…

On Tue, Jun 30, 2020 at 7:06 PM Jonah Gabry ***@***.***> wrote: Ok in that case why don't we just say in the message that we recommend using posterior_epred instead (we don't need to say "deprecated" or "somewhat deprecated" at all). How about this? message( "Instead of posterior_linpred(..., transform=TRUE) please call posterior_epred(), ", "which provides equivalent functionality." ) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#432 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ2XKTYI6PKYPCYY2BTCIDRZJVYJANCNFSM4MSCIJ4A> .

[ci skip]

jgabry · 2020-07-07T22:47:36Z

@bgoodri Ready to merge this?

bgoodri · 2020-07-08T00:27:24Z

sure

…

On Tue, Jul 7, 2020 at 6:47 PM Jonah Gabry ***@***.***> wrote: @bgoodri <https://github.com/bgoodri> Ready to merge this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#432 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ2XKXOCX3L3HXZRHZW2VLR2OQZNANCNFSM4MSCIJ4A> .

jgabry added 5 commits April 27, 2020 11:57

prior scale for intercept now 2.5 instead of 10

8d43c7f

change autoscale usage

8bfe1d2

* default to FALSE in functions for setting priors * explicitly set to TRUE in default prior usage to keep autoscaling by default

add default_prior_intercept, default_prior_coef

0973436

Update priors.R

dd800ab

Update NAMESPACE

76a3806

bgoodri reviewed Apr 28, 2020

View reviewed changes

bgoodri added 2 commits May 2, 2020 23:36

introduce posterior_epred

fa19d13

we will have to make this a method of a S3 generic function at some point

predict.R: remove error message for RAOS

7add53f

jgabry mentioned this pull request May 11, 2020

add posterior_epred generic stan-dev/rstantools#73

Closed

add (currently unused) family argument to default_prior_*

90d49bc

update posterior_linpred/epred doc

b469f1e

jgabry added 13 commits May 14, 2020 17:21

import posterior_epred generic from rstantools

92d10a6

use posterior_epred instead of posterior_linpred in *_R2() functions

fef4102

[ci skip]

use posterior_epred instead of linpred with transform

dfd7d33

[ci skip]

logit and invlogit convenience functions

6ebfa90

[ci skip]

Update DESCRIPTION

cc050a0

[ci skip]

Merge branch 'master' into new-default-prior

64126fc

Update posterior_linpred.R

c5b67a4

[ci skip]

always divide by sd(x) (unless x is constant)

f97753c

don't use range(x) anymore

Update priors.Rmd

eb5cbd4

Merge branch 'new-default-prior' of https://github.com/stan-dev/rstanarm

4c3b8e2

into new-default-prior

more doc updates after updating default priors

dcf587a

Add note at top of priors vignette about changes

5a43cad

[ci skip]

remove autoscale=FALSE from vignettes

27e9988

[ci skip]

jgabry changed the title ~~[WIP] Updates to default priors~~ Updates for Regression and Other Stories Jun 26, 2020

jgabry requested a review from avehtari June 26, 2020 21:47

Update zzz.R

efc6d16

[ci skip]

avehtari reviewed Jun 29, 2020

View reviewed changes

jgabry added 2 commits June 29, 2020 13:30

mention version number in vignette

781a131

averages -> expectations in posterior_epred doc

3a412a9

[ci skip]

update message and doc for posterior_linpred(transform=TRUE)

8708832

[ci skip]

Merge branch 'master' into new-default-prior

5e8f452

bgoodri merged commit 089fe78 into master Jul 8, 2020

bgoodri deleted the new-default-prior branch July 8, 2020 14:13

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updates for Regression and Other Stories #432

Updates for Regression and Other Stories #432

jgabry commented Apr 27, 2020

jgabry commented Apr 27, 2020

bgoodri Apr 28, 2020

jgabry Apr 28, 2020

jgabry commented Apr 28, 2020

jgabry commented May 11, 2020

jgabry commented May 14, 2020

jgabry commented May 14, 2020

jgabry commented Jun 26, 2020 •

edited

Loading

avehtari left a comment

avehtari Jun 29, 2020

jgabry Jun 29, 2020

avehtari Jun 29, 2020

jgabry Jun 29, 2020

bgoodri commented Jun 30, 2020 via email

jgabry commented Jun 30, 2020

bgoodri commented Jun 30, 2020 via email

jgabry commented Jun 30, 2020

bgoodri commented Jun 30, 2020 via email

jgabry commented Jul 7, 2020

bgoodri commented Jul 8, 2020 via email

Updates for Regression and Other Stories #432

Updates for Regression and Other Stories #432

Conversation

jgabry commented Apr 27, 2020

jgabry commented Apr 27, 2020

bgoodri Apr 28, 2020

Choose a reason for hiding this comment

jgabry Apr 28, 2020

Choose a reason for hiding this comment

jgabry commented Apr 28, 2020

jgabry commented May 11, 2020

jgabry commented May 14, 2020

jgabry commented May 14, 2020

jgabry commented Jun 26, 2020 • edited Loading

avehtari left a comment

Choose a reason for hiding this comment

avehtari Jun 29, 2020

Choose a reason for hiding this comment

jgabry Jun 29, 2020

Choose a reason for hiding this comment

avehtari Jun 29, 2020

Choose a reason for hiding this comment

jgabry Jun 29, 2020

Choose a reason for hiding this comment

bgoodri commented Jun 30, 2020 via email

jgabry commented Jun 30, 2020

bgoodri commented Jun 30, 2020 via email

jgabry commented Jun 30, 2020

bgoodri commented Jun 30, 2020 via email

jgabry commented Jul 7, 2020

bgoodri commented Jul 8, 2020 via email

jgabry commented Jun 26, 2020 •

edited

Loading