In the trigamma thread @wds15 said (added parentheticals in square brackets for clarity):
Unless you say that boost is terrible, we should just switch [to boost]. Boost math folks actively maintain this function. So it’s better to let them maintain and test it. If it’s bad then we should file an issue to them. The future maintenance burden is with them which is great for us. That’s why I would switch without thinking at this point (one more look at performance would be good).
I agree with him about this in general (we use boost so heavily there’s no reason for us to duplicate their functionality, especially since they take performance and accuracy seriously). In practice I think this means:
When boost functions are close in terms of error and performance we should just rely on their functions
When we want to deviate but the issue could be addressed via pull request we should check if they’re willing to make modifications
For already-implemented functions like the trigamma I think we should demonstrate to ourselves (so some sort of minor doc, maybe in the Wiki) that we’re making the change for a reason (similar performance and less code is a fine reason!)
For derivatives this isn’t going to be all that helpful since we’re not about to change to their autodiff and they don’t have many of the derivatives we need. We can always back out of relying on boost::math if they go in a different direction for some reason.
That does change my perspective on the stan math library a little. The core math stuff that we often rely on boost::math for is fun but it’s not really a good niche to compete in (not much reason why) but in auto-diff and the functions needed to support that we could do very well and differentiate at the same time.
@syclik is that similar to how you’re currently thinking about the relationship between boost and stan math libs? I’d tag more of the math lib devs but I’ve missed the recent meetings so I’m not sure who to include.