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

Reply via email to