Steven G. Johnson wrote:
...
>
> Note that you have the same problem in several places, e.g. in
> Constellation.jl.
>
> (I don't really understand what that file is doing, but it seems to be
> constructing lots of little arrays that would be better of constructed
> implicitly as part of other data-processing operations.)
>
> There are lots of micro-optimizations I can spot in Constellation.jl, e.g.
> let k = 2*pi/N; [cis(k*x) for x in 0:N-1]; end is almost 2x faster than
> [exp(im*2*pi/N*x) for x in 0:N-1] on my machine, but as usual one would
> expect that the biggest benefits would arise by re-arranging you code to
> avoid multiple passes over multiple arrays and instead do a single pass
> over one (or zero) arrays.
Constellation is just a mapping from an Array{Integer} ->
Array{Complex{Float64}}.
I think I would prefer it to accept an Array{any Integer type}. It's
normally constructed only once, so I don't care about performance of the
construction.
I'd expect it to be called with a large array as input, so hopefully it's
performant enough as is, leaving the type of the argument determined at
runtime:
Basically, it is just this:
type constellation{flt}
C::Array{Complex{flt},1}
end
function (c::constellation)(xsyms)
return [c.C[x+1] for x in xsyms]
end
I guess it would be better to write
function (c::constellation}{T}(xsyms::Array{T})
...
?
