Henry, I still don't understand, consider the
following log on the current beta-12.
<<<<<<<<<<<<<<< log started
9!:53[0
a=: 3 1 4 1 5 9 2
a =: ('b' ,~ 3 ,~ ]) a
|domain error
| a=: ('b',~3,~])a
a
3 1 4 1 5 9 2
9!:53[1
a =: ('b' ,~ 3 ,~ ]) a
|domain error
| a=: ('b',~3,~])a
a
3 1 4 1 5 9 2 3
a=: 3 1 4 1 5 9 2
9!:53[2
a =: ('b' ,~ 3 ,~ ]) a
|domain error
| a=: ('b',~3,~])a
a
3 1 4 1 5 9 2 3
9!:53[0
a =: ('b' ,~ 3 ,~ ]) a=: 3 1 4 1 5 9 2
|domain error
| a=: ('b',~3,~])a=:3 1 4 1 5 9 2
a
3 1 4 1 5 9 2
9!:53[1
a =: ('b' ,~ 3 ,~ ]) a=: 3 1 4 1 5 9 2
|domain error
| a=: ('b',~3,~])a=:3 1 4 1 5 9 2
a
3 1 4 1 5 9 2
9!:53[2
a =: ('b' ,~ 3 ,~ ]) a=: 3 1 4 1 5 9 2
|domain error
| a=: ('b',~3,~])a=:3 1 4 1 5 9 2
a
3 1 4 1 5 9 2
<<<<<<<<<<<<<<< log ended
for the sentence
a =: ('b' ,~ 3 ,~ ]) a
only 9!:53[0 can prevent half-modified, so that
9!:53[1 is still unsafe?
On the other hand the sentence
a =: ('b' ,~ 3 ,~ ]) a=: 3 1 4 1 5 9 2
There is no half-modified, for all 9!:53[0 1 2
because this sentence is not eligible for in-place
operation? or some other reasons?
Can you also elaborate the difference between 9!:53[1 and 2?
Ср, 05 окт 2016, Henry Rich написал(а):
> 9!:53 (0) will run in-place only on the last (or only) verb in a compound,
> and only if that verb will complete without error.
>
> 9!:53 (1) will run in-place wherever the previous contents of the
> to-be-assigned noun are no longer needed, and only if that verb will
> complete without error.
>
> 9!:53 (2) will run in-place wherever the previous contents of the
> to-be-assigned noun are no longer needed.
>
> Henry Rich
>
> On 10/5/2016 12:28 PM, Don Guinn wrote:
> > Thread moved to beta.
> >
> > Determining when in line processing is okay can get very difficult,
> > depending on how extensive one wants to be. J already does checking on
> > compatibility of arguments before it begins actual execution on data. When
> > the assigned name is an argument in the execution in line processing can
> > give a significant performance boost. When only one primitive is involved
> > determining if in line processing is okay should not be too difficult. But
> > when multiple primitives are in the expression it can get difficult. All
> > the cases presented as failures have involved multiple primitives in the
> > expression. Perhaps limiting in line processing to single primitive
> > expressions at first, especially for primitives not rank 0, then extend
> > later.
> >
> > 9!:53 can take 0, 1 and 2 . Do 1 and 2 give different levels of
> > aggressiveness of in line checking? If not then maybe 1 could provide
> > "safe" in line processing and 2 could extend in line to the questionable
> > cases.
> >
> >
> >
> > On Tue, Oct 4, 2016 at 6:34 PM, Xiao-Yong Jin <[email protected]> wrote:
> >
> > > > On Oct 4, 2016, at 2:01 PM, Louis de Forcrand <[email protected]> wrote:
> > > >
> > > > Maybe add a third setting to 9!:53 which copies a at the start of a
> > > tacit verb involving in place operations?
> > >
> > > This is a good compromise between speed and sensible intuition.
> > > I guess a memcpy only when in-place-operation is detected wouldn't be
> > > slower in general than previous non-in-place operations.
> > > This could certainly be the default option.
> > > ----------------------------------------------------------------------
> > > 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
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
