GitLab

Bugzilla Link	1042
Created on	Jan 09, 2013 15:16
Version	svn
OS	Linux
Architecture	PC

Extended Description

I have been looking at the SAC stdlib rotate (and shift)
functions, as they relate to AWLF, and this led me to
look at the definition of the _mod_()
primitive in SAC. I find it wanting, for several reasons.
The underlying challenge is to make AWLF/WLF operate
with rotate as a producer WL and as a consumer WL.
The existing stdlib code uses mod() and a conditional
to normalize the rotate count. I.e., map it
into a non-negative integer
in the range 0...(N-1), where N is the length of
the rotation axis. In the common cases
where the rotate count is a constant, this is not
a problem. However, in APL code, we often see
expressions such as this one, to drop the leading
blanks from a text vector:
((vec≠' ')⍳1) ↓ vec
or
((vec≠' ')⍳1) ⌽ vec
I do not know what the design rationale was for the mod()
primitive, but suspect it was intended to mimic the
behavior of the (equally ill-defined) a%b (remainder)
operation in C.
1. According to the C99 standard*, the result is defined only
    if "...the quotient a/b is representable". E.g.,
    0%0 is undefined.
    For rotate() arguments where the rotate count ends up being
    zero, this can cause the normalization of the rotate count
    to signal an error.
    In APL, where considerable thought was
    given to the definition of residue (aka remainder) on
    all integers, floats, and complex numbers,
    0 | 0 ( 0%0  in C) is defined to produce 0.
2. In K&R (2nd Edition), "the sign of the result for
    % {is} machine-dependent for negative operands."
   By constrast, in APL, the definition is clearly specified for
   all integer (and, in fact, all numeric) arguments. NB. 
   argument order is reversed in SAC from that of APL:
    ¯5 ¯4 ¯3 ¯2 ¯1 0 1 2 3 4  NB.  A
     0  1  2  3  4 0 1 2 3 4  NB.  5|A (AKA A%5)
  This is not the same as the current behavior of the SAC
    mod() primitive on negative A:
    -5 -4 -3 -2 -1 0 1 2 3 4  NB. A
    -5 -4 -3 -2 -1 0 1 2 3 4  NB. A%5
    Note that the APL definition maps a negative
    rotate count into the correct non-negative count.
    The SAC behavior requires checking for a negative
    count and then adding b to the count for negatives.
    This often inhibits the ability to perform AWLF on
    rotated arguments/results, because of problems
    around partition/index vector intersect calculation.
    Furthermore, it may be that the SAC definition is
    "implementation-dependent", in which case we are
    left in a position of not being able even to specify the
    behavior of the stdlib rotate() function. It could screw
    anyone running on an implementation (e.g., Windows?) that produces
    different results.
    If we are going to define stdlib functions on SAC primitives,
    then we need to define the precise semantics of those
    primitives, and eschew "implementation-dependent"
    behavior.
So, a few questions,and a few proposals for redefinition:
Q1: Does anybody depend on the result of SAC
      mod() on negative or zero arguments?
Q2: Are there concrete objections to extending the definition
      of SAC mod() to handle zeros and negative arguments
      in the same way that APL does, thereby avoiding
      any arguments about "implementation-defined"
      behavior there and in the stdlib?
P0: If the answers to Q1 and Q2 are No, I propose to
      change sac2c mod() to operate as APL does, and
      to change the stdlib rotate() functions to rely on
      that definition.
2013-01-09: I have not heard any response from sacdev or others
on this topic. Silence is consent, in my book, so I am going
to proceed with the above implementation, as proposed.
* This is a draft of same:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf