|
From: | Dr . Jürgen Sauermann |
Subject: | Re: APL2 Compatibility |
Date: | Tue, 24 Nov 2020 17:17:05 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
GNU APL's general policy regarding standards and the like is to consider,For the sake of compatibility with IBM APL2
Speaking of which, what is GNU APL's official policy?
I see. That statement is probably a left-over from the early days of GNU APL. When I startedI 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.
I believe older GNU APL versions would have given the APL2/APL X results, while newer versionsThe APL2 language reference does in fact make it perfectly clear how / and friends are treated, namely as operators. Always. Note:
And then:
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
[Prev in Thread] | Current Thread | [Next in Thread] |