BookmarkSubscribeRSS Feed
esirjhm
Calcite | Level 5

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  

8 REPLIES 8
esirjhm
Calcite | Level 5

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
Opal | Level 21

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
Quartz | Level 8

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

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

esirjhm
Calcite | Level 5

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.

esirjhm
Calcite | Level 5

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
Quartz | Level 8

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.

sas-innovate-2024.png

Available on demand!

Missed SAS Innovate Las Vegas? Watch all the action for free! View the keynotes, general sessions and 22 breakouts on demand.

 

Register now!

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 8 replies
  • 1296 views
  • 1 like
  • 4 in conversation