Re: Unexpected result with inner product

[Dr . Jürgen Sauermann]

    Hi again, Gentlemen,
    
    I double-checked with IBM APL2 and the output of IBM APL2 was indeed
    what Elias was expecting.
    
    My previous answer below was only half-way correct: Like I supposed,
    the problem was in fact related to enclose and disclose in the inner
    product.
    However, the problem was not caused by the regular behaviour of
    enclose
    and disclose but simply by a missing disclose in the APL macro that
    implements the inner product when called with a defined function.
    
    Fixed in SVN 1515.
    
    Best Regards,
    Jürgen

On 1/26/22 10:37 PM, Blake McBride wrote:

As a more general comment relating to these sorts of issues, I offer the following opinion.

I imagine that there are many variations that can legitimately be argued.  Where one lands on an issue is somewhat arbitrary.  In some instances, X is better and makes more sense.  And in other instances, Y makes more sense.  Sometimes the answer is logically clear but more often not.

For better or worse, given its somewhat "standard-setting" regard, I think of IBM's APL-2 as "the standard".  For me, it's not a matter of who is right.  That can be debated ad nauseam.  I just consider IBM APL-2 APL-2.  All else are variations on a theme.

It is my understanding that one of the main goals of GNU APL is to provide an open-source implementation of IBM APL-2.  If one were looking for a platform to do explorations in the APL space, we already have NARS2000, KAP, and other vendors to a lesser degree.  I do not think GNU APL was attempting the same thing.

If I am correct, these sorts of debates are far simpler.  We don't debate the various merits.  Rather, we simply compare the results with IBM APL-2.  Case closed.

Also, if my view of GNU APL is correct, I like this fact a lot!  For better or worse, it works a specific way and won't change because someone has a good example and argument.  I am interested in stability and reliability.

Just an opinion.

Blake McBride

On Wed, Jan 26, 2022 at 2:47 PM Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote:

Hi Elias,

I suppose the reason is roughly this:

Some interpreter, including IBM APL2 and GNU APL, sometimes
allow 1-element vertors (lets call them quasi-scalars) in places
where strictly speaking scalars would be required.

Your partial results 0/x if some a=0 is always a vector while 1/x
for some other a-1 is always 1 1-element vector which is subject
to be being treated as a scalar instead.

When the the inner product f.g and the outer product ∘.g gets
 a non-scalar result from g then it will enclose that result before
the f/ and disclose it again after the f/.

The final disclose will in your case see a mix of 0-element and
1-element vectors and will scalar-entend the 1-element
quasi-scalars to the common shape of all items which is,
in your example empty).

A different A reveals this:

      (1⌈A≠0) +.Q B
 6  6
 6  6
 6  6

Best Regards,
Jürgen

On 1/26/22 5:25 AM, Elias Mårtenson wrote:

Consider the following code:

    A←3 4⍴1 3 2 0 2 1 0 1 4 0 0 2
    B←4 2⍴4 1 0 3 0 2 2 0
    Q←{⍺/⍵}
    (A≠0) +.Q B

My reading (and implementation) of the ISO spec suggests the output should be the following:

┏━━━┓
┃4 6┃
┃6 4┃
┃6 1┃
┗━━━┛

However, in GNU APL I get this:

┏→━━━━━━┓
↓┏⊖┓ ┏⊖┓┃
┃┃0┃ ┃0┃┃
┃┗━┛ ┗━┛┃
┃┏⊖┓ ┏⊖┓┃
┃┃0┃ ┃0┃┃
┃┗━┛ ┗━┛┃
┃┏⊖┓ ┏⊖┓┃
┃┃0┃ ┃0┃┃
┃┗━┛ ┗━┛┃
┗∊━━━━━━┛

Which one is correct?

Regards,

Elias