Remaining work for v2.0.2

[Daniel Lee]

We'll release v2.0.2 soon. The list of issues remaining are here: https://github.com/stan-dev/stan/issues?direction=asc&milestone=5&page=1&sort=created&state=open

Once these items get cleared, we'll get a release out.

If you've got some time and want to help out, feel free to take on the issues on this list. I'll get through half the list tonight (all the easy stuff like moving and removing files).

Daniel

[Michael Betancourt]

What happened to improve_nuts_diagnostic?  The potential conflicts with the interfaces were shown to be moot and I really need it in for this paper release.

--
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/groups/opt_out.

[Michael Betancourt]

Also 356 seems to have dropped off.  Same need as with the nuts diagnostic branch - was there a decision to not include these?  They should both be ready for testing, I am not aware of any outstanding issues.

On Nov 21, 2013, at 12:31 AM, Daniel Lee <bea...@alum.mit.edu> wrote:

[Daniel Lee]

For #352 (feature/improve nuts diagnostic), it still has both "n_divergent__" and "n_divergence__" in the doc. @Michael: change the "n_divergence__" to "n_divergent__" and we'll get it back on the testing queue and merge it.

For #356 (feature/flexible adaptation), it can't be merged automatically from the command line. @Michael: can you merge in develop into the branch? @Bob, is this good to merge after fixing "fast" and "slow" in scary quotes? Just FYI, the first use of "fast" and "slow" are italicized.

[Michael Betancourt]

Thanks for the head's up.

> For #352 (feature/improve nuts diagnostic), it still has both "n_divergent__" and "n_divergence__" in the doc. @Michael: change the "n_divergence__" to "n_divergent__" and we'll get it back on the testing queue and merge it

Resolved.

> For #356 (feature/flexible adaptation), it can't be merged automatically from the command line. @Michael: can you merge in develop into the branch? @Bob, is this good to merge after fixing "fast" and "slow" in scary quotes? Just FYI, the first use of "fast" and "slow" are italicized.

Merged. I will defend those italics to the death! I mean, I'm pretty sure they're reasonable style.

[Bob Carpenter]

On 11/21/13, 10:41 AM, Michael Betancourt wrote:
...

> Merged. I will defend those italics to the death! I mean, I'm pretty sure they're reasonable style.

In this particular case, I think the quotes around "fast" and "slow"
signal that you haven't quite come up with the right terminology.
Instead, you're adapting some commonly used words to do slightly different
work. If that's not what you intended to signal, then the usage is wrong.

Here's an excellent summary of this kind of quote usage:

http://en.wikipedia.org/wiki/Quotation_mark#Signaling_unusual_usage

I'm with the U Chicago Manual of Style on this one.

The unusual usage application comes very close to what are commonly
called "scare quotes":

http://en.wiktionary.org/wiki/scare_quote

So just imagine yourself making air quotes every time you use them
and you should be OK.

- Bob

P.S. All of the quotes in this email signal mentions of words, not uses
of words:

http://en.wikipedia.org/wiki/Quotation_mark#Use.E2.80.93mention_distinction

P.P.S. Next week on the grammar channel, we'll pit "Markov chain Monte Carlo"
and "no-U-turn sampler" against "Markov Chain Monte Carlo" and
"No-U-Turn Sampler".

[Bob Carpenter]

We were really hoping to just get bug fixes in a quick
release, but there are a lot of little bug fixes queued up.

If we introduce significant new features, like finer-grained
adaptation, we should bump the minor version up to 2.1.0.

I'd rather prioritize bug fixes over adding functionality.

I'd be happy doing a 2.1.0 very soon after 2.0.2 with all the
new functionality that's queued up.

We could skip 2.0.2, but I'm just worried about delays in fixing
bugs, and each new pull request takes time.

- Bob

On 11/21/13, 3:22 AM, Michael Betancourt wrote:
> Also 356 seems to have dropped off. Same need as with the nuts diagnostic branch - was there a decision to not include
> these? They should both be ready for testing, I am not aware of any outstanding issues.
>

> On Nov 21, 2013, at 12:31 AM, Daniel Lee <bea...@alum.mit.edu <mailto:bea...@alum.mit.edu>> wrote:
>
>> We'll release v2.0.2 soon. The list of issues remaining are here:
>> https://github.com/stan-dev/stan/issues?direction=asc&milestone=5&page=1&sort=created&state=open
>>
>> Once these items get cleared, we'll get a release out.
>>
>> If you've got some time and want to help out, feel free to take on the issues on this list. I'll get through half the
>> list tonight (all the easy stuff like moving and removing files).
>>
>>
>>
>> Daniel
>>
>> --
>> 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 <mailto:stan-dev+u...@googlegroups.com>.

[Michael Betancourt]

