Ven Popov

Oh, it works great! Actually, we can get rid of everything special and make Math.dist_default and Math.dist_transformed completely the same. Same for Ops.dist_transformed and Ops.dist_default. You end up with a...

Ok, this is pretty much done now :) In fact, the best solution proved to be the simplest - just got rid of Math.dist_transformed() and Ops.dist_transformed(), and now everything uses...

Storing the functions in a list is the alternative I also thought about, but initially discarded because I didn't know how to deal with the possibility that one derivative might...

The risk with storing the functions in a list is that it could be a breaking change if any package depends on the current behavior. So a safer solution might...

Neat! Looks like it could work . I tried to make something like that with a similar add_transform function that returns composed functions in math.dist_default but had trouble with the...

I implemented that approach. However, I noticed that if we put `add_transform()` in the Math/Op methods, then if people use nested `dist_transform(dist_transform(...))`, as @mjskay had an example above, they would...

So in effect, now you get what you suggested: ``` r library(distributional) library(vctrs) d [1] t(U(0, 1)) str(d2) #> dist [1:1] #> $ :List of 4 #> ..$ dist :List...

> Looks great! Thanks for the mammoth effort in creating this PR and discussing the design. One minor fix and a question, then it's good to go! Great, thanks for...

A busy semester kicked in and I forgot about this... I'm leaving for a series of conferences and I'm not sure when I could do a final pass. So I...

Following up on the discussion started in #102 > Currently these are calculated with taylor series approximations, which are faster than the numerical integration and I think work fine in...