Re: Unexpected result with inner product

[Blake McBride]

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