Yes, that is obvious. But thanks for removing any confusion about this. My example was contrived to point to the issue.
Thanks. Blake McBride On Fri, Jan 6, 2012 at 10:24 AM, Marc Simpson <m...@0branch.com> wrote: > At the risk of stating the obvious: instead of > > x =: 55(3})44(2})x > > you can use > > x =: 55 44(3 2})x > > Note, > > ts =: 6!:2 , 7!:2@] > x =: i.10000 > ts 'x =: 55 44(3 2})x' > 3e_6 2176 > x > 0 1 44 55 4 5 6 ... > x =: i.10000 > ts 'x =: 55(3})44(2})x' > 2.1e_5 264576 > x > 0 1 44 55 4 5 6 ... > > You could use a similar rephrasing for your > > x=:55(3})(some verb returning a scalar)44(2})x > > example. > > Best, > M > > On Fri, Jan 6, 2012 at 4:11 PM, Roger Hui <rogerhui.can...@gmail.com> wrote: >> x=:44(2})x does not copy. All your other examples do. You can verify this >> using the technique that David Mitchell used. >> >> >> >> On Fri, Jan 6, 2012 at 7:56 AM, Blake McBride <bl...@mcbride.name> wrote: >> >>> So you are saying that J treats the following code 1 with a copy, and >>> code 2 without a copy? >>> >>> 1. y=:44(2})x >>> >>> 2. x=:44(2})x >>> >>> What about the following code: >>> >>> x=:55(3})44(2})x >>> >>> or: >>> >>> x=:55(3})(some verb returning a scalar)44(2})x >>> >>> Thanks for your response. It is very helpful! >>> >>> Blake McBride >>> >>> >>> On Fri, Jan 6, 2012 at 9:51 AM, Roger Hui <rogerhui.can...@gmail.com> >>> wrote: >>> > David Mitchell already answered your question. >>> > >>> > x i}y is not indexed assign. (Where's the assign?) y=:x i}y *is >>> *indexed >>> > assign and is lean and fast. >>> > >>> > >>> > >>> > On Fri, Jan 6, 2012 at 7:42 AM, Blake McBride <bl...@mcbride.name> >>> wrote: >>> > >>> >> This is a very important point. I'd like to get an official response to >>> >> this. >>> >> >>> >> Modifying an existing array could easily be 1,000 times faster than >>> >> creating a new, modified array. Naturally, this would depend on the >>> >> size and type of the array. Seeing how 'fast' it is in human or even >>> >> computer time means nothing! What is important is the relative time >>> >> between performing a real indexed update to a copy operation. Even a >>> >> small difference multiplied over a lot of operations can become >>> >> unbelievable significant. And, we are not talking about a small >>> >> difference! >>> >> >>> >> Imagine an application specific need to maintain a very large array >>> >> and make a lot of changes to individual elements. A program that does >>> >> only this on a large dataset could easily by 1,000 times more time >>> >> consuming. Imagine a situation where one program takes an hour to >>> >> complete a calculation and another takes 1,000 hours for the same >>> >> calculation. This is a significant issue. >>> >> >>> >> Blake McBride >>> >> >>> >> >>> >> On Fri, Jan 6, 2012 at 9:11 AM, David Mitchell <davidmitch...@att.net> >>> >> wrote: >>> >> > I believe that optimization is happening behind the scenes. See the >>> >> following >>> >> > tests actually timing indexed assignment, first without replacing the >>> >> original >>> >> > array and then replacing the original array: >>> >> > >>> >> > ts=: 6!:2 , 7!:2@] >>> >> > a=:i.1e6 >>> >> > ts'_777 (2 9 43556)}a' >>> >> > 0.0238083 8.39078e6 >>> >> > ts'a=:_777 (2 9 43556)}a' >>> >> > 1.00571e_5 2432 >>> >> > >>> >> > On 1/6/2012 9:54, Blake McBride wrote: >>> >> >> Greetings, >>> >> >> >>> >> >> Going through J I found that: >>> >> >> >>> >> >> x=:1+i.5 >>> >> >> x >>> >> >> 1 2 3 4 5 >>> >> >> 44 (2}) x >>> >> >> 1 2 44 4 5 >>> >> >> x >>> >> >> 1 2 3 4 5 >>> >> >> >>> >> >> It seems that J doesn't actually make an indexed assignment. It >>> seems >>> >> >> more like it creates a copy of the array with the specified >>> >> >> modifications. This is actually quite shocking. Index assignment to >>> >> >> a very large array in most languages is a very fast and simple >>> >> >> operation. It is also very memory efficient. Creating a modified >>> >> >> copy of a very large array has a much, much greater time and space >>> >> >> cost. Further, multiplying this (unnecessary) cost over a great >>> >> >> number of operations can drastically (and unnecessarily) affect >>> >> >> performance negatively. >>> >> >> >>> >> >> Am I missing something here? >>> >> >> >>> >> >> Thanks. >>> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
