Re: [Bug-apl] Strange domain error

[Blake McBride]

I now see that I had a typo in my tests the last time I encountered the problem.  Too bad.  I have run that function in a loop more than 1000 times and it works every time.  I've only had it crash twice.  I did'n change any code in Time or Tmfmt, and they take no arguments, so there shouldn't be any situation that causes the problem.  

When encountered the problems I was debugging a function that now works, so the errors were in the context of another function.  (Although, again, that shouldn't have mattered since those functions do not take input or depend on external variables.)  Unfortunately, the function I was debugging now works.  I can't seem to cause the error anymore, but I am left feeling that something is unreliable.

I will try to cause it again.  If I do, I will do a lot more testing, and I will try to save the workspace.

Thanks.

Blake

On Tue, Jun 10, 2014 at 5:10 PM, Kacper Gutowski <address@hidden> wrote:

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