more doc for new arguments?

[Jiqiang Guo]

I reviewed the whole section about the new command line in the manual under feature/arg_refactor branch.  Part of the arguments does not make sense to me.  I am writing the doc of these arguments for rstan.  I feel bad that I just say "please refer to the Stan manual" and I know they are not in the manual of Stan.  So I hope there would be more doc about them though some of which should be in the first version of the manual. 

Specifically, I still do not understand the arguments for adaptation, namely, gamma, delta, kappa, t0.  I think we should not assume that all users understand dual averaging.  At least an explanation and a reference in the doc would be nice. 

Second, the metric option for NUTS.  I do not think NUTS paper talks about geometry much (I might be wrong).  So I cannot make sense of phrases such as "Geometry of base manifold" and options unit_e, diag_e, dense_e.  Honestly, I know little about manifold and I do not understand the meaning of geometry here, which might be the reason for me.  So I need some help.

Last, I do not know what is "int_time" for HMC.  I read again some previous emails on stan-dev and still cannot understand it.  It is of type double, so I guess it is not leapfrog steps that I know is a parameter of HMC. 

By the way, I think this part of doc needs another proofread once we settle down on it. 

--

Jiqiang

[Bob Carpenter]

On 8/27/13 3:49 PM, Jiqiang Guo wrote:
> I reviewed the whole section about the new command line in the manual under feature/arg_refactor branch. Part of the
> arguments does not make sense to me.

We need to get this at least to the point where you
can understand it or there's no hope for our users.

> I am writing the doc of these arguments for rstan. I feel bad that I just say
> "please refer to the Stan manual" and I know they are not in the manual of Stan.

Bogus references like that are worse than nothing.

> So I hope there would be more doc
> about them though some of which should be in the first version of the manual.

Absolutely. It's on its way. I'm supposed to be writing some
of it.

> Specifically, I still do not understand the arguments for adaptation, namely, gamma, delta, kappa, t0. I think we
> should not assume that all users understand dual averaging.

Agreed.

> At least an explanation and a reference in the doc would be
> nice.

I think we need an informal explanation and then a reference.
We don't really want to explain all of dual averaging unless
it's easy. And then probably only after we explain what we're
doing for HMC and NUTS a bit moe thoroughly.

> Second, the metric option for NUTS. I do not think NUTS paper talks about geometry much (I might be wrong).

Only implicitly. You need to read Girolami and Calderhead's RMHMC paper,
or even better, Michael Betancourt's papers. By geometry, they just
mean the curvature of the posterior (typically measured to second order
through a Hessian).

> So I
> cannot make sense of phrases such as "Geometry of base manifold"

We're using plain old Euclidean geometry so far and the metric's
just Euclidean distance. RMHMC generalizes this so that Euclidean
geometry's just a special case where the metric (defining distances
between points) is Euclidean.

> and options unit_e, diag_e, dense_e.

These are the mass matrix shapes, either a unit matrix (usual algebraic
sense of unit for multiplication --- all ones on diagonal), a diagonal
matrix (what we used to call varying step sizes), and a full mass matrix.

Radford's intro to HMC in the MCMC Handbook does a good job explaining
the role of the mass matrix.

> Honestly, I know
> little about manifold and I do not understand the meaning of geometry here, which might be the reason for me. So I need
> some help.

We should definitely provide a simpler explanation that doesn't depend on
understanding differentiable manifolds and metrics.

>
> Last, I do not know what is "int_time" for HMC.

That's what we used to call step size. The reason for the new, more
explanatory terminology is that the step size is just the time
interval for the discretization of the Hamiltonian simulation. The
negative log probability is the potential energy, we provide a random
initial kinetic energy each iteration, and then we trace out the path
given the potential and kinetic energies given the mass matrix. The
int_time is the time interval for each step of the discrete simulation.

> I read again some previous emails on stan-dev and still cannot
> understand it. It is of type double, so I guess it is not leapfrog steps that I know is a parameter of HMC.

Right. Number of steps plus step time determines the overall time of
the simulation. NUTS figures out the number of steps automatically,
but it should still be settable.

> By the way, I think this part of doc needs another proofread once we settle down on it.

Absolutely --- it's not even a finished draft yet!

- Bob

[Jiqiang Guo]

Thanks a lot.  One question about int_time below. 

--

Jiqiang 

On Tue, Aug 27, 2013 at 4:20 PM, Bob Carpenter <ca...@alias-i.com> wrote:

