<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Hi Frederick,<br>
<br>
in IBM APL2 dyadic scalar functions functions can have an axis:<br>
<br>
<b> a←3 3⍴⍳9</b><b><br>
</b><b> b←1 2 3<br>
<br>
</b><b> a +[1] b</b><b><br>
</b><b> 2 3 4</b><b><br>
</b><b> 6 7 8</b><b><br>
</b><b>10 11 12</b><b><br>
</b><b><br>
a +[2] b</b><b><br>
</b><b>2 4 6</b><b><br>
</b><b>5 7 9</b><b><br>
</b><b>8 10 12</b><br>
<br>
However there are additional constraints on the arguments when a
dyadic scalar<br>
function is used with an axis:<br>
<br>
<b> a +[2] a</b><b><br>
</b><b>AXIS ERROR</b><b><br>
</b><b> a+[2]a</b><b><br>
</b><b> ^ ^</b><br>
<br>
So the reason for an axis error is that although the axis was
allowed, the additional<br>
requirements on the arguments were not fulfilled In the example above
the ranks of the<br>
arguments should differ by 1, but they do not.<br>
<br>
Regarding axis error vs. syntax error, it seems like IBM APL2
reports axis error when<br>
the ISO standard proposes syntax error. In ISO p. 63 it says:<br>
<br>
<i>If M is not an axis-operator, signal syntax-error</i><br>
<br>
In contrast, the IBM APL2 language reference says (p 45):<br>
<br>
<i>For axis specification, writing brackets next to a function or
operator <b>is always syntactically</b></i><b><i><br>
</i></b><i><b>correct,</b> but evaluation of the related
function succeeds only when the following</i><i><br>
</i><i>specific conditions are true:</i><i><br>
The bracket expression contains no semicolon</i><i><br>
</i><i> The data in brackets is the proper type</i><i><br>
</i><i> The data in brackets is the proper rank</i><i><br>
</i><i> The function or operator is one of those shown in Figure
7</i><i><br>
</i><i> The data in brackets is within the range defined by the
function or operator</i><i><br>
</i><i>Otherwise, an AXIS ERROR occurs.</i><i><br>
</i><br>
</font><br>
<font face="Helvetica, Arial, sans-serif"><br>
Of course, if you add some exal_XXX() function to a function class<br>
then you override the default behaviour of ignoring the axis.<br>
<br>
If there is a function that has no axis (as per ISO or APL2) and
does not ignore the axis<br>
then this is a fault and should be fixed.<br>
<br>
Best regards,<br>
/// Jürgen<br>
<br>
</font><font face="Helvetica, Arial, sans-serif"></font><br>
<div class="moz-cite-prefix">On 07/06/2017 05:56 PM, Frederick Pitts
wrote:<br>
</div>
<blockquote cite="mid:***@comcast.net"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div>Hello Jürgen,</div>
<div><br>
</div>
<div> Why does your justification for not reporting AXIS ERROR's
apply to monadic functions like sign(+), first (↑), factorial
(!),</div>
<div>not(∼), etc, but not their dyadic partners, add, pick,
binomial and with-out? For example,</div>
<div><br>
</div>
<div> a ← 3 3 ⍴ ⍳ 9</div>
<div> b ← 2 + a</div>
<div> +[1] a</div>
<div>1 2 3</div>
<div>4 5 6</div>
<div>7 8 9</div>
<div> a +[1] b</div>
<div>AXIS ERROR</div>
<div> a+[1]b</div>
<div> ^ ^</div>
<div>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,</div>
</blockquote>
Jürgen<br>
<br>
<blockquote cite="mid:***@comcast.net"
type="cite">
<div>n APL and those of us who occasionally get confused about
what is and is not supported by the language.</div>
</blockquote>
<blockquote cite="mid:***@comcast.net"
type="cite">
<div> 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.</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>On Wed, 2017-07-05 at 00:01 +0200, Juergen Sauermann wrote:</div>
<blockquote type="cite"> Hi Fred,<br>
<br>
this is actually a language extension which has a deeper
background.<br>
<br>
I define a language extension to be a (different) behaviour of
the interpreter when<br>
the standard or the IBM language reference return an error.
Sometimes extensions<br>
are introduced or adopted from other interpreters (for example
⍳1 2 3 taken from<br>
Dyalog) or because the language becomes more general.<br>
<br>
So what you see is a language extension and the reason is this.<br>
<br>
1. GNU APL supports axis arguments for defined functions. This
is so that you can<br>
write proper wrapper functions around APL primitives. Since
defined functions can<br>
not be overloaded you need a way to write a wrapper that can
emulate the optional<br>
axis argument of the wrapped apl primitive. I was always annoyed
by not being able<br>
to write such wrappers, in particular for benchmarking purposes.<br>
<br>
2. Since the axis argument is optional in all apl primitives
that can have one, the axis<br>
is also optional in GNU APL defined functions. You can check for
its presence with<br>
⎕NC just like for optional left arguments.<br>
<br>
3. Another concept in GNU APL is that there shall be as few
differences as possible<br>
between primitive functions (including ⎕-functions) and defined
functions. A consequence<br>
of that (which simplifies the parser a lot) is that also all
primitive function can have<br>
an axis argument. The default behaviour in both cases is to
ignore the axis argument.<br>
That is what you see for ↑[] but also for all other primitives
that have no axis variant.<br>
You can change that by changing e.g.<br>
<br>
<b> virtual Token eval_AXB(Value_P A, Value_P X, Value_P B)</b><b><br>
</b><b> { return eval_AB(A, B); }</b><b><br>
</b><br>
to:<br>
<br>
<b> virtual Token eval_AXB(Value_P A, Value_P X, Value_P B)</b><b><br>
</b><b> { SYNTAX_ERROR; }</b><br>
<br>
<br>
in all <b>eval_XXX</b><b>()</b> functions declared in <b>Function.hh</b>
that have an <b>X</b> (for axis) in their name. Since all
functions are derived from this class it will change all
primitives, but<br>
also all defined functions and operators. I personally would not
do it, though.<br>
<br>
This language extension has been in GNU APL since almost day
one. Therefore I<br>
cannot predict how often it is used (you can also do some dirty
tricks with it). For<br>
that reason I believe it is better not to change it.<br>
<br>
Best Regards,<br>
Jürgen Sauermann<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 07/04/2017 07:42 PM, Frederick
Pitts wrote:<br>
</div>
<blockquote cite="mid:***@comcast.net"
type="cite">
<pre wrap="">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
</pre>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>