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.
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.h...@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?
>
>
