[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Outer product with replicate error

From: Juergen Sauermann
Subject: Re: [Bug-apl] Outer product with replicate error
Date: Sun, 15 May 2016 11:20:18 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0


I changed GNU APL already yesterday, but I could not commit since the SVN repo
was down (and still is).

You can apply the patch below to make GNU APL behave like Dyalog.

/// Jürgen

--- Parser.cc   (revision 11104)
+++ Parser.cc   (working copy)
@@ -525,6 +525,7 @@
         case TC_L_PARENT:   // e.g. (/       (actually syntax error)
         case TC_VALUE:      // e.g. 5/
         case TC_RETURN:     // e.g.  /       (actually syntax error)
+        case TC_OPER2:      // e.g. ./
              return true;   // tos[pos] is at the end of a value
         case TC_R_BRACK:    // e.g. +[1]/2 or 2/[1]2

On 05/15/2016 03:49 AM, David B. Lamkins wrote:
While `$ info apl` speaks to the issues around function/operator ambiguity, it does not make any mention of the outer product case.

I suspect that the failure of "outer product expand" is an oversight. This case is disambiguated by noticing the outer product during the right-to-left scan that GNU APL does anyway (step 3 in the referenced info page).

Outer product is a common idiom dating from the earliest days of APL. It doesn't make any sense to require special (i.e. specific to GNU APL) syntax for this particular case.

On Sat, May 14, 2016 at 01:31:13PM -0500, Xiao-Yong Jin wrote:

On May 14, 2016, at 7:51 AM, David Tran <address@hidden> wrote:


Newbie study "MasteringDyalogAPL"; got error on page #388 example:

      3 0 2 ∘./ 5 1 7
      3 0 2∘./5 1 7
      ^      ^

bug? ( or this is a specify feature of Dyalog and not APL2 ? )
It’s documented in the info page of gnu apl.  A feature (bug?) of the parser treats / as an operator in this case.  Simple workaround would be

      3 0 2 ∘.{⍺/⍵} 5 1 7
 5 5 5  1 1 1  7 7 7 
 5 5    1 1    7 7   

I have too limited experience to say whether it is good or bad.  Perhaps the parser should accept some exceptional cases?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]