Here's my perspective:
* You should almost never define any type that has fields that aren't
concrete types. You can achieve this in two ways: by hard-coding concrete
types or by using parametric types.
* You should generally avoid allocating new arrays. This means that, if
your type ultimately needs to have an Array{Float64} stored in a field,
then it shouldn't even accept other kinds of arrays since those would need
to be converted with an allocation along the way.
* You should try to make code general, but you should also it correct
first. This often encourages specializing on Float64 during a first pass
since that's close to the lingua franca type for numeric computing.
-- John
On Thursday, March 5, 2015 at 8:55:40 AM UTC-8, Benjamin Deonovic wrote:
>
> 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.
>
