A general issue with explicit code is that h =: 3 : '...' cannot be set once because its possible for the contents of the explicit code to reassign h.
h f."0 y though could fix h to "original definition" and so ignore side effects during execution of "this instance" h h f."0 y would apply the new (if any) h definition if it is reset during execution of first (rightmost) h. h@h f."0 would not. ----- Original Message ----- From: Jose Mario Quintana <jose.mario.quint...@gmail.com> To: sou...@jsoftware.com Sent: Monday, September 19, 2016 11:42 AM Subject: Re: [Jsource] Why is dual calculated at verb-execution time? A potential alternative could be to delegate the optimization to fix (f.). That is, f. (in all its forms) would recursively optimize any instances of (forms involving) &. and &.: that it encounters when it is replacing all the names recursively by their referents. On Sun, Sep 18, 2016 at 4:16 PM, Raul Miller <rauldmil...@gmail.com> wrote: > Related, though, is how much time it takes to find if g contains names. > > If this can be significant, it might be worth going to the extra effort to > delay examining it for names until the point where you are prepared to use > its inverse. (And, having an "inverse that contains names" be a different > result than "inverse which does not contain names.) > > Or, another approach might be to spread out the cost of determining that > and putting the information in the verb definition. > > (Purely performance based changes should probably include a test against > the full test suite of unrelated operations just to make sure that they are > not imposing a significant cost on the general case?) > > Meanwhile, as an aside, I noticed this: > > 1 2 1&p. inv 16 25 > |domain error > > It looks like we are not supporting some potential inverses (or, ok, > obverses...) which we could be supporting. (And, yes, I know, two choices > here... but we do ok with things like arccosine despite a multiplicity of > choices.) But, of course, that is probably another project.... > > -- > Raul > > > > On Sun, Sep 18, 2016 at 3:57 PM, Henry Rich <henryhr...@gmail.com> wrote: > > > The point to me is that if you execute f&.g 1000 times, you only need the > > inverse of g once. > > > > Henry > > > > On 9/18/2016 1:09 PM, Raul Miller wrote: > > > >> Mmm.... > >> > >> I think you need the inverse of h regardless of whether it contains any > >> names. > >> > >> But I guess the point is that you do not need the inverse of h until > after > >> g has completed. And organizationally speaking doing the check right at > >> the > >> start (at or near the top level) makes sense. > >> > >> ... > >> > >> That said, was baffled by steps 2 and 3 here, until I took a look at > >> jtundco1 > >> > >> Now, I think the example h=: f&.:g should be introduced, to match that > >> implementation. > >> > >> 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
