Am 16.03.2024 um 17:22 schrieb Brian Revell: Luca has had some email problems lately, perhaps he didn't get this one. I believe that NI stands for non-informative and I for informative, which typically refers to the prior used. So basically the NI results should be purely data-driven, which usually means the max-likelihood or frequentist quantities. This is just for comparison, a Bayesian would of course go for the informative ones. (Provided she really believes in the prior, which for some reason doesn't seem to happen all that often in reality, but that's a different story.) Luca may correct me eventually, but it seems those things are not directly available. I guess this makes sense from a Bayesian perspective since it gives you densities, not point estimates. For example, do you want to consider the posterior mean, median or mode as your quasi-point estimate? All imply different sets of residuals. In principle they could all be stored of course, but it's not clear whether that's the most practical thing to do. Having said that, it looks like for the coefficients (in the sub-bundle post_summ) the means are stored, so in that context this arbitrary choice was made, apparently. So for the CASE 1 in the sample script with covariates list X, I guess you could try:  lincomb(X, out.post_summ.post_betamean) to get the fitted values. (Untested.) Sorry, I don't understand. What URL? cheers sven

Hi Brian, thanks for the message and thank you Sven for the quick reply. Unfortunately I’ve been experiencing some issues with the mailing list recently: I’m receiving the messages late or not at all! Sorry! As for your original questions, the function by default will generate non-informative results (frequentist) alongside the informative ones (truly Bayesian, obtained via the chosen prior): the idea behind is to have a direct comparison between the two. In the resulting output bundle you can access both of them: the sub-bundle non_info_case reports all basic frequentist estimators; while for the informative results you can access two different sub-bundles: i) sampled_coeff which contains all the sampled parameters and from which you can recover quantiles or any sort of function; and ii) post_summ, which simply reports posterior means and standard deviations. In the sample script the informative prior is “not so informative”, for this reason the results are quite similar to the frequentist ones. But if you have to choose which posterior quantity to use between non-informative and informative, always use the informative one. Moreover, if you have to compute some functions on the posterior quantities, I suggest computing them on the sampled parameters and not simply on the posterior mean. In this way, you can derive a distribution and more exact conclusions. As for the residual questions, these are not stored: storing residuals for each sampled parameter will drain quickly the computer memory, especially with big dataset, for this reason, these are not saved. However, you can recover it via the sampled coefficients. I hope this may help and if you have any other questions or doubts, do not hesitate to ask! Best regards, Luca Da: Brian Revell <bjr.newmail(a)gmail.com&gt; Data: lunedì, 1 aprile 2024 23:18 A: Gretl list <gretl-users(a)gretlml.univpm.it&gt; Oggetto: [Gretl-users] Re: BayTool Package Thanks Sven for the detailed explanstion.. I had eventually arrived at the conclusion that the mean value of the density was the point estimate being output albeit that the densities for each parameter were also an output plot option. It would seem then that the residuals from the mean values are not retrievable (yet) from running the GUI version, which incidentally has now attached itself permanently as an option within univariate options. It would appear in many applied studies that the parameter means with credible intervals are employed. In a forecasting or projection context with Bayesian estimation of time series data, one might suppose that the residuals would clearly still be important for post estimation diagnosis regarding stationarity and serial correlation. Brian On Mon, 1 Apr 2024, 20:55 Sven Schreiber, <sven.schreiber@fu-berlin.de<mailto:sven.schreiber@fu-berlin.de>> wrote: Am 16.03.2024 um 17:22 schrieb Brian Revell: Hi I have tried using the BayTool package with some success (in terms of getting output), I have read (perhaps not well enough) the detailed paper by Luca Pedini. Luca has had some email problems lately, perhaps he didn't get this one. However, I am puzzled why when simply using the linear model with conjugate prior, as a default I get two sets of posterior mean parameter and se estimates -NI-post m and I post-m and NI-Pst se and I-post se. . Looking at the graphs of the Gaussian Posterior density estimates, they appear to more closely centred on the I-pos -mean. Although the difference s between the N & O posterior estimates is small, what is the basis for selecting one rather than the other? I believe that NI stands for non-informative and I for informative, which typically refers to the prior used. So basically the NI results should be purely data-driven, which usually means the max-likelihood or frequentist quantities. This is just for comparison, a Bayesian would of course go for the informative ones. (Provided she really believes in the prior, which for some reason doesn't seem to happen all that often in reality, but that's a different story.) Second question - how can I retrieve the fitted values and residuals from theB-Took Package. Hopefully it resides somewhere to be retirieved post estimation. Or is iit necessary to run the input data through the equation to generate it onself -and if so, which set of posterior mean estimates does one use? Luca may correct me eventually, but it seems those things are not directly available. I guess this makes sense from a Bayesian perspective since it gives you densities, not point estimates. For example, do you want to consider the posterior mean, median or mode as your quasi-point estimate? All imply different sets of residuals. In principle they could all be stored of course, but it's not clear whether that's the most practical thing to do. Having said that, it looks like for the coefficients (in the sub-bundle post_summ) the means are stored, so in that context this arbitrary choice was made, apparently. So for the CASE 1 in the sample script with covariates list X, I guess you could try: lincomb(X, out.post_summ.post_betamean) to get the fitted values. (Untested.) PS -the BayTool package does not seem to attach permanently to the URL "model" list of options. Sorry, I don't understand. What URL? cheers sven _______________________________________________ Gretl-users mailing list -- gretl-users@gretlml.univpm.it<mailto:gretl-users@gretlml.univpm.it> To unsubscribe send an email to gretl-users-leave@gretlml.univpm.it<mailto:gretl-users-leave@gretlml.univpm.it> Website: https://gretlml.univpm.it/postorius/lists/gretl-users.gretlml.univpm.it/