Re: [stan] test nan input for functions in src/stan/agrad/rev/functions/ (#845)

[Daniel Lee]

After opening up this can of worms, I'm not sure if the right thing to do is to enforce all of this inside the functions or expect the functions to be called with "good" values.

It makes sense, but might be too much of a performance hit. The cases I'm worried about are the few functions that take nan and output reasonable numbers like 1 or 0.

On Aug 12, 2014 4:44 PM, "Peter Li" <notifi...@github.com> wrote:

Ok and then for functions like fmax, fma, if_else, etc. when NaN is passed in, the gradients return 0 or 1. For instance,

    inline var fmax(const stan::agrad::var& a,
                    const stan::agrad::var& b) {
      return a.vi_->val_ > b.vi_->val_ ? a : b;
    }

is going to give gradient 1 for both NaN inputs so should we just throw in this case?

—
Reply to this email directly or view it on GitHub.

[Bob Carpenter]

Does it make sense to try to have

(1) the autodiff lib follow C++ functions in
throwing or not throwing?

(2) Stan follow C++ functions in throwing or not?

I tried to have both of these follow C++ as closely as
possible, though I'm no longer sure (2) is such a good idea.

I do think that whatever we decide for (2), we should be
consistent, which may mean wrapping C++ built-in and
standard library functions for double valued inputs, because
those don't throw as is.

- Bob

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

On Tue, Aug 12, 2014 at 11:39 PM, Bob Carpenter <ca...@alias-i.com> wrote:

Does it make sense to try to have

(1) the autodiff lib follow C++ functions in
    throwing or not throwing?

What about for boost functions like bessel_first_kind?

 

(2) Stan follow C++ functions in throwing or not?

I tried to have both of these follow C++ as closely as
possible, though I'm no longer sure (2) is such a good idea.

I do think that whatever we decide for (2), we should be
consistent, which may mean wrapping C++ built-in and
standard library functions for double valued inputs, because
those don't throw as is.

- Bob

On Aug 12, 2014, at 4:53 PM, Daniel Lee <bea...@alum.mit.edu> wrote:

> After opening up this can of worms, I'm not sure if the right thing to do is to enforce all of this inside the functions or expect the functions to be called with "good" values.
>
> It makes sense, but might be too much of a performance hit. The cases I'm worried about are the few functions that take nan and output reasonable numbers like 1 or 0.
>
> On Aug 12, 2014 4:44 PM, "Peter Li" <notifi...@github.com> wrote:
> Ok and then for functions like fmax, fma, if_else, etc. when NaN is passed in, the gradients return 0 or 1. For instance,
>
>     inline var fmax(const stan::agrad::var& a,
>                     const stan::agrad::var& b) {
>       return a.vi_->val_ > b.vi_->val_ ? a : b;
>     }
>
> is going to give gradient 1 for both NaN inputs so should we just throw in this case?
>

> --