The new parameterized distributions will promote the inputs to the same
type (see here
<https://github.com/JuliaStats/Distributions.jl/blob/master/src/univariate/continuous/normal.jl#L33>).
Some of the multivariate parameterizations in this
<https://github.com/JuliaStats/Distributions.jl/pull/478> PR have multiple
type variables.
So are you saying the new parameterized distributions will work for you?
Again, your new type would need to be a subtype of Real for this. If that's
the case, everything should work once the new changes are in place.
On Tuesday, April 12, 2016 at 10:34:05 AM UTC-4, Jameson Quinn wrote:
>
> Yes, parameterizing Normal (and other distributions) would solve my
> problem perfectly. The question then is: would it be necessary to
> separately parameterize each parameter, or is it better to just force
> people to use either exclusively floats or exclusively AD numbers?
>
> On Tuesday, 12 April 2016 08:29:25 UTC-4, John Pearson wrote:
>>
>> Yes, this will work, I think. What you're doing is adding an outer
>> constructor to Normal that in fact constructs something else.
>>
>> The only problem you might run into is that other functions that expect a
>> Normal may not accept your custom type.
>>
>> More info:
>>
>> For Distributions.jl, the strategy has been to generalize Normal to have
>> a type parameter:
>>
>> Normal{T <: Real} (see more here
>> <https://github.com/JuliaStats/Distributions.jl/pull/475>). I'm partway
>> through implementing this for the whole library, after which forward-mode
>> automatic differentiation will work out of the box, since AD numbers are
>> subtypes of Real. This is not quite mathematically correct (there's a long
>> discussion on GitHub), but in this case, practicality beats purity.
>>
>> There's another potential strategy for this, which is creating a new
>> subtype of an AbstractNormal, but right now, Normal <:
>> ContinuousUnivariateDistribution.
>>
>> It might be nice to have Normal <: AbstractNormal <:
>> ContinuousUnivariateDistribution so that alternative Normal types might be
>> possible (I advocated strongly
>> <https://github.com/JuliaStats/Distributions.jl/pull/430> for this and
>> even implemented a prototype
>> <https://github.com/jmxpearson/DiffableDistributions.jl>), but it turned
>> out to be trickier for some corner cases than I realized (basically because
>> AbstractMvNormal already exists), so the first strategy turned out to be
>> cleaner and is what's being implemented.
>>
>> On Tuesday, April 12, 2016 at 6:37:24 AM UTC-4, Jameson Quinn wrote:
>>>
>>> Hmm... I guess that this may be a non-issue. I tried the following:
>>>
>>> type Foo
>>> a::Float64
>>> end
>>>
>>> function Foo(a::Int64)
>>> a
>>> end
>>>
>>> Foo(1.0) #Foo(1.0)
>>> Foo(1) #1
>>>
>>> ...and it seems there's no syntactic issues with having a function named
>>> the same as a type which returns values of a different type. So I could
>>> just create a new function Normal(DualNumber,DualNumber) which returns a
>>> DifferentiableNormal object, and everything would work.
>>>
>>> So this question reduces to: is that a stylistic no-no?
>>>
>>
