It depends a little bit on what you mean by "better":
- Using the first one will cause specialized functions to be compiled for each
version
- Using the second one will use generic fallback code every time you access b
Consequently, the first should give faster performance at runtime, but have a
larger compile-time overhead. In most cases, most users seem to want to
maximize runtime performance.
--Tim
On Friday, March 06, 2015 07:14:26 AM Benjamin Deonovic wrote:
> That was the perfect resource, thank you Tim Holy!
>
> Here's a question about a specific situation:
>
> Suppose I have a type that has two String variables, but at construction,
> these might not be the same type of Strings (e.g. one might be ASCIIString,
> the other SubString{ASCIIString}). Which parametrization is better:
>
> type Foo{T <: String, U <: String}
> a::T
> b::U
> end
>
> or
>
> type Foo{T <: String}
> a::T
> b::String
> end
>
> On Thursday, March 5, 2015 at 2:59:40 PM UTC-6, Tim Holy wrote:
> > Extensive discussion here:
> >
> > http://docs.julialang.org/en/release-0.3/manual/faq/#how-do-abstract-or-am
> > biguous-fields-in-types-interact-with-the-compiler
> >
> > --Tim
> >
> > On Thursday, March 05, 2015 12:50:59 PM Benjamin Deonovic wrote:
> > > This has been very helpful
> > >
> > > @Ivar Nesje
> > >
> > > Can you explain the difference between your two examples of type A? I
> >
> > think
> >
> > > that is where most of my confusion comes from.
> > >
> > > On Thursday, March 5, 2015 at 12:24:12 PM UTC-6, Ivar Nesje wrote:
> > > > 1. Make sure that your code is correct for the inputs you allow.
> >
> > There
> >
> > > > is no need to accept BigFloat (nor Float16) if you end up
> >
> > converting to
> >
> > > > Float64 for the calculation anyway (the user of your code can do
> >
> > that
> >
> > > > himself). If you don't care enough about different precisions to
> >
> > even
> >
> > > > think
> > > > about how it will affect your program, I think it is better to add
> >
> > a
> >
> > > > TODO
> > > > comment in the code/documentation, so that others that care might
> > > > submit
> > > > the required changes in a PR.
> > > > 2. Testing your algorithm with random Float16 and BigInt will
> > > > sometimes raise new issues that affects Float64, but is much harder
> >
> > to
> >
> > > > find
> > > > there. There is definitely value in thinking about how different
> >
> > makes
> >
> > > > a
> > > > difference (or why it doesn't).
> > > >
> > > > Usually you shouldn't use abstract types in a type definition, but
> >
> > rather
> >
> > > > make a parametric type. This is for performance, because the current
> >
> > Julia
> >
> > > > runtime is very slow if it can't statically infer the types of the
> >
> > members
> >
> > > > of a type. See that
> > > >
> > > > type A{T<:FloatingPoint}
> > > >
> > > > member::T
> > > >
> > > > end
> > > >
> > > > is usually much better than
> > > >
> > > > type A
> > > >
> > > > member::FloatingPoint
> > > >
> > > > end
> > > >
> > > > Regards
> > > > Ivar
> > > >
> > > > torsdag 5. mars 2015 18.27.38 UTC+1 skrev Simon Danisch følgende:
> > > >> I think it's a good idea to have things parametric and type stable.
> >
> > So
> >
> > > >> I'd vote for T <: FloatingPoint.
> > > >> Like this, the type you call a function with can be propagated down
> >
> > to
> >
> > > >> all other functions and no conversions are needed.
> > > >> As you said, this gets difficult as some people have Float64 hard
> >
> > coded
> >
> > > >> all over the place. It's understandable as John pointed out.
> > > >> But for someone like me who works with GPU's which depending on the
> > > >> graphics card perform up to 30 times faster with Float32, this is
> >
> > quite
> >
> > > >> annoying as I always need to convert©.
> > > >>
> > > >> Am Donnerstag, 5. März 2015 17:55:40 UTC+1 schrieb Benjamin Deonovic:
> > > >>> Moving a post from julia issues to here since it is more
> >
> > appropriate:
> > > >>> https://github.com/JuliaLang/julia/issues/10408
> > > >>>
> > > >>> If I am making a function or composite type that involves floating
> >
> > point
> >
> > > >>> numbers, should I enforce those numbers to be Float64 or
> >
> > FloatingPoint?
> >
> > > >>> I thought it should be FloatingPoint so that the function/type will
> > > >>> work with any kind of floating point number. However, several julia
> > > >>> packages enforce Float64 (e.g. Distributions package Multinomial
> > > >>> distribution) and so I run into problems and have to put in a lot of
> > > >>> converts in my code to Float64. Am I doing this wrong? I'm quite new
> >
> > to
> >
> > > >>> julia
> > > >>>
> > > >>>
> > > >>> I don't have any intention to use non Float64 floatingpoints
> >
> > numbers,
> >
> > > >>> I'm just trying to write good code. I saw a lot of examples where
> > > >>> people recommended to to use Integer rather than Int64 or String
> >
> > rather
> >
> > > >>> than ASCIIString, etc. I'm just trying to be consistent. I'm fine
> >
> > just
> >
> > > >>> using Float64 if that is the appropriate approach here.
