brms support for XBX regression #1698

ikosmidis · 2024-10-28T16:22:56Z

I hope all is well. This PR provides (hopefully) full support for XBX regression through the xbetax rbms family. XBX regression is defined in the recent preprint of mine with @zeileis

Kosmidis I, Zeileis A (2024). Extended-support beta regression for $[0, 1]$ responses.
arXiv: 2409.07233

Specifically, with covariates $x_i$ the likelihood of XBX regression can be defined as

$$\begin{aligned} Z_i | X_i = x_i & \sim \text{Beta}(\mu_i \phi_i, (1 - \mu_i) \phi_i) \\\ Y^*_i &= (1 + 2 U_i) Z_i - U_i \\\ Y_i & = \max(\min(Y^*_i, 1), 0) \\ U_i & \sim_\text{ind.} \text{Exponential}(1/\nu) \\\ \end{aligned}$$

or, equivalently, and as implemented in the PR

$$\begin{aligned} Y_i | X_i = x_i, U_i = u_i & \sim \text{XB}(\mu_i, \phi_i, u_i) \\\ U_i & \sim_{\rm ind.} \text{Exponential}(1/\nu) \\\ \end{aligned}$$

with $\rm XB$, the extended-support beta distribution as defined in the manuscript. Th $u_i$'s are exceedance parameters, as they determine how much the support of the beta distributon should be extended at the left and right of $(0, 1)$, before censoring, and taking a continuous mixture.

The betareg R package already provides the model above, using Gauss-Laguerre quadrature approximation to the log-likelihood.

The approach taken for the brms implementation is to use instead $log(u_i) \sim_{\rm ind.} {\rm Normal}(\mu, \sigma^2)$, which was relatively easy to implement with the default priors. In fact, we considered LogNormal when developing the theory, but in our frequentist treatment, we decided in favour of the one extra parameter that the exponential distribution requires, and there was not much evidence for LogNormal in our preliminary experiments.

For example, with the PR we can now do

if (requireNamespace("betareg", quietly = TRUE)) {
  data("LossAversion", package = "betareg")
  LossAversion$id <- 1:nrow(LossAversion)
  hmc_xbx <- brm(
      bf(invest ~ grade * (arrangement + age) + male,
           phi ~ arrangement + male + grade,
           u ~ 1 || id),
      data = LossAversion,
      family = "xbetax")
}

The new example in ?brm compares the above HMC fit with the maximum likelihood fit we get from betareg with exponential distributions; the fits, up to expectation, are essentially the same.

The Additions section below includes a list of the additions.

Questions

Is there any way to allow for exponential distributions with mean $\nu$ for the exceedance parameters, allowing for a flat prior in $\nu$?
Is there a way to have u ~ 1 || id, where id is the observation id, as the default for xbetax families? Correlated varying effects, more complicating grouping for u or fixed effects there, while easily accommodated by the facilities in brms and fits may be obtainable by HMC, are overkill and are not recommended because both u and phi control the response variance; the model may end up being formally not identifiable.
Is there any way to implement family-specific errors if some conditions about the data are met? e.g. if no zero / one observations are in the responses, then throw a warning and propose the user fits a "beta" family; trying "xbetax" with flat priors on u or the parameters of its distribution can be a challenge for HMC in that case, and there is not much to gain compared to a "beta" family fit.

Notes

The name xbetax for the family (instead of XBX) is used to be close to thedist = "xbetax" argument betareg uses
I added betareg and distributions3 for the XBeta() distribution and manipulation of it, respectively in Suggests. THese could be coded in brms but adding the suggests avoids defining the distributions in multiple places in CRAN (and makes support easier!).
👏👏👏👏 for brms. Fantastic codebase, and glad I engaged with it!

Additions

