Re: ⍬ bug?

[David Tran]

Thanks Jürgen.  Yes, with new ⍬ constant ( value, not function ); it is consist and no confusion.

On Wed, Dec 25, 2019 at 7:50 AM Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote:

Hi,

after some more thinking and considering Elias' comment I have come to the
conclusion that it is cleaner to parse ⍬ as a constant than as a niladic function.

In particular since otherwise ⍬ (the empty numeric vector) and ' ' (the empty
text vector) would bind differently and therefore an unexpected inconsistency
between ' ' and ⍬ would occur.

The new parsing is effective as of SVN 1212.

The change only makes a difference in the following situation:

A. There is an APL literal that contains ⍬, and
B. That literal is the left argument of a dyadic function, and
C. The literal is not enclosed in parentheses.

For example:

1 ⍬ 3 + 4

If ⍬ is parsed as a niladic function (the old scheme) one gets:

      4⎕CR  1 ⍬ 3 + 4    ⍝ 1 ⍬ 3 + 4  ←→ 1 ⍬ (3 + 4)
┏→━━━━━━┓
┃1 ┏⊖┓ 7┃
┃  ┃0┃  ┃
┃  ┗━┛  ┃
┗∊━━━━━━┛


If ⍬ is parsed as a constant (which binds stronger to other constants) then
the new scheme gives:

      4⎕CR  1 ⍬ 3 + 4    ⍝ 1 ⍬ 3 + 4  ←→ (1 ⍬ 3) + 4
┏→━━━━━━┓
┃5 ┏⊖┓ 7┃
┃  ┃0┃  ┃
┃  ┗━┛  ┃
┗∊━━━━━━┛


Best Regards,
Jürgen

On 12/24/19 4:36 PM, Dr. Jürgen Sauermann wrote:

Hi,

yes. In some sense. Actually

1 2 X 4

is the same as 1 2 (X) 4

because there is a rule that says so. However, the point here is that

1 2 X 4

can be (very) different from

(1 2 X 4)

The difference does not occur in simple examples, but may in more complex ones.

1 2 X 4   + 1

is generally different from

(1 2 X 4)   + 1

simply because the order of evaluation differs between X and +. More generally, if
you put the left argument of a dyadic function in parentheses then that most likely
(though not neccessarily) changes the valuation order (and hence the result). I know
that this is odd, but so are niladic functions when it comes to parsing. According to
the IBM APL 2 parentheses rules, the parantheses around (⍬) are redundant (and
make no difference while the parentheses around (⍳0) are not redundant. As a
consequence, even though ⍳0 yields essentially ⍬ they are not entirely equivalent.

Best Regards,
Jürgen Sauermann

On 12/24/19 3:16 PM, Elias Mårtenson wrote:

I think such a change would make sense. A niladic function is in some sense a shortcut to writing a specific value, so it should probably be treated as such.

It a little odd that:

  1 2 X 4

is different from:

  1 2 (X) 4

Regards, 

Elias 

On Tue, 24 Dec 2019, 14:48 Dr. Jürgen Sauermann, <mail@jürgen-sauermann.de> wrote:

Hi David,

not sure either if this is a bug. The APL standard has quite a specification gap
when it comes to binding strength. In GNU APL, the binding between values
(aka strand notation) is stronger than the binding between values and functions.

For example:

      V←⍳0

∇Z←F
 Z←⍳0
∇

Both V and F result in the same value ⍬:

      V≡F
1

However, they are parsed differently:

      2 V 3⊃a
3

      2 F 3⊃a
 2    99

In the first case: 2 V 3⊃a the value V binds strongly to 2 and 3 so that value (2 V 3)
 becomes the left argument of ⊃. In the second case:  2 F 3 the value 3 binds
stronger to ⊃ than to F so that first  is evaluated 3⊃a and then the result of ⊃ is
tied to the F and 2.

In GNU APL ⍬ is a niladic function, so it behaves like F above.

This behaviour could be changed, but I hesitate to do that since it might break
existing code. The impact of such a change would not only affect ⍬ but all niladic
functions.

Best Regards,
Jürgen Sauermann

On 12/24/19 2:49 AM, David Tran wrote:

Ooops, missing something on my examples, correction:  ( missing ⊂ on ⍳3 )

a ← 'abc'(⊂⍳3)99

the 3 examples are the same:

2(⍳0)3⊃a

2⍬3⊃a

(2⍬3)⊃a

On Mon, Dec 23, 2019 at 7:20 PM David Tran <address@hidden> wrote:

Hi,

Not sure this is a bug or not, for me, (⍳0) ≡ ⍬, so it seems that both can be replaced each other; consider below example:

a←'abc'(⍳3)99

2(⍳0)3⊃a ⍝ ≡ 3

2⍬3⊃a ⍝ ≡ 2 ⍬ 99

(2⍬3)⊃a ⍝ ≡ 3

Doesn't the second example should return 3 as first example, without the need parentheses as third example?

(btw. my version is build from SVN around Oct )

Thanks,

Dave