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