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. >> >> Blake McBride >> ---------------------------------------------------------------------- >> 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
