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