Extensive discussion here:
http://docs.julialang.org/en/release-0.3/manual/faq/#how-do-abstract-or-ambiguous-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.
