That's a very good clue. And, it relates to an oversight on my part
when I was looking at this:
In the example that fails, the y argument to getdetail1_jpm_ is this
one line sequence of lines:
10000000 Sava y
That matches the monadic definition of Sava
Meanwhile,
# _1{::5!:2 <'Sava'
25
Sava's full definition has 25 rows (one of which is the ':' line which
separates the monadic and dyadic definitions. So, the result from
getdetail2_jpm_ is providing the details for both the monadic and
dyadic definitions of Sava,
Hilarity ensues...
Anyways, I suspect that the fix would be to make getdetail2_jpm_
distinguish between information for monadic lines and information for
dyadic lines.
Looking at the implementation, it's a bit odd, because in the calling
getdetail_jpm_ the code seems to be asking for both the monadic
details and the dyadic details though at the same time there's also a
constraint which limits the request to be asking for only the monadic
details or only the dyadic details. So there's some unnecessary work
being done which sort of confuses things. But this suggests that
another plausible fix would be to rip out support for the unnecessary
redundant/contradictory queries and force the resulting
simplifications into the upper level code.
Anyways, it looks like some change did not deal with ambivalence
adequately and plausibly there's no test in the test suite for jpm to
catch that issue.
But this looks to be a big issue, and it might be faster for the
maintainer of jpm to zoom in on the right approach here (since there's
some intent issues which I'm not aware of)?
Meanwhile, as you point out, avoiding ambivalence looks like the way
to work around this problem.
I hope this helps,
--
Raul
On Mon, Jun 21, 2021 at 6:45 AM 'Michael Day' via Beta
<[email protected]> wrote:
>
> I tried tracing the behaviour but got rather lost! I see what you
> mean, but don't know why
> it happens. Anyway, I'm trying to improve my program, not J software!
>
> I have a sort of clue - I ran the Lab on "Performance Monitor Utilities"
> which I hadn't done for
> years, and realised its example uses a function, accpay, which is a
> non-ambivalent monad,
> ie there's no allowance for missing left argument such as I nearly
> always use. The lab's invocation
> of showdetail_jpm_ worked fine in the same session where it had failed
> for Sav(a).
>
> So I tried removing the default LH-arg bit; here's the new start:
>
> Sav =: monad : 0
> NB. 16384 Sav y NB. old dyadic input
> NB. :
> x =. 16384 NB. force required LH argument
> .............
>
> showdetail_jpm_ worked ok!
>
> I wonder why?
>
> Mike
>
> On 20/06/2021 15:49, Raul Miller wrote:
> > I do not have a copy of j7.01 on any of my current machines. I could
> > probably install one, but:
> >
> > If you use the debugger and put a stop on the line which throws the
> > error for you, what is different about the data there? (The error
> > comes from trying to index a 2 element array with the index value 2).
> >
> > Thanks,
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
