A further possibility is to work with vector of FixedSizeArrays (a julia package). You can cast a dxn array to an n-array of immutable d-FixedSizeVectors (they have the same memory layout) and then access the columns directly using stack allocation (just the same as you would work with a complex vector instead of a 2xn array)
Am Montag, 8. Februar 2016 00:39:28 UTC+1 schrieb Nitin Arora: > > Thanks and Tim and Stefan, if there is anyway I can contribute to help, do > let me know. > > thanks, > Nitin > > On Sunday, February 7, 2016 at 8:24:38 AM UTC-8, Stefan Karpinski wrote: >> >> Being able to stack-allocate objects that refer to the heap is an >> important case that we need to address, but doing so is non-trivial and >> hasn't been done yet. >> >> On Sunday, February 7, 2016, Tim Holy <[email protected]> wrote: >> >>> I filed an issue, https://github.com/JuliaLang/julia/issues/14955, >>> which you >>> can check to learn about progress on this problem. >>> >>> Best, >>> --Tim >>> >>> On Saturday, February 06, 2016 03:35:34 PM Nitin Arora wrote: >>> > I see, thanks for the information. I think, if possible, this feature >>> will >>> > help the language a lot. >>> > >>> > I have recommended Julia to many of my colleagues (they all love it >>> over >>> > Fortran and Matlab) and most of them seem to run into this issue. I >>> think, >>> > a modern language with soo much elegance and potential, like Julia, >>> should >>> > nail such major issues. I am sure by V-1.0 we will have the best >>> scientific >>> > programming language ever :-) >>> > >>> > thanks, >>> > Nitin >>> > >>> > On Saturday, February 6, 2016 at 3:55:56 AM UTC-8, Tim Holy wrote: >>> > > On Friday, February 05, 2016 05:24:04 PM Nitin Arora wrote: >>> > > > Thanks Tim, this is very useful. I will probably use >>> CartesianRange now. >>> > > > >>> > > > Is Julia 0.5 Arraypocalypse planning to address this issue as well >>> ? >>> > > >>> > > I don't think there's a way to solve this by changing our >>> implementation >>> > > of >>> > > views; I think it's more of a compiler issue, and the fact that >>> > > >>> > > julia> isbits(CartesianRange((3,5))) >>> > > true >>> > > >>> > > julia> immutable ArrayWrapper{M} >>> > > >>> > > data::M >>> > > >>> > > end >>> > > >>> > > julia> z = rand(5,5); >>> > > >>> > > julia> isbits(ArrayWrapper(z)) >>> > > false >>> > > >>> > > >>> > > Since I don't work on the compiler, I can't speak for what's going to >>> > > happen >>> > > there, but I'd be surprised if this changes in 0.5. >>> > > >>> > > Best, >>> > > --Tim >>> > > >>> > > > thanks, >>> > > > Nitin >>> > > > >>> > > > On Friday, February 5, 2016 at 3:24:34 PM UTC-8, Tim Holy wrote: >>> > > > > On Friday, February 05, 2016 08:17:21 AM Kevin Squire wrote: >>> > > > > > I think this needs to be @time bar(A). >>> > > > > >>> > > > > Yeah, sorry for the typo. >>> > > > > >>> > > > > > I get >>> > > > > > >>> > > > > > julia> @time bar(A) >>> > > > > > >>> > > > > > 0.000269 seconds (5 allocations: 176 bytes) >>> > > > > > >>> > > > > > 20010.937886591404 >>> > > > > >>> > > > > That's just REPL allocation. Since A has 10000 columns, if this >>> > > >>> > > strategy >>> > > >>> > > > > were >>> > > > > allocating you'd expect "10000+n allocations," where n comes >>> from the >>> > > > > REPL. >>> > > > > >>> > > > > --Tim >>> >>>
