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?
>>
>
