> > For the sake of compatibility with IBM APL2
Speaking of which, what is GNU APL's official policy? I noticed that the info manual ( https://www.gnu.org/software/apl/apl.html#APL-symbols-that-can-be-functions-or-operators) is factually wrong about APL2, claiming that: > the ambiguity related to / ⌿ \ and ⍀ is not resolved by these rules. > The APL2 language reference does in fact make it perfectly clear how / and friends are treated, namely as operators. Always. Note: > [image: image.png] > And then: > [image: image.png] > Note that this makes APL2 ISO non-compliant. Indeed, here, GNU APL follows Dyalog and NARS2000: 1 2 3/¨'ABC' A BB CCC While APL2 and APLX give: 1 2 3/¨'ABC' AAAAAA BBBBBB CCCCCC This is because 1 2 3/ is a derived monadic function and ¨ maps the entire function to each letter. On Mon, Nov 23, 2020 at 9:21 PM Dr. Jürgen Sauermann < mail@jürgen-sauermann.de> wrote: > Hi Kacper, Adam, > > thanks. For the sake of compatibility with IBM APL2 I have changed *⎕UCS* > so that > it accepts float and complex numbers that are near to integers. My > initial thinking was > that e.g.* ⎕UCS* of a complex number is most likely a programming mistake > so > that a DOMAIN ERROR would be more helpful than being a burden. But APL2 > compatibility is an even stronger argument in this case. > > I have also adjusted the integer domain which is now -$80 ... $7FFFFFFF > so that no conflicts with signed bytes from *⎕FIO *should arise. > > *SVN 1362*. > > Best Regards, > Jürgen > > > > On 11/22/20 11:11 PM, Kacper Gutowski wrote: > > On Sun, Nov 22, 2020 at 03:19:19PM +0100, Dr. Jürgen Sauermann wrote: > > Floating point and complex numbers are not allowed as to avoid > interference with ⎕CT (i.e. how should rounding be performed?). > > > I share your sentiment regarding the upper bound of the ⎕UCS domain, but > throwing a domain error on ⎕UCS1E2 looks like a bug to me too. 1E2 is > clearly an integer regardless of the implementation details, and I would be > surprised if APL2 didn't accept it. I would expect rounding to be the same > as in all the other places that require near-integers, like array indices. > > The negative ones are also a bit weird. I wasn't aware of their > existence, and they seem to work in surprising ways when passed to various > variants of ⎕CR. > > -k > > >
