Exposing (non-normalized) Incomplete Beta Function

[Peter Li]

In order to get all the distributions up and running with the generalized operands and partials, I think we need to expose the non-normalized incomplete beta function. It doesn't seem like it'll be too bad since Michael already has the gradients done for the first two arguments. So is it ok to expose it and for the derivatives just call the stuff in internal_math.hpp?

[Michael Betancourt]

The only issue is that the derivatives aren’t tested nor are they particularly robust or fast.

On Jun 18, 2014, at 4:19 PM, Peter Li <li.pe...@gmail.com> wrote:

In order to get all the distributions up and running with the generalized operands and partials, I think we need to expose the non-normalized incomplete beta function. It doesn't seem like it'll be too bad since Michael already has the gradients done for the first two arguments. So is it ok to expose it and for the derivatives just call the stuff in internal_math.hpp?

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

[Peter Li]

I can test the derivatives against finite-diff values and then I can just not add the function signaturesr so people can't call them but we can still use them for the prob functions.

[Michael Betancourt]

They’ll still be exposed indirectly — I’m fine with it but we have to be aware that they

can be horrendously unstable.  I’d suggest a warning, but users have not been receptive

to those...

[Peter Li]

I'll keep the set-up similar to what you did before (replacing internal_math.hpp with a folder internal_math that will contain all the double/fvar/var versions).

[Bob Carpenter]

What's unstable? Is it some kind of range thing where
we can just fail if they're outside that range?

Or is the usual numerical instability of auto-diffing
an iterative algorithm? And if so, do you know how to do it
better? Presumably you (Michael) have some solution up your sleeve
for the new autodiff at higher orders.

- Bob

[Michael Betancourt]

> What's unstable? Is it some kind of range thing where
> we can just fail if they're outside that range?
> Or is the usual numerical instability of auto-diffing
> an iterative algorithm?

Both. The functions themselves are poorly implemented power
series and derivatives would be even worse (wether the series
were diff’d by hand or the autodiff was used explicity).

> And if so, do you know how to do it
> better? Presumably you (Michael) have some solution up your sleeve
> for the new autodiff at higher orders.

Don’t allow CDFs for higher-order methods? The new autodiff
has exections for functions without higher-order partials implemented
for exactly this purpose.

The real problem is that stable numerical implementations of these
nasty functions is way beyond our expertise. If I had a few months
I might be able to find the old references, learn all the tricks, and
then implement them for everything. But I don’t.

[Bob Carpenter]

I'm OK with not allowing higher-order autodiffs.

We can throw exceptions, which will get the user the point
eventually.

It'd also be helpful if we listed functions with higher-order
autodiff in the manual. Even better if we could warn users
at compile time. I'd like it even better if we could throw
errors at compile time, but it's not clear we're going to know
what they're going to call when they compile.

- Bob