Two simple "rules":
- "Always" use concrete types for fields in types. When in doubt, use
`isleaftype` to check.
- You "never" need to specify types in functions unless you want to control
dispatch to different methods
Like most rules, there are circumstances where you can afford to/want to break
them. But these are a pretty good starting point.
A final trick:
type MyType{AT<:AbstractMatrix}
mymatrix::AT
end
lets you use an AbstractMatrix in a type, concretely. See the FAQ for more
detail, including any questions you're about to ask :) about specifying the
element type in that matrix.
--Tim
On Tuesday, October 21, 2014 11:33:05 PM David van Leeuwen wrote:
> Hi,
>
> Thanks for the explanation. While writing the type abstract below I
> realized that I should have specified μ being Matrix{T} instead of
> Array{T}---but I hadn't suspected this was the culprit. I still find it a
> difficult balance between over-specifying types in functions and type
> definitions and code generality.
>
> Similarly, I am not sure if I win any performance pixy points by specifying
> Matrix{T} in types and functions rather than AbstractMatrix{T}---which is
> something I see a lot in other code.
>
> Cheers,
>
> ---david
>
> On Wednesday, October 22, 2014 6:10:40 AM UTC+2, Simon Kornblith wrote:
> > On Tuesday, October 21, 2014 6:41:24 PM UTC-4, David van Leeuwen wrote:
> >> I replaced the `γ = broadcast()` with the lines below that. No globals,
> >> but perhaps the field type gmm.μ is spoiling things. I am not sure if
> >> this
> >> is a case of an abstractly typed field
> >>
> >> type GMM{T<:FloatingPoint}
> >> ...
> >>
> >> μ::Array{T}
> >>
> >> ...
> >> end
> >>
> >> Should I have written GMM{T2} in the declaration of stats()?
> >
> > The declaration of stats() is fine, but μ is abstract because it's missing
> > the number of dimensions. It should be Array{T,2} or something like that,
> > or else GMM should be parametrized on the number of dimensions.
> >
> > Simon
