Yes, we should open an issue in tmpMCMC.jl. — John
> On Dec 7, 2014, at 8:42 AM, Rob J. Goedman <goed...@icloud.com> wrote: > > 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 > goed...@mac.com > > > > > >> On Dec 5, 2014, at 5:04 PM, John Myles White <johnmyleswh...@gmail.com> >> 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 <goed...@icloud.com> 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 <johnmyleswh...@gmail.com> >>>> 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 <goed...@icloud.com> 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 >>>>> goed...@mac.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >
