[julia-users] Re: Confused about parametrization type
Mybe you're looking for this pattern:
type Foo{T <: String}
a::T
b::T
end
Foo(a::String, b::String) = Foo(promote(a,b)...)
If you don't know promote, here's an excerpt from help()
julia> help(promote)
Base.promote(xs...)
Convert all arguments to their common promotion type (if any), and
return them all (as a tuple).
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
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
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.
[julia-users] Re: Confused about parametrization type
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.
>>>
>>
[julia-users] Re: Confused about parametrization type
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.
>>
>
[julia-users] Re: Confused about parametrization type
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. >
[julia-users] Re: Confused about parametrization type
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.
>
