There's no guarantee that an amend will be inplace. If the value of the
name is also assigned to another name, inplacing is impossible.
Henry Rich
On 11/13/2019 12:06 AM, Ben Gorte wrote:
Yeah, it always looks a bit scary to do X =: A I}X to modify only a small
part of X, but at the end of
https://www.jsoftware.com/help/jforc/modifying_an_array_m.htm
we are promessed that J does that in place.
I think this should not change when A depends on what was already there, in
I{X, as is very often the case. Of course it is important whether you agree
:-)
In your example you're moving things somewhere else inside the array. I
sort of understand it can be tricky to do that in-place when the source and
the destination overlap.
On Wed, 13 Nov 2019 at 14:43, Henry Rich <[email protected]> wrote:
I should say, you can't count on the JE to make the best decision
unaided. If you write
big =: i. 1e4 1e4
big =: (1 { big) 2} big
it will not run inplace & will be very slow. Why? Because (1 { big)
will produce a virtual result, i. e. a noun whose data is mapped to a
subarray of another noun (viz big).
Having the virtual result extant makes big ineligible for inplacing, so
the 2} requires copying big. The JE can't look ahead to see that it
should forego inplacing { for the greater good of inplacing big} .
In this case, you must assign (1 { big) to a name, which will realize
the value and remove the restraint on inplacing big} .
Henry Rich
On 11/12/2019 6:32 PM, Ben Gorte wrote:
Great, thanks!
Greetings,
Ben
On Wed, 13 Nov 2019 at 02:54, Henry Rich <[email protected]> wrote:
Fixed for next release. The problem was that (x{M) created a temporary
in-place noun to refer to atoms of M; this raised the usecount of M
rendering it uninplaceable for the amend (}). The in-place noun should
have been released right after it was used, but erroneously it was not
released until the end of the sentence.
The workaround is to do the fetch from M in a different sentence. And do
try those forms that avoid boxing.
Henry Rich
On 11/12/2019 2:17 AM, Ben Gorte wrote:
Dear J'ers
I'm using large 3D arrays (voxels), such as
M =: ?400 400 400$100
To add 1 to a bunch of voxels at positions
I =: ?100 3$400
I go like:
timespacex 'M =: (1+(;/I){M) (;/I) } M'
1.3e_5 42048
This was in version 8.07:
JVERSION
Engine: j807/j64/linux
Release: commercial/2018-10-04T15:00:41
Library: 8.07.26
In version 9.01, however: timespacex 'M =: (1+(;/I){M) (;/I) } M'
0.238664 5.36912e8
It became thousands of times slower! I'm doing this hundreds of
thousands
of times and it takes weeks instead of minutes.
A multi-dimensional index for amend does not need to be boxed in j901,
but:
timespacex 'M =: (1+(;/I){M) I } M'
0.238302 5.36894e8
gives pretty much the same result.
This is with:
JVERSION
Engine: j901/j64avx2/linux
Beta-p: commercial/2019-11-06T09:48:25
Library: 9.01.10
I was wondering whether it happend in { or }, but to my great surprise:
timespacex 'new =: 1+(;/I) { M'
8e_6 21824
timespacex 'M =: new (;/I) } M'
6e_6 20992
So the solution is to do it in two steps !?!?
With unboxed I in step 2, I get even:
timespacex 'M =: new I } M'
2e_6 2560
Am I missing a point? Could I have foreseen this?
Greetings,
Ben
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
