Re: "program" vs. "model" for Stan 3

[Bob Carpenter]

[moved to stan-dev]

Absolutely. I think the terminology we want to follow
is that a Stan program is a concrete implementation of a model.

Now we have to be careful with reparameterizations, which
technically change the model if the model is defined as
the density on the unconstrained scale, but can be set up
in such a way as to maintain all the inferences we care about
from the original model.

- Bob

> On Jan 2, 2016, at 8:32 PM, Allen B. Riddell <a...@ariddell.org> wrote:
>
> Hi Bob,
>
> I really like the distinction between "model" and "program" that you
> mentioned as being something that should be adopted for Stan 3. (see:
> https://github.com/stan-dev/stan/wiki/User-Interface-Guidelines-for-Developers)
>
> Are you still in favor of this renaming? If so, should there be a goal
> to replace 'model' with 'program' in the C++ API in addition to the
> interfaces? For example, should `compile` in stan::lang be updated from
> taking an argument `model_name` to `program_name`? Or is this
> distinction only something that's going to exist at the interface
> (RStan/PyStan) level?
>
> (This question occurred to me as I write tests for stan::lang::compile
> in protostan.)
>
> Best,
>
> Allen
>

[Allen B. Riddell]

Just double checking about this:

So when we (in Stan 2.x days) talked about 'parameters {real y;} model
{y ~ normal(0,1);}' as "model code" (which typically was associated with
a model name like `anon_model`) we should instead (in Stan 3) refer to
this as "program code" associated with a "program name"? For example,
the (Python) signature for the StanProgram constructor (née StanModel)
should be `StanProgram(program_code, program_name)`. If so, is the goal
eventually to have this reflected in the C++ API as well (`model_name`
occurs in 13 files under the stan tree)?

Best,

Allen

> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Bob Carpenter]

> On Jan 4, 2016, at 10:25 AM, Allen B. Riddell <a...@ariddell.org> wrote:
>
> Just double checking about this:
>
> So when we (in Stan 2.x days) talked about 'parameters {real y;} model
> {y ~ normal(0,1);}' as "model code" (which typically was associated with
> a model name like `anon_model`) we should instead (in Stan 3) refer to
> this as "program code" associated with a "program name"?

Correct. Any real code is a program. I was very sloppy
with this originally, but Andrew has reformed me :-)

> For example,
> the (Python) signature for the StanProgram constructor (née StanModel)
> should be `StanProgram(program_code, program_name)`. If so, is the goal
> eventually to have this reflected in the C++ API as well (`model_name`
> occurs in 13 files under the stan tree)?

Yes. Feel free to open an issue and assign it to me or
just go in and clean it up yourself in the C++ code (on
a branch named after an issue, of course).

- Bob

[Andrew Gelman]

Yes I’ve thought for awhile that it was unfortunate that we used the term “model” for the block of the Stan code that computes lp. Since that block is the “model,” we use “program” to refer to the entire Stan program with all its blocks.

[Bob Carpenter]

The name "model" for that block was a bad choice.

The log density is actually implemented on the unconstrained
params, and has terms that can be defined in any of the blocks.
The log Jacobian for the transforms is added automatically and
other terms are added in the model block, but subexpressions can
come from all the other blocks.

- Bob

[Michael Betancourt]

I would argue that it’s a fine name. We’re trying to specify
a model via a posterior, p(parameters | data), which means
defining inputs (data, parameters) and then the posterior
itself (model). Other blocks are just convenient intermediates.

[Allen B. Riddell]

Is the idea also to have support in Stan 3 for someone using 'program'
instead of 'model' for that block (i.e., in the program code itself).

Thanks,

-a

[Bob Carpenter]

No. Andrew's beef (see below) was that we were
using "model" for the block and the whole program.

We're also overloading it to be the log density
defined on the unconstrained parameters, but that's
a different story.

- Bob

[Andrew Gelman]

Bob has correctly identified my beef.

[Ben Goodrich]

On Tuesday, January 5, 2016 at 5:58:26 PM UTC-5, Bob Carpenter wrote:

No.  Andrew's beef (see below) was that we were
using "model" for the block and the whole program.

Consequently, I think it would make sense for RStan 3 and PyStan 3 to
change model_code to program_code as the argument name for several
functions.

Ben

[Andrew Gelman]

Good point.

[Allen B. Riddell]

