On 8 July 2016 at 09:04, Kacper Gutowski wrote:
> But I was looking at the evaluation sequence just below the informal
> description you quoted and after some reshaping and scalar expansion
> it says:
>
> > If A1 and B1 are both vectors, return f/A1 g B1.
> > Otherwise, set Z to an array such tha
On 8 July 2016 at 09:24, Jay Foad wrote:
> So if A and B are vectors, Z is a scalar whose single item is f/AgB. Hence Z
> itself is ⊂f/AgB.
I think you are right that it should be ⊂f/AgB. I stand corrected.
But I was looking at the evaluation sequence just below the informal
description you quo
On 7 July 2016 at 12:57, Kacper Gutowski wrote:
> 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 see
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
On 6 July 2016 at 20:31, Xiao-Yong Jin wrote:
> I’m not sure which one is at fault here. Any idea?
The standard explicitly says A f.g B ←→ f/A g B when A & B vectors.
A←⊂[1]⍳2 3
B←⊂[1]10×⍳2 3
GNU APL is at fault here:
{⍺+.+⍵}/A+B
165 242
(+.+)/A+B
209 198
But in the
11 matches
Mail list logo
