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
