What might be missing is to note the important difference between abstract and concrete types. Otherwise it might indeed be interpreted as advice to use curly-brackets in your type definitions.
Best, --Tim On Tuesday, July 12, 2016 12:36:28 PM CDT Yichao Yu wrote: > On Tue, Jul 12, 2016 at 12:23 PM, Fred <[email protected]> wrote: > > I tried that "change" because of this part of the documentation (in > > http://docs.julialang.org/en/release-0.4/manual/performance-tips/) : > > > > For example: > > > > julia> type MyType{T<:AbstractFloat} > > > > a::T > > > > end > > > > This is a better choice than > > > > julia> type MyStillAmbiguousType > > > > a::AbstractFloat > > > > end > > Please read the text around this example. In particular > > > This allows a to be of any type. This can often be useful, but it does > > have a downside: for objects of type MyAmbiguousType, the compiler will > > not be able to generate high-performance code. > > because the first version specifies the type of a from the type of the wrapper object. For example: > It's the type used for the field that is important. Whether the type > itself is parametrized or not has nothing to do with it. Type > parameter only helps to make the type more generic (in case you want > to use the type for other field types too) > > Do note that, > 1. your `d` is `Dict{Any,Any}` so accessing the value will be type unstable. > 2. As Jeffrey mentioned, you can make the type immutable if you don't need > to mutate it. > 3. `typeof(1)` is `Int` and not necessarily `Int64`. It is `Int32` on 32bit. > > Le mardi 12 juillet 2016 17:32:09 UTC+2, Yichao Yu a écrit : > >> On Tue, Jul 12, 2016 at 11:10 AM, Fred <[email protected]> wrote: > >> > I am referring to all 3, ie the type of Ions_frag :) > >> > >> Well, can you quote the performance tip? There's nothing wrong with > >> the type you are using in terms of performance so I'd like to know > >> which part of the doc is misleading.
