0

Under what circumstances could ⎕DR intermittently fail?

While it's been running fine for years, our system which reads binary data from a file recently from time to time has been crashing with a DOMAIN ERROR at ⎕DR.

The application code in question reads data from a native file and looks something like this: 

[0]  r ← convert data
[1]  r ← 0 0 0 0 0
[2]  r[1] ← 323 ⎕DR data[1 2 3 4]
[3]  r[2] ← 323 ⎕DR data[5 6 7 8]
[4]  r[3] ← 645 ⎕DR data[9 10 11 12 13 14 15 16]
[5]  r[4] ← 645 ⎕DR data[17 18 19 20 21 22 23 24]
[6]  r[5] ← 645 ⎕DR data[25 26 27 28 29 30 31 32]

It is at one of the 645 ⎕DR lines where the program has been crashing, the following is what caused it to crash this last time:

645 ⎕DR ⎕AV[157 43 52 44 1 1 215 96]

On the other hand, the following works:

645 ⎕DR ⎕AV[1 1 1 1 2 71 134 232]

We use Dyalog APL version 10.

Lobachevsky
  • 1,222
  • 9
  • 17
Googolplex Starthinker
  • 11
  • 1
  • 1
    Some more details would be helpful, such as which version of Dyalog and perhaps even some code so that we know if you're using monadic or dyadic ⎕DR... – MBaas Oct 13 '15 at 06:37
  • Could you at least isolate and post the []DR expression which gives the offending domain error? – Lobachevsky Oct 13 '15 at 07:21
  • MUCH better. Consider eventually changing over to []IO 0 - the world has changed since the early days of APL when Fortran (with its Origin 1 world view) was one of the dominant languages. – Lobachevsky Oct 14 '15 at 09:19
  • I guess it must have something to do with indices being > 127 and thus affecting the datatype of the string (and its converted result) - but I do not have enough experience with dyadic ⎕DR to give a profound explanation. I'd recommend to get in touch with support@dyalog.com or ask in the forum at www.dyalog.com - even though V10 is no longer officially supported, you should still get an answer (BTW, this also crashes in V14.1, so it is a general issue...) – MBaas Oct 15 '15 at 08:35
  • It's a NaN. Will post an answer when I have time. – Lobachevsky Oct 15 '15 at 10:37

1 Answers1

3

The floating point value which would otherwise be contained in

645 ⎕DR ⎕AV[157 43 52 44 1 1 215 96]

is a NaN (Not A Number) with a payload value of 2.251799834E15 or 20150831 (31 August 2015??), depending on how you look at it.

To my knowledge, no existing APL today handles NaNs as part of its floating point repertoire (IBM 360 floating point had none of this), hence the DOMAIN ERROR.

See

https://en.wikipedia.org/wiki/NaN

https://en.wikipedia.org/wiki/Double-precision_floating-point_format

Why does IEEE 754 reserve so many NaN values?

and also search for "Double NaN payload".

APL provides a way to easily examine the contents of NaNs. Try the following:

       ⊖ 8 8 ⍴ 11 ⎕DR ⎕AV[157 43 52 44 1 1 215 96]
0               ⍝ sign bit, does not matter for NaN
  1 1 1 1 1 1 1 ⍝ 11 bit exponent, should be all 1
1 1 1 1 
        1 0 0 0 ⍝ the rest is the exponent
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 1
0 0 1 1 0 0 1 1
0 1 1 1 1 0 1 0
0 0 1 0 1 1 1 1

The ⊖ is necessary as the number is stored as little endian in memory. The answer starts to make sense when compared to the 64-bit double pattern diagram in the Wikipedia articles.

The payload is the whatever is in the exponent.

      ⍝ value of exponent
      2⊥12↓,⊖ 8 8 ⍴ 11 ⎕DR ⎕AV[157 43 52 44 1 1 215 96]
2.251799834E15
      ⍝ ignore that first bit
      2⊥13↓,⊖ 8 8 ⍴ 11 ⎕DR ⎕AV[157 43 52 44 1 1 215 96]
20150831

Negative and positive infinity are similar.

What software or language created this data?

Community
  • 1
  • 1
Lobachevsky
  • 1,222
  • 9
  • 17