David Widmann

> Btw, looking quickly at Wikipedia, it looks like the correct symbol for convolution is '∗' (\\ast)\n(I can definitely see how annoylingly similar to '*' it is though) That's what...

Is this a Distributions or a CUDA issue? What exactly is the problem? The `Normal` constructor is not special at all, basically just the standard constructor with a check of...

Yeah, usually (e.g. in constructors without sigma or `convert`) we use `Normal(mu, sigma; check_args=false)`. However, on this specific case I think we should just call https://github.com/JuliaStats/StatsFuns.jl/blob/master/src/distrs/norm.jl, I've never understood why...

I opened https://github.com/JuliaStats/Distributions.jl/pull/1487.

Thanks for the ping! I postponed the PR because I wanted to think about it carefully once more. I came to the conclusion that - in my opinion it is...

It's known, the type only depends on the data. If you use `Float32[1, 2, 3]` the type should be `Normal{Float32}`.

Of course, the question is still if this should be changed. I think it would be reasonable.

Well, it seems there are some hardcoded Float64 arguments, e.g. in https://github.com/JuliaStats/Distributions.jl/blob/master/src/univariate/continuous/normal.jl#L238. It would be easy to change these type restrictions at least in a first step.

I would support a PR, I think, since in my opinion it is a bit strange to return a partly redundant set of parameters. And if one is actually interested...

> It also seems to me that something like this is required in order to write code generic over exponential family distributions. At least that was how I ran into...