DESCRIPTION
- Suggests now has betareg and distributions3 for the XBeta() distribution and manipulation of it, respectively
R/families.R
- brmsfamily() now supports link_u, where u is the exceedance parameter of the extended-support beta distribution
- links_dpars() now has u = c("log")
- family_bounds.brmsterms(): "xbetax" is now in beta_families`
- Documentation updates
Added inst/chunks/fun_xbetax.stan
R/brm.R
- Documentation updates
- Added XBX regression example
R/family-lists.R
- Added .family_xbetax()
R/log_lik.R
- Added log_lik_xbetax()
R/posterior_epred.R
- Added posterior_epred_xbetax()
R/posterior_predict.R
- Added posterior_predict_xbetax()
R/stan-likelihood.R
- Added stan_log_lik_xbetax()
R/priors.R
- def_dpar_prior() now has u = "gamma(0.01, 0.01)" if link is identity and u = "student_t(3, 0, 2.5)" otherwise
- dpar_bounds() now has u = list(lb = "0", ub = "")
R/stan-predictor.R
- stan_dpar_comments() now has u = "exceedance parameter"

paul-buerkner · 2024-10-28T23:26:27Z

Thank you! This looks really nice! I will take a closer look at the PR in the next few days.

About your questions:

Is there any way to allow for exponential distributions with mean ν for the exceedance parameters, allowing for a flat prior in ν ?

I don't fully understand. Can you elaborate?

Is there a way to have u ~ 1 || id, where id is the observation id, as the default for xbetax families? Correlated varying effects, more complicating grouping for u or fixed effects there, while easily accommodated by the facilities in brms and fits may be obtainable by HMC, are overkill and are not recommended because both u and phi control the response variance; the model may end up being formally not identifiable.

This is unforunately not possible as it would require too much special case coding. It has to remain the responsibility of the user.

Is there any way to implement family-specific errors if some conditions about the data are met? e.g. if no zero / one observations are in the responses, then throw a warning and propose the user fits a "beta" family; trying "xbetax" with flat priors on u or the parameters of its distribution can be a challenge for HMC in that case, and there is not much to gain compared to a "beta" family fit.

Good question. I will think about a good way to achieve this.

One more quick point: I don't think that such a detailed example of a cool but still niche model should be placed within the ?brm doc. I am not sure if brms has a good place for such detailed examples. Perhaps in the ?brmsfamily page. In any case, I don't think the betareg comparison is needed there, which would also allow you to drop the betareg suggests I believe.

ikosmidis · 2024-10-29T07:23:38Z

Thank you! This looks really nice! I will take a closer look at the PR in the next few days.

About your questions:

Is there any way to allow for exponential distributions with mean ν for the exceedance parameters, allowing for a flat prior in ν ?

I don't fully understand. Can you elaborate?

The model, as we defined it (see above) has

$$\begin{aligned} Y_i | X_i = x_i, U_i = u_i & \sim \text{XB}(\mu_i, \phi_i, u_i) \\\ U_i & \sim_{\rm ind.} \text{Exponential}(1/\nu) \\\ \end{aligned}$$

However, instead of $U_i \sim_\text{ind.} {\rm Exponential}(1 / \nu)$ (mean $\nu$), I implemented $log(u_i) \sim_{\rm ind.} {\rm Normal}(\mu, \sigma^2)$ in brms, by allowing $U_i$ to be independent varying effects per observation and using the default priors for varying effects. We have considered log-normal for $U_i$ in the past, but, in our frequentist treatment we went for Exponential, which introduces only a single unknown parameter to the model. I wonder whether there is a way to (e.g. not going through varying effects?) to define the family to have $U_i$ independent with an $\text{Exponential}(1/\nu)$ prior, and $\nu$ to have a flat prior.

Is there a way to have u ~ 1 || id, where id is the observation id, as the default for xbetax families? Correlated varying effects, more complicating grouping for u or fixed effects there, while easily accommodated by the facilities in brms and fits may be obtainable by HMC, are overkill and are not recommended because both u and phi control the response variance; the model may end up being formally not identifiable.

This is unforunately not possible as it would require too much special case coding. It has to remain the responsibility of the user.

Understood. This is not a big issue with detailed family-specific documentation.

Is there any way to implement family-specific errors if some conditions about the data are met? e.g. if no zero / one observations are in the responses, then throw a warning and propose the user fits a "beta" family; trying "xbetax" with flat priors on u or the parameters of its distribution can be a challenge for HMC in that case, and there is not much to gain compared to a "beta" family fit.

Good question. I will think about a good way to achieve this.

Thanks. This can also be useful to allow for checking that any required-by-the-family packages are attached in the namespace.

One more quick point: I don't think that such a detailed example of a cool but still niche model should be placed within the ?brm doc. I am not sure if brms has a good place for such detailed examples. Perhaps in the ?brmsfamily page. In any case, I don't think the betareg comparison is needed there, which would also allow you to drop the betareg suggests I believe.

I had considered moving them to ?brmsfamily, but the existing examples were mostly about defining family objects rather than fitting them, and I did not want to contaminate them :). Happy to put it there. Another option would be to have family vignettes. This would allow the space for more detailed discussion about certain families and their quirks. Happy to produce either.

betareg is in suggests because it provides the XBeta() function that defines the extended-beta distribution; then the methods of the distributions3 R package are used to compute log-likelihoods, predictions, etc. I just pushed a version which uses only methods in betereg (dxbeta(), rxbeta()) and a copy of betareg:::mean_xbeta(), which we can avoid if we export the latter in a future release of betareg. So distributions3 is now not necessary, but betareg in Suggests is.

Best regards
-Ioannis

paul-buerkner · 2024-10-29T07:43:47Z

Thanks!

I see. I don't think there is a pretty way to do it. And even the ugly ones that come to mind (injecting Stan code via stanvar are probably not going to work super well. Does the regular normal random effects version work well enough?

About the suggested packages: Okay, makes sense.

I will now review the PR.

paul-buerkner

I think a lot of this PR already looks good and I hope my comments help you to make it merge ready.

Please also add tests for the new functionality. In particular, in addition to some basic tests (see the tests folder), you could add what is your current detailed example in the local tests folder (in tests/local/tests-models-5.R). There it would be great because we had direct validation against betareg even.

R/brm.R

R/families.R

R/posterior_epred.R

R/posterior_predict.R

R/family-lists.R

R/posterior_predict.R

paul-buerkner · 2024-10-29T08:00:45Z

inst/chunks/fun_xbetax.stan

+   * Returns:
+   *   a scalar to be added to the log posterior
+   */
+   real xbetax_lpdf(real y, real mu, real phi, real u) {


can these functions also be vectorized and if yes, would that speed of the sampling speed? The latest versions of Stan allow function overloading also for user-defined functions so you can define the same function multiple times just with different argument signatures.

It is totally alright not to have a vectorized version. I just wanted to ask to be sure.

Happy to give that a shot and run some comparisons. Do you know of any vectorized implementation already in brms or elsewhere that I can look at?

Looking at it again, I think we do not need a vectorized version for this PR. I saw you already started and I am sorry I caused you extra work. The reason is the getting speed improvement out of the vectorized version requires a bit more effort since we need to group the y into those that fall into the different categories defined by the if statements. Kind of the same thing as for zero-inflated models, which are also not vectorized for now. In order to safe your time, I would say that the non-vectorized version alone is good enough.

No worries. I'll give it another shot and if all fails we default to the scalar version.

okay! to be clear: we need the scalar version in any case. an additional vectoriced version may just be helpful to speed up sampling. but this will only be beneficial if the lpdf statements are victorized that is called at the same time for multiple y.

Suppose you have build a vectorized version vectorized only over mu but not over phi and kappa. Then you reqn = TRUE only if phi or kappa is predicted or some addition terms are used (like weights), which prevents vectorization from being valid. At the same time, vec = TRUE is only valid if you only predict mu (and keep phi and kappy constant) because you have only build a vectorized version for this case.

Again, I believe my suggestion to make a vectorized version was not a good once since your family would likely require quite a bit of work to benefit from vectorization.

I think I got a vectorized version in all mu, phi, kappa in commit 31193c8.
Ugly indexing, but it is a start, and I may be able to improve it further/

Would

stan_log_lik_xbetax <- function(bterms, ...) { p <- stan_log_lik_dpars(bterms, reqn = FALSE) sdist("xbetax", p$mu, p$phi, p$kappa, vec = TRUE) }

be enough to use it? I see

R> stan_log_lik_dpars(bterms, reqn = FALSE) $mu [1] "mu" $phi [1] "phi" $kappa [1] "kappa"

and

sdist("xbetax", p$mu, p$phi, p$kappa, vec = TRUE) $dist [1] "xbetax" $args [1] "mu, phi, kappa" $vec [1] TRUE $shift [1] "" attr(,"class") [1] "sdist"

and in the output of stancode() we have target += xbetax_lpdf(Y | mu, phi, kappa)

Does that do it?

P.S.: I might need to check for only ones, only zeros or both ones and zeros but that's easy to do now

I think the vectorized version looks good. Now the problem is that this will only work if all 3 parameters are predicted, which will often not be the case. So I would argue you vectorize (only) the most common case which is, I assume only mu being predicted. Can you check if that leads to relevant speed-ups?

I will fix the reqn myself before I merge.

With all three parameters predicted, and a single run, I get:

Vectorized:

Chain 1: Elapsed Time: 232.716 seconds (Warm-up) Chain 1: 50.756 seconds (Sampling) Chain 1: 283.472 seconds (Total)

Scalar:

Chain 1: Elapsed Time: 253.758 seconds (Warm-up) Chain 1: 108.226 seconds (Sampling) Chain 1: 361.984 seconds (Total)

which looks good. I will experiment with only one or two parameters being predicted, and report back

inst/chunks/fun_xbetax.stan now has all eight versions of xbeta_lpdf, depending on whether mu, phi, kappa are real or vector. So, given the right call, STAN should figure out which one to use.

What I could not get my head around from the limited time I had to experiment is how brms decides which version to use. For some reason, the default stan_log_lik_adj(bterms) did not do it, but I admit I did not dig further.

For now, I forced the use of the non-vectorized version in the commit for now, having

stan_log_lik_xbetax <- function(bterms, ...) { p <- stan_log_lik_dpars(bterms, reqn = TRUE) sdist("xbetax", p$mu, p$phi, p$kappa, vec = FALSE) }

See, 6524911

I'm looking forward to seeing how that choice can be made automatically, when you merge.

ikosmidis · 2024-10-29T08:04:01Z

Thanks!

I see. I don't think there is a pretty way to do it. And even the ugly ones that come to mind (injecting Stan code via stanvar are probably not going to work super well. Does the regular normal random effects version work well enough?

Yes. This is fine; both exponential and log normal give essentially the same fit; I would rather avoid injecting Stan code. Another advantage of the current specification is that the "xbetax" family directly benefits from future enhancements/features in terms, etc., and the user can experiment with other specifications for the exceedances $U_i$ (though the latter may be asking for trouble for some data sets).

About the suggested packages: Okay, makes sense.

I will now review the PR.

Great stuff; thanks for doing that so promptly!

I will start preparing a vignette just in case; it can either go in the brms vignette, or I can publish it on my page for future reference (and testing).

paul-buerkner · 2024-10-29T08:08:24Z

I think a vignette would be great! I don't think it can go into brms itself though because CRAN already complains about package size and every vignette contributes to it. So I had to stop adding new vignettes to the package unfortunately.

wds15 · 2024-10-29T22:51:23Z

Instead of vignettes you can have so called articles. The articles go only on the pkgdown generated web site and not on CRAN. For RBesT (https://opensource.nibr.com/RBesT/), I have dropped but just one vignette and moved the rest to be an article.

paul-buerkner · 2024-10-30T07:10:01Z

Let me know when you think this PR is ready for another round of review.

ikosmidis · 2024-10-30T09:23:39Z

Let me know when you think this PR is ready for another round of review.

Sure. Let's have another round of review now.

The other things I'd like to do are

Add tests for the xbetaxfamily
Prepare the vignette

I will start with 1. now. I have the material for 2. but I will wait to wrap that up when the PR has been merged.

paul-buerkner

Thanks! The PR has become much better! Some issues remain which I have commented on.

R/families.R

R/family-lists.R

paul-buerkner · 2024-10-31T08:23:10Z

inst/chunks/fun_xbetax.stan

+   }
+
+   real xbetax_lpdf(vector y, vector mu, real phi, vector kappa) {
+      vector[1] phiv;


I don't think this will work as you expect. You also need to handle the fact that phi for example is not of length 1 not of length N. I believe your fully vectorized version expects all vectors to be of the same length as y. This issue holds for all these partial vector versions.

OK. I see now. The vectorized versions in commit e8b3352 should now work as expected. I tested things around with the LossAversion data (the example I had in ?brm and will appear in the vignette) and despite it being relatively small we can already see speedups.

Here is a comparison in elapsed times between vectorized and non-vectorized implementations

where the x axis is what components are passed to brm, based on 20 replications per model with init = 0, chains = 1, iter = 2000.

The fits between vectorized and non-vectorized implementations are the same.

I can also share the script that reproduces the figure and carries out the tests on the brmsfit objects. If you want that what is the right place to push it (tests/local?)?.

One thing I wanted to ask: is there any value in having vectorized functions with real mu, e.g.

xbetax_lpdf(vector y, real mu, vector phi, real kappa)

? These are not difficult to setup, but I am not sure if rbm would ever pass real mu to the compiled STAN code

Thank you! I will now do some edits to the PR and let you know for a final check before merging.

About your question: mu will indeed always be a vector in brms so no need to have a vectorized real mu implementation.

R/stan-likelihood.R

Given the generality of the family allowing for arbitrary specification of the kappa regression structures it is best to use to `xbeta`, as the family implements the extended-support beta only. The correspodning to `xbetax` then results if kappa ~ 1 || id is used

paul-buerkner · 2024-11-07T13:08:12Z

As I am editing your PR I decided to substantially shorten your description in the ?brmsfamily doc. You can write a bit more (but please not so many) details in the brmsfamilies vignette.

paul-buerkner · 2024-11-07T13:52:52Z

I have made some edits to the PR. I think it should basically be ready now.

I noticed that the posterior_predict test was still missing. Was this intentional?

ikosmidis · 2024-11-07T16:51:22Z

As I am editing your PR I decided to substantially shorten your description in the ?brmsfamily doc. You can write a bit more (but please not so many) details in the brmsfamilies vignette.

I have added a bit more details; mainly to advise users when xbeta is better to use than hurdle beta families.

ikosmidis · 2024-11-07T16:51:33Z

I have made some edits to the PR. I think it should basically be ready now.

I noticed that the posterior_predict test was still missing. Was this intentional?

Added some tests, too.

ikosmidis · 2024-11-07T16:58:40Z

All looks good to me now, and my local tests pass after your edits.

Just a few things that I would like to keep on the todo list, related to the discussion above:

Is there any way to implement family-specific errors if some conditions about the data are met? e.g. if no zero / one observations are in the responses, then throw a warning and propose the user fits a "beta" family; trying xbeta or the parameters of its distribution can be a challenge for HMC in that case, and there is not much to gain compared to a "beta" family fit. Similarly, if 0/1's are detected with beta family, an error can inform the user to use xbeta or the one/two-part hurdle models instead, directing them to the documentation for details.
I will prepare a blog post for my web page and release it when the new version is on CRAN. I'd be happy to convert it to a vignette when/if family-specific vignettes come to the package pages / CRAN.

I'm happy for this to be merged.

Thanks for the input and for being open to having thexbeta family in rbms.

paul-buerkner · 2024-11-08T07:08:28Z

Thank you!

I think it makes sense to open a new issue for that as I have to implement the mechanism allowing for such errors and messages.
Thank you for writing a vignette!

I will now run a few more checks and then merge if they pass.

paul-buerkner · 2024-11-08T07:23:55Z

Unrelated question: Could a similar strategy that you employ also be used for lower-bounded families such as, say, Gamma or lognormal? This way, one may be able to avoid hurdle_gamma or hurdle_lognormal as well if the aim is to model a single rather than multiple different responses processes.

paul-buerkner · 2024-11-08T08:13:37Z

checks fail online for unrelated reasons, but pass locally. So i am going to merge this PR.

Thank you for contributing to brms and providing this amazing new feature!

zeileis · 2024-11-08T09:34:04Z

Regarding the applicability to other lower-bounded families: Yes, in principle, this is doable and worth trying out.

I think it is not always quite as appealing as in the beta case where we can leverage results for the four-parameter beta distribution and also get the connection to the normal distribution.

For the gamma distribution I also know that the idea of a censored shifted gamma distribution has been proposed by Baran & Nemoda 2016, Environmetrics. So this is similar in spirit but without the continuous mixture of the shift (corresponding to our exceedance parameter) for shrinking it twoards zero.

ikosmidis · 2024-11-11T15:06:55Z

Regarding the applicability to other lower-bounded families: Yes, in principle, this is doable and worth trying out.

I think it is not always quite as appealing as in the beta case where we can leverage results for the four-parameter beta distribution and also get the connection to the normal distribution.

For the gamma distribution, I also know that the idea of a censored shifted gamma distribution has been proposed by Baran & Nemoda 2016, Environmetrics. So this is similar in spirit but without the continuous mixture of the shift (corresponding to our exceedance parameter) for shrinking it twoards zero.

Yes, indeed. Beta is convenient because we can extend the support, and we establish results linking the resulting distribution to the normal linear model.

However, nothing prevents trying the same methodology to other distributions with bounded support. For example, with Gamma or Log-normal, one could subtract $\kappa$ from a Gamma-distributed random variable and link that to varying/population effects. I guess this can be implemented in full generality in brms. Still, identifiability issues must be examined carefully on an ad-hoc basis, especially for location-scale families with location and scale specifications.

ikosmidis added 9 commits October 28, 2024 11:35

added xbetax family

04eacc2

Put xbetax statements to eof's for easy find

ca9d783

Added default priors for u

37b0c7d

Added u in stan_dpar_comments()

a843dd5

Documentation updates to include xbetax

fb5b1b2

xbetax example in ?brm

7606586

Fixed bug in get_xbetax()

31c4605

Moved get_xbeta() close to posterior_predict_xbetax()

30d9629

Added fun_xbetax.stan

ee1e1ab

ikosmidis marked this pull request as ready for review October 28, 2024 16:34

ikosmidis mentioned this pull request Oct 28, 2024

brms support for XBX regression #1699

Closed

ikosmidis added 3 commits October 28, 2024 23:13

Documentation updates

5593ac6

documentation improvements

88f7392

More doc updates

cbdad9e

ikosmidis added 2 commits October 29, 2024 06:36

xbetax documentation fixes

e7a4d18

Removed distributions3 from Suggests

b1e5aa0

paul-buerkner requested changes Oct 29, 2024

View reviewed changes

ikosmidis added 7 commits October 29, 2024 08:13

Removed xbetax example from ?brm

d706c6d

Added more detail in ?brmsfamily on xbetax` family

