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.
>>
>
