If there are no candidates for in place operation, then time and space for making copy will be wasted.
On Oct 6, 2016 6:09 AM, "Louis de Forcrand" <[email protected]> wrote: > In > N=: f N=: 1 2 3 > If I understand correctly, N itself has no usecount. However, 1 2 3 does, > and when it's assigned to N, its usecount is incremented (to a value of 2), > which makes it ineligible for IPO. > In other words, the interpreter does not look further (yet?) to the > beginning of the line, where we can see that the old value of N can be > discarded. If there was no a=: at the beginning of the line, doing IOPs on > 1 2 3 would corrupt a. > The way I would get around this would be to make a copy of 1 2 3 (with a > usecount of 1), on which I then do all the IOPs I want, and then reassign > it to a if needed. This would prevent corruption of a if any one of the > IOPs failed, while still retaining a large advantage in speed over the old > method wouldn't it? > > Louis > > > On 05 Oct 2016, at 16:10, 'Pascal Jasmin' via Programming < > [email protected]> wrote: > > > > > > > >> Assignment to (a) increments the usecount, giving (a) a usecount of 2. > > > > I think in the expression, > > > > > > f N =: 1 2 3 NB.(where 1 2 3 is anonymous noun/result) > > > > > > N or 1 2 3 has a use count of 1 here, right after the assignment. (more > precisely the anonymous "usecount" is freed) > > > > There is no possible f such that f N differs from f N =: (noun). ie. the > line is always identical to the 2 lines > > > > N =: (noun) > > f N > > > > > > > > > > ----- Original Message ----- > > From: Henry Rich <[email protected]> > > To: [email protected] > > Sent: Tuesday, October 4, 2016 10:42 PM > > Subject: Re: [Jprogramming] Early assignment WAS: Non-mutable arrays > > > > Yes, you're right, I misanalyzed. It goes like this: > > > > 1 2 3 starts with a usecount of 1, and a mark to indicate that the > > usecount should be decremented when the sentence completes. [When the > > usecount is decremented to 0 the block is freed]. > > > > Assignment to (a) increments the usecount, giving (a) a usecount of 2. > > That makes (a) ineligible for in-place operations. > > > > > > Henry Rich > > > > > >> On 10/4/2016 10:21 PM, 'Pascal Jasmin' via Programming wrote: > >> this didn't seem to work in beta 12 (latest all in one installer) > >> > >> > >> > >> > >> ----- Original Message ----- > >> From: Henry Rich <[email protected]> > >> To: [email protected] > >> Sent: Tuesday, October 4, 2016 10:14 PM > >> Subject: Re: [Jprogramming] Early assignment WAS: Non-mutable arrays > >> > >> Yes, this is executed in-place. > >> > >> In general, an assignment to a name whose value is not in use in another > >> name causes that value to become eligible for in-place execution (with > >> the possibility of early assignment) as long as the execution stack > >> contains nothing beyond the value to be assigned. > >> > >> a=: ('b' ,~ 4,~])a =: 1 2 3 NB. in place > >> > >> (a=: ('b' ,~ 4,~])a =: 1 2 3) [ 1 NB. not in place > >> > >> Henry Rich > >> > >> > >> > >> > >> > >>> On 10/4/2016 9:28 PM, 'Pascal Jasmin' via Programming wrote: > >>> I made different suggestions in my beta post. namely, this expression > should also be optimized: > >>> > >>> > >>> a=: ('b' ,~ 4,~])a =: 1 2 3 > >>> > >>> if possible, early assignment should also apply in scripts (even if > through tacit expressions). > >>> > >>> In general though, I think the advice "assign to new name to be safe", > works ok, but above line in console can be edited and reapplied with > consistent results. > >>> > >>> > >>> > >>> > >>> > >>> ----- Original Message ----- > >>> From: Henry Rich <[email protected]> > >>> To: [email protected] > >>> Sent: Tuesday, October 4, 2016 7:25 PM > >>> Subject: [Jprogramming] Early assignment WAS: Non-mutable arrays > >>> > >>> The whole point of operation in place is to avoid having to copy an > >>> in-placeable argument; copying the argument would not be a good > solution. > >>> > >>> After hearing the screams and dodging the dead cats, I have some > proposals: > >>> > >>> 1. Early assignment (which is what we'll call the act of assigning an > >>> intermediate value to a name that is about to be reassigned) will apply > >>> only for sentences executed from an explicit definition. That will > >>> eliminate the most likely source of confusion, which is erroneous > >>> sentences typed into the console during debugging and exploration. > >>> > >>> For discussion here: > >>> > >>> 2. Early assignment could be disabled for sentences executed between > >>> try. and catch. This would apply only to sentences from the same > >>> execution that contains the try. Verbs called from within the try. > >>> block will continue to have early assignment enabled as specified by > the > >>> setting of 9!:52''. > >>> > >>> 3. Error message text could be modified to indicate that an early > >>> assignment occurred. I worry about this because existing code might > >>> rely on the text of messages. > >>> > >>> Henry Rich > >>> > >>> > >>>> On 10/4/2016 3:01 PM, Louis de Forcrand wrote: > >>>> I second Raul; the behaviour described is very counter-intuitive. > Maybe add a third setting to 9!:53 which copies a at the start of a tacit > verb involving in place operations? > >>>> > >>>> Also, what is the current (j804) behaviour when an in-place ammend > fails? > >>>> Since there's only one operation, if it fails a shouldn't be modified > should it? > >>>> If so, copying a at the beginning of a tacit verb containing more > than one in-place operation (IPO) should always be faster than the current > implementation, since copying would only be needed when two or more IPOs > take place. > >>>> > >>>> Louis > >>>> > >>>>> On 04 Oct 2016, at 07:15, Raul Miller <[email protected]> wrote: > >>>>> > >>>>> When there are many verbs involved, it seems like the relative cost > to > >>>>> make a copy of the original at the start should be minor. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> -- > >>>>> Raul > >>>>> > >>>>> > >>>>>> On Mon, Oct 3, 2016 at 10:52 PM, Henry Rich <[email protected]> > wrote: > >>>>>> The shape is just the tip of the iceberg. If the verb in question > were m}, > >>>>>> there would be no way to restore (a). > >>>>>> > >>>>>> And in general, many in-place verbs may have executed before the > error. The > >>>>>> original (a) may be long gone. > >>>>>> > >>>>>> If you foresee this as a problem, you should execute 9!:53(0) to > turn off > >>>>>> early assignment. > >>>>>> > >>>>>> Henry Rich > >>>>>> > >>>>>>> On 10/3/2016 10:34 PM, Raul Miller wrote: > >>>>>>> > >>>>>>> There are two reasons to be concerned about the value of a in the > error > >>>>>>> case. > >>>>>>> > >>>>>>> The minor one is error recovery. This is a simple example, and > easy to > >>>>>>> understand. What happens, though, when someone uses try./catch. > with a > >>>>>>> large code base? This issue would not be easy to isolate, nor will > it > >>>>>>> be easy to understand. > >>>>>>> > >>>>>>> A bigger issue is the one you mentioned here: debugging. When > >>>>>>> debugging code which takes a long time to run, you will at times > want > >>>>>>> to fix the issue and continue, rather than burning the time > necessary > >>>>>>> to restart from the beginning. > >>>>>>> > >>>>>>> And, also, this seems like it will be hard to explain and at the > same > >>>>>>> time distract from issues which are more important. > >>>>>>> > >>>>>>> But keep in mind that I am not recommending the (a=:0)](a) > mechanism > >>>>>>> for this example. I made that suggestion for hypothetical cases. > >>>>>>> > >>>>>>> I am instead recommending that the shape of a be saved somewhere > and > >>>>>>> that a have its shape set to what it originally was, in the error > >>>>>>> case. > >>>>>>> > >>>>>>> Is there some reason why you think that restoring a's shape in the > >>>>>>> error case is not a viable approach here? > >>>>>>> > >>>>>>> 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 > >>>> ------------------------------------------------------------ > ---------- > >>>> 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 > > ---------------------------------------------------------------------- > > 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
