Thank you very much!!
On Thu, Jan 27, 2022 at 5:53 AM Dr. Jürgen Sauermann <
mail@jürgen-sauermann.de> wrote:
> 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
>>
>>
>>
>
