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