> When you say (N =: f N =: 1) can be treated like (N =: f N)
you must be meaning something else, because this is obviously false if the value of N is, say, 2. N =: f N =: (anonymous noun/result) By the time f N is evaluated, it shouldn't make a difference if N was assigned on the same line (to the right). I am guessing that you are interpreting (N =: f N =: 1) as (N =: f 1) instead of (N =: f N) I suggest you can do the latter (after making the first assignment). Can't tell you how, though. ----- Original Message ----- From: Henry Rich <[email protected]> To: [email protected] Sent: Wednesday, October 5, 2016 11:21 PM Subject: Re: [Jprogramming] Early assignment WAS: Non-mutable arrays I have been assuming that by 'N' you meant 'any name'. And in that case, the statements are assuredly NOT the same. N =: value f N is different from f N =: value for proper choices of N and value. Your assignment is to demonstrate this. The 'top of stack reference' is not deleted after an assignment. In fact, it becomes the RESULT of the assignment. (f 1) cannot inplace the result if the line is executed from an explicit definition, because then the 1 must not be modified. When you say (N =: f N =: 1) can be treated like (N =: f N) you must be meaning something else, because this is obviously false if the value of N is, say, 2. Henry Rich On 10/5/2016 10:55 PM, 'Pascal Jasmin' via Programming wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
