Apparent conversion inconsistency

[esirjhm]

I post this on the wrong forum, the ODS one and so I've duplicated it, but I think it belongs here.  I did have a response that said that nothing was wrong because the responder ran same program and got identical 10.5 results when the hex16. values were identical.  But the numbers the responder supplied do not work on the z/os machine I have.  The responder had another question: what this the entire program.  And the answer is yes, this is the entire program.

DATA TEST;                                                 

  HMWID = 62.7;                                             

  LIN_FT = 1;                                               

  RUN;                                                      

DATA AVAL (KEEP = K FT);                                   

  ARRAY LAR{240:799} _TEMPORARY_;                           

  SET TEST END=END;                                         

  PUTLOG HMWID=10.5  +3 HMWID=HEX16.;                       

  HMWID = HMWID * 10;                                       

  PUTLOG 'STORING VALUE '  HMWID=10.5 +3   HMWID=HEX16.;    

  LAR{HMWID} + LIN_FT;                                      

  IF END;                                                   

  DO J = 240 TO (799-40);                                   

     K  = J;                                                

     FT = LAR{J};                                           

     IF FT THEN DO;                                         

        OUTPUT AVAL;                                        

        PUTLOG 'RESTORING VALUE ' K=10.5 +3 HMWID=HEX16.;   

     END;                                                   

  END;                                                      

  RUN; 

Output results...                                                    

HMWID=62.70000    HMWID=423EB33333333333               

STORING VALUE HMWID=627.00000    HMWID=43272FFFFFFFFFFF

RESTORING VALUE K=626.00000    HMWID=43272FFFFFFFFFFF  

[esirjhm]

Maybe the problem is not all that obvious.  I have a value 62.7.  I multiply this value by 10 which should be give 627 exactly (or more or less).  I use this value as a subscript to store another value into an array, the array is LAR and the storing occurs at LAR{HMWID} + LIN_FT.

Then I search through this array looking for the non-zero value, DO J = 240 TO (799-40) and I find this at subscript 626.

But I just noticed a BUG in my code.  The PUTLOG 'RESTORING VALUE' has HMWID=HEX16. when it should have had K=HEX16.  And when I do that, I have a different answer.

HMWID=62.70000    HMWID=423EB33333333333               

STORING VALUE HMWID=627.00000    HMWID=43272FFFFFFFFFFF

RESTORING VALUE K=626.00000    K=4327200000000000      

I still have the same problem, which is, why does the HMWID which prints in 10.5 as 627.0000 and as hex16. as 43272F....FFF when converted into an integer to be used as a subscript turn into 626.0000.

I know how to get around the problem, but I don't understand the inconsistency (as I call it) in the first place.

[art297]

On Windows I get the consistent, expected result.  Have you looked at the SAS technical note regarding numeric precision and, particularly, the differences to be expected between various operating systems?  If not, take a look at: http://support.sas.com/documentation/cdl/en/lrcon/62955/HTML/default/viewer.htm#a000695157.htm

[Howles]

Keep in mind that non-integer array indexes are truncated, not rounded. For example, MYARRAY[2.999] is equivalent to MYARRAY[2], not MYARRAY[3]. Applying the FUZZ function can correct for the "drift" caused by limited floating point precision.

[DLing]

Agreed!  Non-integer array indices is a dangerous approach to programming.

[esirjhm]

Where is it documented that array idices are truncated?  I can't seem to find it in the SAS documentation.  And the value of 62.7 * 10 would appear to be an integer, especially when the format 10.5 produces five decimal places of zero.  At least it appeared to be an integer to me.

[art297]

http://support.sas.com/kb/5/689.html

[esirjhm]

I don't want to quible, but your reference is from the Samples and SAS Notes Knowledge Base and was noted on SAS 8.  I'm not sure this is exactly part of the SAS official documentation.  Did this truncation only begin with SAS 8?  What about SAS 5 and SAS 6?  Where was the documentation for these versions.

[Howles]

Five decimal places isn't enough to reveal the drift. Try format BEST32.

My statement about truncation was based on an experiment rather than on documentation. It appears to be undocumented (except for the KB article which Art referenced).

I suspect that truncation has always been the behavior, but I don't have any way of testing.

The documentation ought to explain this issue. I might even argue that the behavior should be changed by making the FUZZing automatic.

esirjhm wrote:
I don't want to quible, but your reference is from the Samples and SAS Notes Knowledge Base and was noted on SAS 8.  I'm not sure this is exactly part of the SAS official documentation.  Did this truncation only begin with SAS 8?  What about SAS 5 and SAS 6?  Where was the documentation for these versions.