Last, I do not know what is "int_time" for HMC.

That's what we used to call step size.  The reason for the new, more
explanatory terminology is that the step size is just the time
interval for the discretization of the Hamiltonian simulation.  The
negative log probability is the potential energy, we provide a random
initial kinetic energy each iteration, and then we trace out the path
given the potential and kinetic energies given the mass matrix.  The
int_time is the time interval for each step of the discrete simulation.

From the help (below), int_time is the total integration time and we have 

an argument called stepsize. 

              int_time=<double>

                Total integration time for Hamiltonian evolution

                Valid values: 0 < int_time

                Defaults to 2 * pi

So can I understand int_time = stepsize * (number of leapfrog steps)?  If yes, I think

the default values for int_time (2 * pi) and stepsize = 1 are not good for each other.

[Michael Betancourt]

These are optimal values for IID Gaussians, which is e best default I can think of.

--
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.

[Jiqiang Guo]

I rephrase my question.  What are the actual values of int_time and stepsize if I turn off adaptation for static HMC? They cannot be 2 *pi and 1 at the same time since int_time/stepsize is not an integer (assuming my understanding is correct). 

--

Jiqiang  

[Michael Betancourt]

It rounds to the nearest integer (by static casting from a double to an int).  In this case you would get 6 steps.

[Jiqiang Guo]

Running an example indicates something else; the stepsize is 0.0625.

$ ./dogs data=dogs.data.R sample algorithm=hmc engine=static adapt engaged=0

$ more samples.csv

# stan_version_major = 1

# stan_version_minor = 3

# stan_version_patch = 0

# model = dogs

# method = sample (Default)

#   sample

#     num_samples = 1000 (Default)

#     num_warmup = 1000 (Default)

#     save_warmup = 0 (Default)

#     thin = 1 (Default)

#     adapt

#       engaged = 0

....

#     algorithm = hmc (Default)

#       hmc

#         engine = static

#           static

#             int_time = 6.2831853071795898 (Default)

#         metric = diag_e (Default)

#         stepsize = 1 (Default)

....

# output

#   file = samples.csv (Default)

#   append_sample = 0 (Default)

#   diagnostic_file =  (Default)

#   append_diagnostic = 0 (Default)

#   refresh = 100 (Default)

lp__,accept_stat__,stepsize__,int_time__,alpha,beta,A,B

-4640.98,0,0.0625,6.28319,-0.67269,-4.93523,0.510334,0.00718883

-4640.98,0,0.0625,6.28319,-0.67269,-4.93523,0.510334,0.00718883

[Michael Betancourt]

That is not the correct behavior - I can look but I won't be able to push for a few days.

[Michael Betancourt]

I see - adaptation is indeed off but the step size gets initialized no matter what.  The fix is easy - just move the try blocks in the two sampler init functions to the init adapt function.

Should we wait to fix until after the arg_refactor merge?  I'll also add details on the dual averaging and HMC options into the doc.  Note that it'll be a few day (no wireless on my laptop and not an Ethernet port in sight).

[Daniel Lee]

Yes, wait until post-merge.

Does anyone object to the merge as-is? It passes tests. https://github.com/stan-dev/stan/pull/172

[Michael Betancourt]

Merge merge merge.  :-)

[Daniel Lee]

