where you have (anonymous name) I had/meant (anonymous noun/result)
N =: 1 f N f 1 f N =: 1 are all (last 3) the same to me, including if f is ] In the first expression, if I can guess why it ends in use count of 1 is that the statement terminates, and the "original top of stack value" can be discarded. It is just temporarily increased to usecount=2 by the assignment. What if "the top of stack" reference was decreased/let go immediately on assignment? (replaced with the named ref). The one difference between the 3 statements is that (f 1) can inplace the result, but (f N) cannot, unless it is (N =: f N). Logically though, (N =: f N =: 1) can be treated like (N =: f N). ----- Original Message ----- From: Henry Rich <[email protected]> To: [email protected] Sent: Wednesday, October 5, 2016 8:31 PM Subject: Re: [Jprogramming] Early assignment WAS: Non-mutable arrays I am changing your statement to: "There is no possible f such that N =: (anonymous name) f N gives a different result from f N =: (anonymous name) " [because obviously f N is different from f N =: 1] Answer: yes, there is a counterexample. The function f can be ] Now the question for you: tell me what N looks like. It's a cute puzzle. Henry Rich On 10/5/2016 7:23 PM, 'Pascal Jasmin' via Programming wrote: > Just in case I'm not the one misunderstanding, > > is there a counter example to > > "There is no possible f such that f N differs from f N =: (anonymous noun)" > > > > ----- Original Message ----- > From: Henry Rich <[email protected]> > To: [email protected] > Sent: Wednesday, October 5, 2016 3:58 PM > Subject: Re: [Jprogramming] Early assignment WAS: Non-mutable arrays > > All I can say is, It doesn't work that way. (You have 2 statements, > each with 2 versions. All 4 statements are false.) > > Henry Rich > > On 10/5/2016 10:10 AM, 'Pascal Jasmin' via Programming 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