If these guys aren't in in the next few days the paper is going to be non-trivially compromised. Given the time at which the pull-requests were made, and the number of additional fixes that were added after that, I don't' think think this is at all unreasonable.

[Michael Betancourt]

They're italics, as in emphasizing a word when it is first introduced. That falls into the common
convention of many styles.

[Daniel Lee]

On Thu, Nov 21, 2013 at 3:19 PM, Michael Betancourt <betan...@gmail.com> wrote:

If these guys aren't in in the next few days the paper is going to be non-trivially compromised.

I don't quite follow. Can't you state that it'll be out in v2.1.0?

 

 Given the time at which the pull-requests were made, and the number of additional fixes that were added after that, I don't' think think this is at all unreasonable.

Most of the additional fixes were bug fixes, not changes to behavior in working code. I messed up the process by not creating a hotfix branch right away and we had some minor non-bugfixes in there. But mostly bugs. We want to release to squash bugs that exist in v2.0.1.

Although timing since submission is important, it isn't what I'm prioritizing for a patch release. #352 seems pretty tame, but #356 is a different. That's designed to have a different behavior: 0.8 vs 0.65 as the target acceptance probability. (I didn't realize that this actually had different behavior until Bob reminded me... I must have been too tired when I looked over it.) There are also a bunch of classes that were introduced, but no additional tests, in that pull request. (Another thing I missed.)

So, I think it'll be better to hold these features for the next feature release, v2.1.0, which we can release right after v2.0.2. (By right after, I mean after having those pull requests tested, verified, and pulled in, so another couple days at the soonest?)

So going back to the paper, how will it be compromised? Is it not sufficient to state that it's in v2.1.0?

[Bob Carpenter]

I assume you (Michael) want to be able to say in the paper
that you generated the results using a recreatable hash
tag in GitHub. I can respect that commitment to reproducibility.

Can you just create a separate branch that has a tag for
what you used for the paper and point people to that?
I'd rather you do that in a personal repo, so we don't have long-term
clutter in the form of Stan branches that are no longer under
development.

Alternatively, we can try to prioritize merging your pull request
into develop and you can tag that. Develop and its history will persist,
at least while we're on GitHub.

Long term, you may be better off just making a tarball that's
under your control. I think we'll be able to keep the tarballs
(now zipballs) for official releases, but it's going to be
a few days before we can even get 2.0.2 out, and that sounds like
it's going to be too late for your schedule even if we do commit
to releasing a 2.1.0 with your pull request instead of a simpler
2.0.2 patch release. There's the issue of RStan and PyStan catching
up, too, but there's no reason we can't release Stan version N before
RStan or PyStan version N.

- Bob




On 11/21/13, 3:33 PM, Daniel Lee wrote:

> <mailto:bea...@alum.mit.edu <mailto:bea...@alum.mit.edu>>> wrote:
> >>
> >>> We'll release v2.0.2 soon. The list of issues remaining are here:
> >>> https://github.com/stan-dev/stan/issues?direction=asc&milestone=5&page=1&sort=created&state=open
> >>>
> >>> Once these items get cleared, we'll get a release out.
> >>>
> >>> If you've got some time and want to help out, feel free to take on the issues on this list. I'll get through
> half the
> >>> list tonight (all the easy stuff like moving and removing files).
> >>>
> >>>
> >>>
> >>> Daniel
> >>>
> >>> --
> >>> 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 <mailto:stan-dev%2Bunsu...@googlegroups.com>
> <mailto:stan-dev+u...@googlegroups.com <mailto:stan-dev%2Bunsu...@googlegroups.com>>.

> >>> For more options, visit https://groups.google.com/groups/opt_out.
> >>
> >> --
> >> 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 <mailto:stan-dev%2Bunsu...@googlegroups.com>.

> >> For more options, visit https://groups.google.com/groups/opt_out.
> >
> > --
> > 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 <mailto:stan-dev%2Bunsu...@googlegroups.com>.

> > For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> 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 <mailto:stan-dev%2Bunsu...@googlegroups.com>.

[Bob Carpenter]

On 11/21/13, 3:20 PM, Michael Betancourt wrote:
> They're italics, as in emphasizing a word when it is first introduced. That falls into the common
> convention of many styles.

This is all just FYI -- if we were going to get super
picky about manual style and grammar we'd need a better
copy editor than me!

For instance, compare and contrast these:

We define "variance" to be the average squared distance from the mean.

Variance is the average squared distance from the mean.

The first should be quoted, because it's a mention of
the term. The second should not be quoted, because it's
a use of the word. The second usage is sometimes italicized
in technical books to highlight definitions.

Now we're ready for some philosophy. The sentence

"Red" means red.

not only makes sense, but is not a tautology. The first
instance is a mention, the second a use. Compare and contrast
with

"Rouge" means red.

- Bob

[Michael Betancourt]

