maths::beta_log now maths::lbeta; prob::beta_ls_log removed (for now)

[Bob Carpenter]

I just pushed through the lbeta name change.

Which led me to the new beta_ls parameterization.
It needs a fair bit of work. So I just removed
it (and commented out tests). If we need to bring
it back, it was last seen in:

revision 561

I feel bad for yanking it, but I'd rather wait until
a stable version 1 to put more work on Daniel's and
my plate for error checking code, testing, etc.
But feel free, Ben, to go back in and add all of this
stuff yourself if you really want beta_ls that
badly.

Here's an outline of fixes needed.

The original version was:

template <bool propto = false,
typename T_y, typename T_mu, typename T_theta,
class Policy = policy<> >
inline typename promote_args<T_y,T_mu,T_theta>::type
beta_ls_log(const T_y& y, const T_mu& mu, const T_theta& theta,
const Policy& = Policy()) {
T_mu alpha = mu * theta;
T_mu beta = (1.0 - mu) * theta;
return beta_log(y, alpha, beta, Policy());
}

1. It needs error checks actually on the
mu and theta params. We want to guarantee
mu is between 0 and 1 and that theta is positive
and do it with feedback as to which distribution was
called. If the products aren't right, we'll currently
get errors reported as originating in beta_log,
not beta_ls_log, which will confuse the users.

2. I named types for the kinds of variables, not
the actual variable (other than for outcome y),
so it's (T_loc mu, T_scale sigma), not (T_mu mu, T_sigma sigma).
I suppose it could be T_mean instead of T_loc -- it seems
odd to call mu a location here.

The extra naming gives people some hint as to what the
parameter is. (This made me realize that the variables
for the standard beta parameterization should be T_scale_success
and T_scale_failure rather than T_alpha and T_beta.)

3. The types declared for locals alpha and beta need
promotions as they involve T_mu and T_theta:

typename promote_args<T_mu,T_theta>::type
alpha = mu * theta;
typename promote_args<T_mu,T_theta>::type
beta = (1.0 - mu) * theta;

So that must mean there aren't unit tests for the
appropriate types in place.

An easier alternative would be to just drop them
into the beta_log call directly -- then the types all
get auto-computed from the operations.

- Bob

[Ben Goodrich]

On Jan 20, 2:49 pm, Bob Carpenter <c...@alias-i.com> wrote:
> An easier alternative would be to just drop them
> into the beta_log call directly -- then the types all
> get auto-computed from the operations.

That is what I did in the beta_binomial_ls (which I haven't pushed
yet). Wawro doesn't actually need beta_ls, only beta_binomial_ls, and
even then I can just map mu and phi to alpha and beta in the .stan
file instead of the .hpp file if you don't want to mess with it right
now.

But, it seems that even the plain beta_binomial is not parsing
correctly at the moment, e.g. you get

no matches for function name="beta_binomial_log"
arg 0 type=int[0]
arg 1 type=int[0]
arg 2 type=int[0]
arg 3 type=double[0]
arg 4 type=double[0]
EXCEPTION. PARSE
ERROR.

even though beta_binomial_log has an entry in the parser file.

Ben

[Bob Carpenter]

I'd rather wait unless you want to dot all the
i-s and cross all the t-s. It's not that any of
this is hard, it's just that I don't want our
to-do list to grow faster than we can check things
off it. There's also doc, but I'll deal with that
if you want to include them.

Beta-binomial only takes four arguments:

double beta_binomial_log(int n,int N,double alpha,double beta);

and indeed, if I do something like:

x <- beta_binomial_log(2, 7, 1.0, 1.0);

it compiles OK (at least on my machine). If you convert
the 1.0 to 1, it also works, because the type inference
allows integer-to-double promotions.

- Bob