Hi Frederick,
in IBM APL2 dyadic scalar functions functions can have an axis:
a←3 3⍴⍳9
b←1 2 3
a +[1] b
2 3 4
6 7 8
10 11 12
a +[2] b
2 4 6
5 7 9
8 10 12
However there are additional constraints on the arguments when a
dyadic scalar
function is used with an axis:
a +[2] a
AXIS ERROR
a+[2]a
^ ^
So the reason for an axis error is that although the axis was
allowed, the additional
requirements on the arguments were not fulfilled In the example above
the ranks of the
arguments should differ by 1, but they do not.
Regarding axis error vs. syntax error, it seems like IBM APL2
reports axis error when
the ISO standard proposes syntax error. In ISO p. 63 it says:
If M is not an axis-operator, signal syntax-error
In contrast, the IBM APL2 language reference says (p 45):
For axis specification, writing brackets next to a function or
operator is always syntactically
correct, but evaluation of the related
function succeeds only when the following
specific conditions are true:
The bracket _expression_ contains no semicolon
The data in brackets is the proper type
The data in brackets is the proper rank
The function or operator is one of those shown in Figure
7
The data in brackets is within the range defined by the
function or operator
Otherwise, an AXIS ERROR occurs.
Of course, if you add some exal_XXX() function to a function class
then you override the default behaviour of ignoring the axis.
If there is a function that has no axis (as per ISO or APL2) and
does not ignore the axis
then this is a fault and should be fixed.
Best regards,
/// Jürgen
On 07/06/2017 05:56 PM, Frederick Pitts
wrote:
Hello Jürgen,
Why does your justification for not reporting AXIS ERROR's
apply to monadic functions like sign(+), first (↑), factorial
(!),
not(∼), etc, but not their dyadic partners, add, pick,
binomial and with-out? For example,
a ← 3 3 ⍴ ⍳ 9
b ← 2 + a
+[1] a
1 2 3
4 5 6
7 8 9
a +[1] b
AXIS ERROR
a+[1]b
^ ^
Not that I am suggesting you do it, the axis specification
could be just as easily ignored for the add function as the sign
function. To the contrary, I believe sign, first, factorial,
not, and other monadic functions that do not support axis
specifications should also report AXIS ERROR's. I'm confident
doing so would benefit anyone trying to leaBest regards,
Jürgen
n APL and those of us who occasionally get confused about
what is and is not supported by the language.
Per your comments in item 3) of your email, I was able make
monadic primitives that do not support axis specifications
report SYNTAX_ERROR's if an axis-specification is applied to
them. The only wrinkle was that I had to add methods eval_XB,
eval_ALXb, eval_LRXB and eval_ALRXB to eval_XXX group of methods
modified. And for consistency with how the dyadic function axis
specification errors are reported, AXIS_ERROR should be used
rather than SYNTAX_ERROR.
Regards,
On Wed, 2017-07-05 at 00:01 +0200, Juergen Sauermann wrote:
Hi Fred,
this is actually a language extension which has a deeper
background.
I define a language extension to be a (different) behaviour of
the interpreter when
the standard or the IBM language reference return an error.
Sometimes extensions
are introduced or adopted from other interpreters (for example
⍳1 2 3 taken from
Dyalog) or because the language becomes more general.
So what you see is a language extension and the reason is this.
1. GNU APL supports axis arguments for defined functions. This
is so that you can
write proper wrapper functions around APL primitives. Since
defined functions can
not be overloaded you need a way to write a wrapper that can
emulate the optional
axis argument of the wrapped apl primitive. I was always annoyed
by not being able
to write such wrappers, in particular for benchmarking purposes.
2. Since the axis argument is optional in all apl primitives
that can have one, the axis
is also optional in GNU APL defined functions. You can check for
its presence with
⎕NC just like for optional left arguments.
3. Another concept in GNU APL is that there shall be as few
differences as possible
between primitive functions (including ⎕-functions) and defined
functions. A consequence
of that (which simplifies the parser a lot) is that also all
primitive function can have
an axis argument. The default behaviour in both cases is to
ignore the axis argument.
That is what you see for ↑[] but also for all other primitives
that have no axis variant.
You can change that by changing e.g.
virtual Token eval_AXB(Value_P A, Value_P X, Value_P B)
{ return eval_AB(A, B); }
to:
virtual Token eval_AXB(Value_P A, Value_P X, Value_P B)
{ SYNTAX_ERROR; }
in all eval_XXX() functions declared in Function.hh
that have an X (for axis) in their name. Since all
functions are derived from this class it will change all
primitives, but
also all defined functions and operators. I personally would not
do it, though.
This language extension has been in GNU APL since almost day
one. Therefore I
cannot predict how often it is used (you can also do some dirty
tricks with it). For
that reason I believe it is better not to change it.
Best Regards,
Jürgen Sauermann
On 07/04/2017 07:42 PM, Frederick
Pitts wrote:
Hello Jürgen,
The IBM 'APL2 Programming: Language Reference' suggests that
axis specification is not allowed with the first function in that
'Figure 7. Functions and Operators That Allow Axis Specification', page
45, does not list 'First' by the '↑' symbol, whereas ravel, catenate
and laminate are listed by the ',' symbol. The text under Figure 7 says
an AXIS ERROR occurs if a function or operator is not in the list.
ISO/IEC 13751:2000(E)' contains 'Table 4: The Form Table',
pages 71-74, which claims to list all syntactic-units for which
evaluation sequences exist. The first function with axis specification
does not appear in that table.
Yet Gnu-APL allows
↑[ 2 ] 3 3 3 ⍳ 27
1
which is the first scalar in the ravel of the argument and the axis
specification is being ignored.
Neither IBM or ISO specifications say that the first function
with axis specification is part of the language. I respectfully submit
that Gnu-APL should report an attempt to use first function with axis
specification as a syntax error.
Regards,
Fred
|