Re: [Bug-apl] Strange domain error

[Kacper Gutowski]

On 2014-06-10 14:08:47, Blake McBride wrote:
> It is funny because I call this function a lot.  Sometimes it works, other
> times it gives me the domain error.  Here are some more facts:
> 
> DOMAIN ERROR
> Tmfmt[1]  z←(2 0⍕⍉d[,1;]),':',2 0⍕⍉(d←(2⍴100)⊤,d)[,2;]
>                               ^   ^
>       d
> 2
> 0

I think I know what the problem might be.
To confirm, run 2⎕TF'd' which should show you what the values *really*
are.  I suspect that d contains a complex zero 0J0.

When result of encode ⊤ contains zero, sometimes it's returned internally
represented as a complex number instead of real.  I discovered this in
January [1], but concluded that this should not be a problem because for
real arguments it will return near-reals anyway (AFAIK the standard doesn't
say they can not be complex), and near-reals are for all intents and
purposes indistinguishable from reals; therefore I reported it as problem
with functions requiring near-reals rather than with encode.  It has been
fixed in SVN 117 and worked for what I tested.

Now, as for dyadic format A⍕B, ISO 13751 contradicts itself (or maybe
is just underspecified).  First, it contains a note saying that “for
complex elements of B, the precision specifier applies to each part of
the representation.”  And then it gives an evaluation sequence which
explicitly states that “if any item of the ravel-list of B is not a
real-number, signal domain-error.”  Note, that it says “real-number,”
not “near-real number.”  It seems that behavior of GNU APL matches the
evaluation sequence as given by the standard.

I'm not sure, whether it should be resolved by changing ⊤ never to return
complex numbers for real arguments, or by making ⍕ accept it somehow.
Perhaps both.

-k

[1] https://lists.gnu.org/archive/html/bug-apl/2014-01/msg00116.html