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....


On Sun, Sep 18, 2016 at 3:57 PM, Henry Rich <> 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
For information about J forums see

Reply via email to