Oh, yeah. I forgot that .+, .-, etc are not along for the ride yet. I understand it is pretty much ready for inclusion in 0.6.
There is also a one extra allocation, namely y.', which would not be necessary in a loop. But this is hardly worse than numpy, right? On Tuesday, September 13, 2016 at 2:42:35 PM UTC+2, Mauro wrote: > > On Tue, 2016-09-13 at 14:26, Neal Becker <[email protected] <javascript:>> > wrote: > > So you're saying that abs2.(x .- y.') will not allocate a 2d array and > then > > pass to abs2? That's great! But how would I know that? > > The operators do not do the fusing yet, check right at the bottom of the > linked manual section. I think you can work around it by using their > functional form: > > x .+ y # not fused > (+).(x,y) # fused > > So: > > out .= abs2.((-).(x, y.')) > > > DNF wrote: > > > >> For your particular example, it looks like what you want is (and I am > just > >> guessing what mag_sqr means): > >> dist = abs2.(x .- y.') > >> The performance should be the similar to a hand-written loop on version > >> 0.5. > >> > >> You can read about it here: > >> > http://docs.julialang.org/en/release-0.5/manual/functions/#dot-syntax-for-vectorizing-functions > > >> > >> > >> On Monday, September 12, 2016 at 9:29:15 PM UTC+2, Neal Becker wrote: > >>> > >>> Some time ago I asked this question > >>> > >>> > http://stackoverflow.com/questions/25486506/julia-broadcasting-equivalent-of-numpy-newaxis > > >>> > >>> As a more interesting example, here is some real python code I use: > >>> dist = mag_sqr (demod_out[:,np.newaxis] - const.map[np.newaxis,:]) > >>> > >>> where demod_out, const.map are each vectors, mag_sqr performs > >>> element-wise euclidean distance, and the result is a 2D array whose > 1st > >>> axis matches the > >>> 1st axis of demod_out, and the 2nd axis matches the 2nd axis of > >>> const.map. > >>> > >>> > >>> From the answers I've seen, julia doesn't really have an equivalent > >>> functionality. The idea here is, without allocating a new array, > >>> manipulate > >>> the strides to cause broadcasting. > >>> > >>> AFAICT, the best for Julia would be just forget the vectorized code, > and > >>> explicitly write out loops to perform the computation. OK, I guess, > but > >>> maybe not as readable. > >>> > >>> Is there any news on this front? > >>> > >>> >