It would be much better to have a proper tagged version of Stan
as this isn't just about reproducing the exact results but also having
the code ready for users who read the paper and want to implement
the techniques. We want people to read the paper on the arXiv and then
immediately improve their models, not have to play with some detached
branch that's non trivial to install (we already have enough problems
with conflicting Rstan installs). In addition, it's much simpler to quote the
paper instead of writing the same advice over and over again in the list!

The nominal deadline is the end if the month so there is some time
(I was careful to have a few weeks for the pull requests, but they have
unfortunately called to the wayside). But we really need to talk about
management again, which we should reserve for the next Stan meeting.

[Michael Betancourt]

We need to talk about this at the next meeting.

[Michael Betancourt]

Sure, which is how I'm using italics. Quotes were earlier used to
to denote a casual definition - something used for notational
convenience but shouldn't be taken too seriously. I'm fine with
defining a consistent Stan style but let's be careful about differentiating
a consistent style from a "correct" style. Damn straight I used quotes.

[Ben Goodrich]

One thing we should probably add to the release process is to reformat the code consistently. There is a clang tool for this, although we would need to write a set of rules to enforce Bob style (by default it only knows LLVM, Google, Chromium, Mozilla, and Webkit styles).

http://clang.llvm.org/docs/ClangFormat.html

With LLVM style, it is just

find src/ -type f -name \*\.\[ch]pp -print | xargs -n 1 -P 9 clang-format-3.4 --style=LLVM -i

which results in a diff that is 270948 lines long.

Ben

P.S. Also, src/test/mcmc/mock_hmc.hpp has a recently messed-up header guard. Somebody put that fix on top of an existing pull-request; it is not worth running the whole set of tests just for something like that.

[Daniel Lee]

Ben, can you create a pull request? If it's only a header guard, I'll go ahead and merge without the full set of tests.

[Bob Carpenter]

On 11/22/13, 9:37 AM, Ben Goodrich wrote:
> One thing we should probably add to the release process is to reformat the code consistently. There is a clang tool for
> this, although we would need to write a set of rules to enforce Bob style (by default it only knows LLVM, Google,
> Chromium, Mozilla, and Webkit styles).

I don't have a problem with a loose guide and not being
too picky about it. For me, it's just about keeping the
code readable.

From first principles, I'd say go with Kernighan, Ritchie,
and Stroustroup. I said that before looking it up. Turns
out they use the style I like for conditionals and for loops
(space before the open round parens, open curly on same line),
and the style Mike likes for functions (open curlies on their
own line).

If we automate, won't it mess up all the outstanding pull
requests? I'm curious how well the Clang tool works. I've
never seen one work very well, but they'll have the parser
sorted, which is the hardest part.

- Bob

[Ben Goodrich]

I fixed via the GitHub web interface

https://github.com/stan-dev/stan/commit/d5ffd40c498ae6e4de926ad438b6c2d4f59b355d

Ben

[Daniel Lee]

Thanks. I've got it from here.

[Daniel Lee]

Never mind. I'm ok with the change.

[Daniel Lee]

Looks like we need to clean up our header guards. We really don't need the "__BETA__" in there.

[Ben Goodrich]

On Friday, November 22, 2013 12:16:59 PM UTC-5, Bob Carpenter wrote:

On 11/22/13, 9:37 AM, Ben Goodrich wrote:
> One thing we should probably add to the release process is to reformat the code consistently. There is a clang tool for
> this, although we would need to write a set of rules to enforce Bob style (by default it only knows LLVM, Google,
> Chromium, Mozilla, and Webkit styles).

I don't have a problem with a loose guide and not being
too picky about it.  For me, it's just about keeping the
code readable.

If we do it, we should specify all the options we want. For me, I don't want to have to remember style rules when I am coding if there is a tool that can automate the style before (or after) I commit it.

If we automate, won't it mess up all the outstanding pull
requests?  

It would be a challenge to run it on develop right now because of the merge conflicts (however trivial) it would create. But you run the tool as the last thing you do on a release branch before final testing because nothing branches from that. Then master and the tarballs will have the correct formatting. As for develop, it is probably easier to run the tool before merging and then the code would look a little better bit by bit. Another opportunity would be to run it on develop as soon as we branch off a major feature release.
 

I'm curious how well the Clang tool works.  I've
never seen one work very well, but they'll have the parser
sorted, which is the hardest part.

 
Yes, that is why all llvm-based tools basically work well quickly. Here are all the flags you can set:

http://clang.llvm.org/docs/ClangFormatStyleOptions.html

Taking LLVM style as a base, we can edit and later commit the attachment.

Ben

[Bob Carpenter]

I'm going to go out the if-it-aint'-broke-don't-fix-it
limb on this one. I just don't think consistent formatting
is worth the pain it will impose.

I do occassionally change styles in things I'm committing,
but only if I'm already doing major changes. Otherwise, it's
just too annoying on the merge front.

- Bob