I have one vote for merge from Michael. (I'm counting the other two as rejections.)

I'm voting merge. I'll wait until Bob, Jiqiang, or Ben weigh in on this. One more merge vote will get it in.

[Ben Goodrich]

Abstain, although in general I don't see why it shouldn't be merged if whoever is working on a branch thinks it is ready and it passes the tests.

Ben

[Bob Carpenter]

I'm all for merging and working from there to make
everyone's life easier. But let's not ignore anyone's
objections by outvoting them! Having said that, let's also
not wait forever. How's that for wishy-washy, namby-pamby,
pass-the-buck, weasel-worded advice?

You might want to rebase it all first, as it looked
like there were a lot of broken intermediate commits.

- Bob

On 8/28/13 12:25 PM, Daniel Lee wrote:
> I have one vote for merge from Michael. (I'm counting the other two as rejections.)
>
> I'm voting merge. I'll wait until Bob, Jiqiang, or Ben weigh in on this. One more merge vote will get it in.
>
>
> On Wed, Aug 28, 2013 at 12:21 PM, Michael Betancourt <betan...@gmail.com <mailto:betan...@gmail.com>> wrote:
>
> Merge merge merge. :-)
>

> On Aug 28, 2013, at 6:19 PM, Daniel Lee <bea...@alum.mit.edu <mailto:bea...@alum.mit.edu>> wrote:
>
>> Yes, wait until post-merge.
>>
>> Does anyone object to the merge as-is? It passes tests. https://github.com/stan-dev/stan/pull/172
>>
>>
>>
>>
>> On Wed, Aug 28, 2013 at 12:03 PM, Michael Betancourt <betan...@gmail.com <mailto:betan...@gmail.com>> wrote:
>>
>> I see - adaptation is indeed off but the step size gets initialized no matter what. The fix is easy - just
>> move the try blocks in the two sampler init functions to the init adapt function.
>>
>> Should we wait to fix until after the arg_refactor merge? I'll also add details on the dual averaging and HMC
>> options into the doc. Note that it'll be a few day (no wireless on my laptop and not an Ethernet port in sight).
>>

>>>> On Wed, Aug 28, 2013 at 3:09 AM, Michael Betancourt <betan...@gmail.com <mailto:betan...@gmail.com>>

>>>>> stan-dev+u...@googlegroups.com <mailto:stan-dev+u...@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+u...@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+u...@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+u...@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>.

[Jiqiang Guo]

Positive.
--
Jiqiang

                stan-dev+unsubscribe@googlegroups.com <mailto:stan-dev+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com <mailto:stan-dev+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com <mailto:stan-dev+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com <mailto:stan-dev+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.

[Marcus Brubaker]

I'd say try to merge other small outstanding pull requests first and then merge it ASAP.

Cheers,

Marcus

[Daniel Lee]

I'm taking that as enough yeses. Did someone want to go through and rebase the commits? If not, I'll merge as-is.

[Bob Carpenter]

I would very much like to rebase this one, but don't know
how to do it myself. Ben --- could you help with this?

Or do you think it's better to leave in the buggy commits?

- Bob

On 8/28/13 4:23 PM, Daniel Lee wrote:
> I'm taking that as enough yeses. Did someone want to go through and rebase the commits? If not, I'll merge as-is.
>
>
>
> On Wed, Aug 28, 2013 at 2:49 PM, Marcus Brubaker <marcus.a...@gmail.com <mailto:marcus.a...@gmail.com>> wrote:
>
> I'd say try to merge other small outstanding pull requests first and then merge it ASAP.
>
> Cheers,
> Marcus
>
>
> On Wed, Aug 28, 2013 at 1:08 PM, Ben Goodrich <goodri...@gmail.com <mailto:goodri...@gmail.com>> wrote:
>
> Abstain, although in general I don't see why it shouldn't be merged if whoever is working on a branch thinks it
> is ready and it passes the tests.
>
> Ben
>
>
> On Wednesday, August 28, 2013 12:25:10 PM UTC-4, Daniel Lee wrote:
>
> I have one vote for merge from Michael. (I'm counting the other two as rejections.)
>
> I'm voting merge. I'll wait until Bob, Jiqiang, or Ben weigh in on this. One more merge vote will get it in.
>
>
> On Wed, Aug 28, 2013 at 12:21 PM, Michael Betancourt <betan...@gmail.com> wrote:
>
> Merge merge merge. :-)
>
> On Aug 28, 2013, at 6:19 PM, Daniel Lee <bea...@alum.mit.edu> wrote:
>
>> Yes, wait until post-merge.
>>

>> Does anyone object to the merge as-is? It passes tests. https://github.com/stan-dev/__stan/pull/172

>>> lp__,accept_stat__,stepsize__,__int_time__,alpha,beta,A,B
>>> -4640.98,0,0.0625,6.28319,-0.__67269,-4.93523,0.510334,0.__00718883
>>> -4640.98,0,0.0625,6.28319,-0.__67269,-4.93523,0.510334,0.__00718883

>>>>> stan-dev+u...@__googlegroups.com.
>>>>>
>>>>> For more options, visit https://groups.google.com/__groups/opt_out
>>>>> <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.
>>>>
>>>> For more options, visit https://groups.google.com/__groups/opt_out
>>>> <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.
>>>>
>>>> For more options, visit https://groups.google.com/__groups/opt_out
>>>> <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.
>>>
>>> For more options, visit https://groups.google.com/__groups/opt_out
>>> <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.
>>>
>>> For more options, visit https://groups.google.com/__groups/opt_out
>>> <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.
>>
>> For more options, visit https://groups.google.com/__groups/opt_out
>> <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.
>>
>> For more options, visit https://groups.google.com/__groups/opt_out
>> <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.
>
> For more options, visit https://groups.google.com/__groups/opt_out
> <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]

