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
