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