Is it possible to merge in a branch with buggy commits
and then only do bisect on the merge points? If so,
I don't think we need to worry about rebasing.

- Bob

On 8/28/13 4:23 PM, Daniel Lee wrote:

> I'm taking that as enough yeses. Did someone want to go through and rebase the commits? If not, I'll merge as-is.
>
>
>
> On Wed, Aug 28, 2013 at 2:49 PM, Marcus Brubaker <marcus.a...@gmail.com <mailto:marcus.a...@gmail.com>> wrote:
>
> I'd say try to merge other small outstanding pull requests first and then merge it ASAP.
>
> Cheers,
> Marcus
>
>
> On Wed, Aug 28, 2013 at 1:08 PM, Ben Goodrich <goodri...@gmail.com <mailto:goodri...@gmail.com>> wrote:
>
> Abstain, although in general I don't see why it shouldn't be merged if whoever is working on a branch thinks it
> is ready and it passes the tests.
>
> Ben
>
>
> On Wednesday, August 28, 2013 12:25:10 PM UTC-4, Daniel Lee wrote:
>
> I have one vote for merge from Michael. (I'm counting the other two as rejections.)
>
> I'm voting merge. I'll wait until Bob, Jiqiang, or Ben weigh in on this. One more merge vote will get it in.
>
>
> On Wed, Aug 28, 2013 at 12:21 PM, Michael Betancourt <betan...@gmail.com> wrote:
>
> Merge merge merge. :-)
>
> On Aug 28, 2013, at 6:19 PM, Daniel Lee <bea...@alum.mit.edu> wrote:
>
>> Yes, wait until post-merge.
>>

>> Does anyone object to the merge as-is? It passes tests. https://github.com/stan-dev/__stan/pull/172

>>> lp__,accept_stat__,stepsize__,__int_time__,alpha,beta,A,B
>>> -4640.98,0,0.0625,6.28319,-0.__67269,-4.93523,0.510334,0.__00718883
>>> -4640.98,0,0.0625,6.28319,-0.__67269,-4.93523,0.510334,0.__00718883

>>>>> stan-dev+u...@__googlegroups.com.
>>>>>
>>>>> For more options, visit https://groups.google.com/__groups/opt_out
>>>>> <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.
>>>>
>>>> For more options, visit https://groups.google.com/__groups/opt_out
>>>> <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.
>>>>
>>>> For more options, visit https://groups.google.com/__groups/opt_out
>>>> <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.
>>>
>>> For more options, visit https://groups.google.com/__groups/opt_out
>>> <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.
>>>
>>> For more options, visit https://groups.google.com/__groups/opt_out
>>> <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.
>>
>> For more options, visit https://groups.google.com/__groups/opt_out
>> <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.
>>
>> For more options, visit https://groups.google.com/__groups/opt_out
>> <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.
>
> For more options, visit https://groups.google.com/__groups/opt_out
> <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>.

[Daniel Lee]

I spent a little bit of time searching for whether we could do that. Unfortunately, it doesn't look like that's how git bisect works by default.

Fortunately, the number of merges due to pull requests is actually low and with the number we have now, I can just walk through and find them and run whatever test on just the merges. And reverting a pull request is easy.

That said, I don't think we should worry about rebasing/squashing the commit history. Although it would be nice if every commit was tested and in a good state, I think our pull request merges into develop are where we can assume and enforce that behavior.

Daniel

        stan-dev+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.

[Ben Goodrich]

On Wednesday, August 28, 2013 5:27:43 PM UTC-4, Bob Carpenter wrote:

I would very much like to rebase this one, but don't know
how to do it myself.  Ben --- could you help with this?

Or do you think it's better to leave in the buggy commits?

- Bob

It's bad, but there is not a whole lot I can do about it. When

1. There are a lot of new commits
2. The rebaser is not familiar with the commits
3. The develop branch has been pulled into the feature branch

then it is pretty much impossible to rebase explicitly.

What can be done is to create a patch of feature/arg_refactor against develop (at the time it was branched) and save that somewhere. Then make a new branch, git apply the patch, and commit hunks of it (perhaps using the --interactive option to git-add or git-gui). Then we merge the newest branch only.

Ben