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

Reply via email to