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)`?  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 <javascript:>
> > 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?
>>
>>
>

Reply via email to