See #5468 <https://github.com/JuliaLang/julia/pull/5468> and linked issues.
Thanks,
Jiahao Chen
Staff Research Scientist
MIT Computer Science and Artificial Intelligence Laboratory
On Sat, Jan 31, 2015 at 7:49 AM, David P. Sanders <dpsand...@gmail.com>
wrote:
>
>
> El sábado, 31 de enero de 2015, 15:46:50 (UTC+3), David P. Sanders
> escribió:
>>
>>
>>
>> El sábado, 31 de enero de 2015, 15:35:49 (UTC+3), Jiahao Chen escribió:
>>>
>>> Hm, this is a tough one. The imaginary unit im is currently defined to
>>> be of type Complex{Bool}, which seems to be the cause of the type
>>> instability. Previously im was its own ImaginaryUnit type, which meant that
>>> very few functions were defined on just im and also led to a lot of
>>> unwanted NaNs cropping up in computations.
>>>
>>
>> What is the reason why `im` is not just defined as `Complex(0,1)`?
>>
>
>
> Oh, I guess there's the obvious issue of what type the real and imaginary
> parts should be.
> So really, im should be parametrised on this type.
>
>
>> I'm sure there's a good one, since this must have been thought about at
>> length, but I'd like to know what it is or have a reference to the
>> discussion.\
>>
>> Best,
>> David.
>>
>>
>>
>>> Thanks,
>>>
>>> Jiahao Chen
>>> Staff Research Scientist
>>> MIT Computer Science and Artificial Intelligence Laboratory
>>>
>>> On Sat, Jan 31, 2015 at 5:53 AM, Tim Holy <tim....@gmail.com> wrote:
>>>
>>>> There seem to be some problems with type inference and `im`. If at the
>>>> beginning of the function I define
>>>> myim = convert(Complex128, im)
>>>> and then replace all uses of `im` with `myim`, then everything works as
>>>> expected.
>>>>
>>>> Can you file an issue, please?
>>>>
>>>> --Tim
>>>>
>>>> On Friday, January 30, 2015 09:48:26 PM Kirill Ignatiev wrote:
>>>> > I have a newbie-type performance question.
>>>> >
>>>> > In some of my code there is a structure that looks like this:
>>>> >
>>>> > type FourierPoly
>>>> >
>>>> > > periods :: Vector{Int}
>>>> > > radiuses :: Vector{Float64}
>>>> > > phase_offsets :: Vector{Float64}
>>>> > >
>>>> > > end
>>>> >
>>>> > and the following two functions that operate on it:
>>>> >
>>>> > - function polyval(f::FourierPoly, t::Float64)
>>>> >
>>>> > > 33694968 s = zero(Complex128)
>>>> > >
>>>> > > 0 @inbounds for k = 1:length(f.periods)
>>>> > > 0 s += exp(2.pi*(t + f.phase_offsets[k]) * f.periods[k]
>>>> * im)
>>>> > >
>>>> > > * f.radiuses[k]
>>>> > >
>>>> > > - end
>>>> > > 0 return s::Complex128
>>>> > > 0 end
>>>> > > 0
>>>> > > 0 function polyder(f::FourierPoly, t::Float64)
>>>> > > 0 s = zero(Complex128)
>>>> > >
>>>> > > 492303248 @inbounds for k = 1:length(f.periods)
>>>> > >
>>>> > > 0 θ = 2.pi * f.periods[k]
>>>> > >
>>>> > > 164100720 s += θ * im * exp((t + f.phase_offsets[k]) * θ * im) *
>>>> > > f.radiuses[k]
>>>> > >
>>>> > > 257652 end
>>>> > >
>>>> > > 0 return s::Complex128
>>>> > > - end
>>>> >
>>>> > (copied from output of julia run with --track-allocation=user).
>>>> >
>>>> > What is the difference between these two functions? polyval seems
>>>> fine, but
>>>> > polyder is called at most as often as polyval from the rest of the
>>>> code,
>>>> > yet its memory consumption is at least an order of magnitude higher?
>>>> Can
>>>> > somebody please point out what I'm missing here?
>>>>
>>>>
>>>
