Hi,
I have changed the code so that near-zero complex numbers in ⊤ are
demoted to integer 0, see SVN 319. This isn't quite in line with the
standard
who says that ⎕CT is not used in ⊤, but makes more sense to me.
/// Jürgen
On 06/11/2014 07:05 AM, Blake McBride wrote:
Even simpler:
)CLEAR
CLEAR WS
d←100 100⊤199
2 ⎕TF 'd'
d←1 99
d←100 100⊤200
2 ⎕TF 'd'
d←2 0J0
d←100 100⊤201
2 ⎕TF 'd'
d←2 1
The 0J0 is the winner!
--blake
On Tue, Jun 10, 2014 at 11:48 PM, Blake McBride <blake1...@gmail.com
<mailto:blake1...@gmail.com>> wrote:
I can now duplicate the problem every time!
Tmfmt 202
2:02
Tmfmt 201
2:01
Tmfmt 159
1:59
Tmfmt 158
1:58
Tmfmt 200
DOMAIN ERROR
Tmfmt[1] z←(2 0⍕⍉d[,1;]),':',2 0⍕⍉(d←(2⍴100)⊤,d)[,2;]
^ ^
2 ⎕TF 'd'
d←(2 1⍴2 0J0)
Only 200 causes the problem! It looks like you were right. Very
strange!
Blake
On Tue, Jun 10, 2014 at 11:35 PM, Blake McBride
<blake1...@gmail.com <mailto:blake1...@gmail.com>> wrote:
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
<mwgam...@gmail.com <mailto:mwgam...@gmail.com>> 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
