Neural network gradient HMC

[ben18785]

See this.

[MichaelClerx]

Another thing we might need to think about at some point, is how fine grained we want to make PINTS. Having one of each "class" of methods is probably more important than having several. I'm guilty of this myself as well with CMA/X/S-nes. Ideally we would only have the "best" of each class of method so the users wouldn't have to do any work to decide between the sub-types?

[ben18785]

Yep this is something that has occurred to me. I am inclined to think that PINTS is for trialling as many methods as we can stomach. I do, however, think that as we get more feedback from users about which methods worked for them, that we might consider taking some of these methods and plonking them in a high performance “QuickPINTS” library: potentially in C++ but with Python wrappers. This latter library would be much much smaller and only contain the most useful methods across the classes of algos. The reason for this is that, for those wanting to use PINTS for models that are less expensive, it may be more enticing for them. Additionally, as the sampling methods become more involved, this typically means there’s more Python code (NUTS and Multinest are good examples of this) which means efficiency gets worse. Thoughts all?

…

On 1 Mar 2020, at 19:37, Michael Clerx ***@***.***> wrote: Another thing we might need to think about at some point, is how fine grained we want to make PINTS. Having one of each "class" of methods is probably more important than having several. I'm guilty of this myself as well. Ideally we would only have the "best" of each class of method so the users wouldn't have to do any work to decide between the sub-types? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.