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> 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>
> 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
>>
>>
>