7cc5aa7

dpar u -> kappa + removed u from codebase + predictions shape

641fbd7

mean_xbeta() gets a bit more documentation

4f561ee

Use rcontinuous() in posterior_predict_xbetax()

d8b7e8c

A first attempt to vectorizing xbetax_lpdf

065be82

Vectorized version of xbetax_lpdf

31193c8

All 8 xbetax_lpdf versions depending on the type of mu, phi, kappa

6524911

ikosmidis added 2 commits October 30, 2024 09:58

Fixed bug in STAN code

a6c73c1

Minor documentation fixes

636bcdc

paul-buerkner requested changes Oct 31, 2024

View reviewed changes

ikosmidis added 6 commits October 31, 2024 17:19

Documentation fixes + else {

3f3f8e9

Updates to stan vectorized lpdf's

e8b3352

Redundant elementwise division

72031c5

Some tests about the xbeta family

e5fbf28

clean up the xbeta code a bit

3b87e01

ikosmidis and others added 5 commits November 7, 2024 14:51

Fixes to family documentation

92e94be

fix typo

1a6b000

Documentation updates

4640585

Merge branch 'xbetax' of github.com:ikosmidis/brms into xbetax

72fcb4b

xbeta posterior predict tests

cc5ec33

Merge branch 'master' into pr/1698

d2dd8c4

paul-buerkner merged commit 7a2eb2d into paul-buerkner:master Nov 8, 2024
0 of 5 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

brms support for XBX regression #1698

brms support for XBX regression #1698

ikosmidis commented Oct 28, 2024 •

edited

Loading

paul-buerkner commented Oct 28, 2024

ikosmidis commented Oct 29, 2024

paul-buerkner commented Oct 29, 2024

paul-buerkner left a comment

paul-buerkner Oct 29, 2024

ikosmidis Oct 29, 2024

paul-buerkner Oct 29, 2024 •

edited

Loading

ikosmidis Oct 29, 2024

paul-buerkner Oct 29, 2024

paul-buerkner Oct 29, 2024 •

edited

Loading

ikosmidis Oct 29, 2024 •

edited

Loading

paul-buerkner Oct 29, 2024 •

edited

Loading

ikosmidis Oct 29, 2024 •

edited

Loading

ikosmidis Oct 30, 2024

ikosmidis commented Oct 29, 2024

paul-buerkner commented Oct 29, 2024

wds15 commented Oct 29, 2024

paul-buerkner commented Oct 30, 2024

ikosmidis commented Oct 30, 2024

paul-buerkner left a comment

paul-buerkner Oct 31, 2024

ikosmidis Nov 1, 2024

ikosmidis Nov 1, 2024

paul-buerkner Nov 7, 2024

paul-buerkner commented Nov 7, 2024

paul-buerkner commented Nov 7, 2024

ikosmidis commented Nov 7, 2024

ikosmidis commented Nov 7, 2024

ikosmidis commented Nov 7, 2024

paul-buerkner commented Nov 8, 2024

paul-buerkner commented Nov 8, 2024

paul-buerkner commented Nov 8, 2024

zeileis commented Nov 8, 2024

ikosmidis commented Nov 11, 2024

brms support for XBX regression #1698

brms support for XBX regression #1698

Conversation

ikosmidis commented Oct 28, 2024 • edited Loading

Questions

Notes

Additions

paul-buerkner commented Oct 28, 2024

ikosmidis commented Oct 29, 2024

paul-buerkner commented Oct 29, 2024

paul-buerkner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paul-buerkner Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paul-buerkner Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

ikosmidis Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

paul-buerkner Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

ikosmidis Oct 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ikosmidis commented Oct 29, 2024

paul-buerkner commented Oct 29, 2024

wds15 commented Oct 29, 2024

paul-buerkner commented Oct 30, 2024

ikosmidis commented Oct 30, 2024

paul-buerkner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paul-buerkner commented Nov 7, 2024

paul-buerkner commented Nov 7, 2024

ikosmidis commented Nov 7, 2024

ikosmidis commented Nov 7, 2024

ikosmidis commented Nov 7, 2024

paul-buerkner commented Nov 8, 2024

paul-buerkner commented Nov 8, 2024

paul-buerkner commented Nov 8, 2024

zeileis commented Nov 8, 2024

ikosmidis commented Nov 11, 2024

ikosmidis commented Oct 28, 2024 •

edited

Loading

paul-buerkner Oct 29, 2024 •

edited

Loading

paul-buerkner Oct 29, 2024 •

edited

Loading

ikosmidis Oct 29, 2024 •

edited

Loading

paul-buerkner Oct 29, 2024 •

edited

Loading

ikosmidis Oct 29, 2024 •

edited

Loading