Just thought I'd throw this out there: Instead of having generate_s, generate_sor, etc., we could switch to just a single function, gen perhaps, that takes in a symbol argument that is :s, or :sor etc and then returns the appropriate tuple.
and that would be just as easy for the compiler to inline as generate_sor.
Or I suppose we could have both of these coexist.
I guess I personally like keeping the functions separate because that requires the least understanding of julia, is simpler to support than having them coexist, and doesn't seem to have any advantages other than style.
Anybody have any strong feelings about this? @juliohm it seemed like you liked this a lot in #10
Hi Zach, this sounds like a cool idea, one empty generic function in the specification taking care of all the variants generate_s, generate_sor, etc. :+1:
Just thought I'd throw this out there: Instead of having
generate_s
,generate_sor
, etc., we could switch to just a single function,gen
perhaps, that takes in a symbol argument that is:s
, or:sor
etc and then returns the appropriate tuple.gen(sor::Symbol, p::MyPOMDP, s::MyState, a::MyAction, rng::AbstractRNG)
At first I was worried about the compiler having trouble inlining this, but then I realized one could write
gen(sor::Val{:sor}, p::MyPOMDP, s::MyState, a::MyAction, rng::AbstractRNG)
and that would be just as easy for the compiler to inline as
generate_sor
.Or I suppose we could have both of these coexist.
I guess I personally like keeping the functions separate because that requires the least understanding of julia, is simpler to support than having them coexist, and doesn't seem to have any advantages other than style.
Anybody have any strong feelings about this? @juliohm it seemed like you liked this a lot in #10