DATA Step, Macro, Functions and more

Apparent conversion inconsistency

Reply
Occasional Contributor
Posts: 8

Apparent conversion inconsistency

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  

Occasional Contributor
Posts: 8

Apparent conversion inconsistency

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.

PROC Star
Posts: 7,467

Apparent conversion inconsistency

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

Regular Contributor
Posts: 184

Apparent conversion inconsistency

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.

Frequent Contributor
Posts: 104

Apparent conversion inconsistency

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

Occasional Contributor
Posts: 8

Apparent conversion inconsistency

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.

PROC Star
Posts: 7,467

Apparent conversion inconsistency

Occasional Contributor
Posts: 8

Apparent conversion inconsistency

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.

Regular Contributor
Posts: 184

Apparent conversion inconsistency

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.

Ask a Question
Discussion stats
  • 8 replies
  • 225 views
  • 1 like
  • 4 in conversation