Hi John, Thanks, yes, I should have studied StatsBase.jl in more depth. I have been more focused on Distributions.jl.
It seems from my point of view, as a user, there are 3 or 4 levels: 1. BayesianModels, an abstract type that can contain specializations for a Bugs/Jags model, a Mamba model , Stan model, MCMC/Lora model, etc. 2. Types to hold a posterior set of samples, like Mamba’s Chains 3. Use of StatsBase’s StatisticalModel and RegressionModel to extract and compare summary stats 4. Additional (Bayesian specific?) posterior tools, like Mamba’s diagnostic and plotting capabilities. If we continue this discussion, maybe we should switch to JuliaStats or even tmpMCMC.jl? Regards, Rob J. Goedman [email protected] > On Dec 5, 2014, at 5:04 PM, John Myles White <[email protected]> wrote: > > StatsBase is meant to occupy that sort of role, but there's enough > disagreement that we haven't moved as far foward as I'd like. Have you read > through the StatsBase codebase? > > -- John > > On Dec 2, 2014, at 8:19 PM, Rob J. Goedman <[email protected]> wrote: > >> Thanks John, I’d come to a similar conclusion about there not being a >> straightforward solution. Nice to get that confirmed from your side. Cutting >> back on exporting names whenever possible also makes a lot of sense. >> >> Is StatsBase intended to play a similar role for types? Or is that more the >> domain of PGM.jl? >> >> As an example, Model is used in several packages (MCMC, Mamba). This makes >> using both packages simultaneously harder as the end user needs to figure >> out which names to qualify. Other packages have taken a different approach. >> MixedModels uses MixedModel and LinearMixedModel, GLM uses LmMod and GlmMod, >> Stan and Jags use Stanmodel and Jagsmodel (I could rename them to StanModel >> and JagsModel). Is it reasonable to make Model an abstract type? >> >> Rob >> >> >>> On Dec 2, 2014, at 4:37 PM, John Myles White <[email protected]> >>> wrote: >>> >>> There's no clean solution to this. In general, I'd argue that we should >>> stop exporting so many names and encourage people to use qualified names >>> much more often than we do right now. >>> >>> But for important abstractions, we can put them into StatsBase, which all >>> stats packages should be derived from. >>> >>> -- John >>> >>> On Dec 2, 2014, at 4:34 PM, Rob J. Goedman <[email protected]> wrote: >>> >>>> I’ll try to give an example of my problem based on how I’ve seen it occur >>>> in Stan.jl and Jags.jl. >>>> >>>> Both DataFrames.jl and Mamba.jl export describe(). Stan.jl relies on >>>> Mamba, but neither Stan or Mamba need DataFrames. So DataFrames is not >>>> imported by default. >>>> >>>> Recently someone used Stan and wanted to read in a .csv file and added >>>> DataFrames to the using clause in the script, i.e. >>>> >>>> ``` >>>> using Gadfly, Stan, Mamba, DataFrames >>>> ``` >>>> >>>> After running a simulation, Mamba’s describe(::Mamba.Chains) could no >>>> longer be found. >>>> >>>> I wonder if someone can point me in the right direction how best to solve >>>> these kind of problems (for end users): >>>> >>>> 1. One way around it is to always qualify describe(), e.g. >>>> Mamba.describe(). >>>> 2. Use isdefined(Main, :DataFrames) to upfront test for such a collision. >>>> 3. Suggest to end users to import DataFrames and qualify e.g. >>>> DataFrames.readtable(). >>>> 4. ? >>>> >>>> Thanks and regards, >>>> Rob J. Goedman >>>> [email protected] >>>> >>>> >>>> >>>> >>>> >>> >> >
