It's clear that the interpreter does delete old copies sooner or later, otherwise J would crash from out of memory errors after extended operations.
(It's a reference counting implementation - not so good for fine grained performance but excellent for large flat arrays.) I will agree that some number of copies will be maintained but not arbitrarily many. For example: A=: X Y} A Here, when A=: is executed the old copy of A is dereferenced. The interpeter does not hold onto every value of A from every loop instance if the above sentence appears in a loop (except for trivially cases). I believe you are focusing on whether the value from A can be dereferenced while ignoring the surrounding context. And you are right about that issue: that would be unsafe. Thanks, -- Raul On Mon, Jan 13, 2014 at 3:26 PM, Henry Rich <henryhr...@nc.rr.com> wrote: > You have a point, IF the interpreter can figure out when a copy can be > deleted. Often it can't. We would need the exact code to be sure. > > Code that modifies part of an array is often - I would say usually - faster > when explicit. > > Henry Rich > > > On 1/13/2014 3:14 PM, Raul Miller wrote: >> >> Could you explain your reasoning? >> >> I understand O(n^3) time from the multiple copies - you have O(n^2) >> time cost multiplied by n repetitions. But space cost should be O(n^2) >> -- the number of copies of the array needed should have a fixed upper >> bound, because previous temporary copies do not need to be preserved. >> >> I am amused though, that this illustrates a case where the interpreter >> is designed to be more efficient with explicit code than tacit. >> >> (Or did I miss something?) >> >> 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
