That's not a calculated inverse of an explicit function. That's an assigned obverse, and the explicit verb can be replaced with a verb with an empty domain without changing the result:
[: :.-:inv 4 2 (Thinking about this case was why I specified a 'calculated inverse' rather than just an inverse.) Thanks, -- Raul On Mon, Sep 19, 2016 at 2:22 PM, 'Pascal Jasmin' via Source < sou...@jsoftware.com> wrote: > h =: 3 : '+: y' :. -: > > h inv 4 > 2 > > > > ----- Original Message ----- > From: Raul Miller <rauldmil...@gmail.com> > To: Source forum <sou...@jsoftware.com> > Sent: Monday, September 19, 2016 2:01 PM > Subject: Re: [Jsource] Why is dual calculated at verb-execution time? > > Are there any examples of explicit functions which have a computed inverse? > > My guess would be no, since even identity functions (which are their own > inverse) currently yield a domain error: > > 3 :'y'inv 0 > |domain error > > Thanks, > > -- > Raul > > > On Mon, Sep 19, 2016 at 11:52 AM, 'Pascal Jasmin' via Source < > sou...@jsoftware.com> wrote: > > > 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 > > > ---------------------------------------------------------------------- > 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
