In principle I don't see why the current Complex{Bool} definition shouldn't be
feasible. There might just be an inference bug. If you use @code_warntype,
you'll see that `im` gets annotated as `Any`.
--Tim
On Saturday, January 31, 2015 04:49:10 AM David P. Sanders 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 <[email protected]> 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?
