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