Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Way to get the weights and nodes for an expectation operator? #4

Closed
jlperla opened this issue Jul 10, 2018 · 4 comments
Closed

Way to get the weights and nodes for an expectation operator? #4

jlperla opened this issue Jul 10, 2018 · 4 comments
Assignees

Comments

@jlperla
Copy link
Member

jlperla commented Jul 10, 2018

It is very convenient to do the following

E = expectation(Normal(0.0, 1.0))
E(x-> x^2)

However, sometimes you would prefer to instead directly get the nodes and weights for the expectation operator (which is then a linear operator).

Because of this, instead of expectation(...) returning a function, perhaps it should return an operator "type" which is callable (and hence can act as a function) but has other methods. In particular,

E = expectation(Normal(0.0, 1.0))
E(x-> x^2)
nodes(E) #returns a vector of the underlying nodes associated with the operator
weights(E) #returns the weights.
@arnavs
Copy link
Member

arnavs commented Jul 10, 2018

Makes sense. Is there any distinction (in CS-land) between an operator and a function f(x::Function)::Function?

@jlperla
Copy link
Member Author

jlperla commented Jul 10, 2018

Well, I meant to use operator in the mathematical sense, but this is how you make an object callable https://docs.julialang.org/en/v0.6.0/manual/methods/#Function-like-objects-1
Where the argument would be a function.

The only thing to keep in mind with the design of the types is that nodes and weights do not apply to all quadrature algorithms. For example, with adaptive quadrature it doesn't make any sense, so we would need to have the type returned from the expectation have different super-types depending on the algorithm. But we can design those parts of the interface later.

@arnavs
Copy link
Member

arnavs commented Jul 10, 2018

Gotcha. Thanks for the link; could easily see myself struggling with that. And makes sense re different algos.

@arnavs
Copy link
Member

arnavs commented Jul 17, 2018

This issue is now implemented; e.g.

# Callable behavior for the object. Parameters because we cannot add methods to an abstract type. 
function (e::IterableExpectation{NT, WT})(f::Function; kwargs...) where {NT, WT}
    applicable(f, rand([e.nodes...])) || throw(MethodError("The function doesn't accept elements from the distribution's support."))
    return dot(f.(e.nodes), e.weights; kwargs...) 
end 

@arnavs arnavs closed this as completed Jul 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants