Hi,
it looks to me like that the discussion on comp.lang.apl
exactly hits the issue.
I have simplified Xiao-Yong's example a little and compared GNU
APL with IBM APL2.
In IBM APL2 we have:
Q←(1 2) (3
4)
On 7 July 2016 at 12:55, Jay Foad wrote:
> (⊂+/3 4 ⍴ 5 6)≡3 4 +.⍴ 5 6
> 1
Ah, I see what you mean. But it still wasn't my error, it's really what
ISO says. It's not equivalent to APL2 definition, nor to Dyalog's one,
and it seems to be wrong altogether.
-k
Hi,
Dyalog APL and GNU APL use different reduction styles and both are
allowed in the ISO standard.
I had a brief look at the example and my impression is that the
differences for f.g
in Dyalog APL
and in GNU APL are primarily caused by the di
There was some relevant discussion in comp.lang.apl here:
https://groups.google.com/forum/#!topic/comp.lang.apl/23LrwRZKmPs
On 6 July 2016 at 19:31, Xiao-Yong Jin wrote:
> The following from GNU APL,
>
> (⊂[1]⍳2 3)+.+.+⊂[1]10×⍳2 3
> 209 198
> (⊂[1]⍳2 3)(+.+).+⊂[1]10×⍳2 3
> 209 198
On 7 July 2016 at 11:39, Kacper Gutowski wrote:
> On 7 July 2016 at 11:07, Jay Foad wrote:
> > (I think you meant ⊂f/A g B on the RHS?)
>
> No, I don't think I did. That enclosure is already a result of reduction.
>
I was thinking of cases like this (in GNU APL):
(+/3 4 ⍴ 5 6)≡3 4 +.⍴ 5
On 7 July 2016 at 11:07, Jay Foad wrote:
> (I think you meant ⊂f/A g B on the RHS?)
No, I don't think I did. That enclosure is already a result of reduction.
In any case, the problem seems not to be related to inner product or to
parsing of multiple operators at all. It manifests in any reducti
On 7 July 2016 at 03:59, Kacper Gutowski wrote:
> The standard explicitly says A f.g B ←→ f/A g B when A & B vectors.
>
(I think you meant ⊂f/A g B on the RHS?)
But in the +.(+.+) case, it's Dyalog that gives unexpected results:
>
> +/A(+.+)B
> 33 66 66 66
> A+.(+.+)B
> 99 132
