Re: [julia-users] Re: Confused about parametrization type
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.
Re: [julia-users] Re: Confused about parametrization type
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-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. > >
Re: [julia-users] Re: Confused about parametrization type
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