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