Good. It sounds like we're all on the same page.

[Jiqiang Guo]

I agree that a cmdstan executable is a program.

But I think model is a better word for the whole Stan code specifying model data, parameters, posterior, etc.  In addition, using program, Stan users will be called programmers rather than modellers.

Jiqiang 

[Andrew Gelman]

J

But I think it’s super-confusing for the term “model” to be used both for a single block of code and for the whole program. As long as that little block is called the model, I think we have to call the whole thing the program.

A

[Michael Betancourt]

Model -> Abstract probabilistic system

In practice we need a representation of that system.  Probabilistic

programming uses programs to represent models, hence

Program -> Concrete representation of model

The language itself is entirely appropriate.

[Allen B. Riddell]

Given that both the language and the interface behavior is changing
significantly in Stan/PyStan/Rstan 3 switching to 'program_code' from
'model_code' will help reinforce that things are indeed different.

Are you objecting to using 'program_code' and 'program_name'?

[Bob Carpenter]

+1. That's the standard distinction in computer science:
function vs. implementation, the former being abstract
and the latter concrete.

- Bob

[Bob Carpenter]

Maybe. It'll also break people's old code.

The one thing we have to fight strongly against is forking.
If things change enough, people will just lock in whatever 2.x
they're using and not update. Just look at what happened
to Python and is now happening to Julia.

Luckily, unlike those two languages, people probably haven't
built packages around RStan, PyStan, etc., other than us anyway.

- Bob

[Ben Goodrich]

On Wednesday, January 6, 2016 at 1:35:36 PM UTC-5, Bob Carpenter wrote:

Luckily,  unlike those two languages, people probably haven't
built packages around RStan, PyStan, etc., other than us anyway.

Actually, there are 5 packages that depend on RStan that aren't maintained by us

https://cran.r-project.org/web/packages/rstan/index.html

But if everything else is breaking for version 3, then I don't think naming arguments with program is that much of an additional burden.

Ben

[Allen B. Riddell]

People are forking Julia?

Python 3 has been accepted by the scientific computing/data analysis
folks within Python. I think it's the people using Python for network
services and system administration tasks that have been refusing to
switch. See http://www.snarky.ca/the-stages-of-the-python-3-transition

Best,

Allen

[Bob Carpenter]

It's been an ongoing ugly transition since Python 3.0
was officially released way back in 2008 because of the
lack of backward compatibility. The Python project has
been trying to get people off 2.x for over 7 years! When
I worked on a project in 2010 or so, I couldn't use 3.x
because of client issues with it (it was natural language
processing).

From the current Python 2 vs. Python 3 notes on python.org (my highlighting):

Guido van Rossum (the original creator of the Python language)
decided to clean up Python 2.x properly, with less regard for
^^^^^^^^^^^^^^^^^^^^
backwards compatibility than is the case for new releases in
^^^^^^^^^^^^^^^^^^^^^^^
the 2.x range. The most drastic improvement is the better
Unicode support (with all text strings being Unicode by default) as
well as saner bytes/Unicode separation.

However, the broader Python ecosystem has amassed a significant amount
of quality software over the years. The downside of breaking backwards
compatibility in 3.x is that some of that software (especially in-house
software in companies) still doesn't work on 3.x yet.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Julia's now simultaneously working on versions 0.4
and 0.5, with no backward compatiblity and packages forking
based on version, with some people still stuck on 0.3 (though
I have no idea how many). At Julia Con, the main devs spent a lot of
time discussing backward-compatibility breaking changes. I'd
be way too timid to start developing in Julia now. Julia has
this for 0.3 to 0.4 transitions:

https://github.com/JuliaLang/Compat.jl

but I don't know if it works and is certainly got to be a major
hassle to implement. There's a summary on that page's README about
how much has changed from 0.3 to 0.4. But see this discussion on reddit:

https://www.reddit.com/r/Julia/comments/2zme0y/timeframe_on_productionready_release_of_julia/

where 0.4 is described as the "break everything" release. But then

Regardless of the final scope of 0.4, 0.5 is going to have quite a
few major changes in it that were holdovers that didn't make it into 0.4.

But lets just say their referring to 0.5 as "Arraypocalypse" had me worried.
(I'm neither Australian nor Alfred E. Neuman.):

https://github.com/JuliaLang/julia/issues/13157

- Bob