proc freq percent not exactly 100

[merryr]

I found an old thread about proc freq cumulative percent not adding up to exactly 100, but this is a little different.  I am doing a frequency (proc freq noprint with an output data set) where there is only one value of the 'tables' variable in the data so the percent itself (not just the cumulative percent) is 100.  It looks like 100 when we view the output data, and if we print it out with a format, even if the format is for example 32.28, we get 100.0000000000000000000000000000.  However in an 'if' expression it does not compare as being equal to 100 unless we round it.  

Why would that be?  This is only happening in one of three jobs (same code, different input data).  We could add a step to round the value of percent before doing the check for 100, but should that really be necessary?  How can we tell under what circumstances it should be necessary to round a percent value of 100% ?

thanks!

[ballardw]

Internal representations of decimals. computer precision. Old news. The cumulative is adding many decimal values and there is internal computer storage issues with cumulative error.

Round a value when you need an equal comparison.

If round(x,1) = 100 or similar.

[merryr]

Yeah I know that, but was still surprised since this doesn't seem like it needs to be a computation involving decimals.  It's not the Cumulative, it's the Percent, and it's the Percent for a frequencey for which there is only one value, so the Percent is 100.  I guess this kind of makes sense that SAS still computes it, it's just surprising to me that (966979/96679) * 100  (or however they get it to a percent style value) is not equal to 100.

[Tom]

If you can reproduce the issue with a small set of values then post the example data.

If you can reproduce but the set of values is large (more than a hundred say) then open a ticket with Tech Support and ask them to explain.

[Rick_SAS]

Are you using a WEIGHT variable or a FREQ variable?

Please post the code and sample data.