topic Re: How does SAS input an integer by format like x.y in SAS Programming

How does SAS input an integer by format like x.y

whymath — Fri, 25 Sep 2020 01:16:43 GMT

My friend asked me a question:

data _null_;
  test = input(12,4.2);
  put test = ;
run;

The result is 0.12, why?

I do some test on this and I guess SAS read the string '12' from right to left to determin the position of decimal point. When I test test = input(123,4.2);, it gives me 1.23 which support my assumption. But when I test test = input(12.0,4.2);, it returns 12. So I do more test on this and have another guess: SAS have different policy on inputing decimal and integer.

Am I right? Or you have other idea?

Re: How does SAS input an integer by format like x.y

ChrisNZ — Fri, 25 Sep 2020 02:30:08 GMT

When you use informat 4.2 you tell SAS that you want 2 decimals.

If SAS finds a decimal dot, it uses it. If not, it considers the last 2 digits to be the 2 decimal values.

Re: How does SAS input an integer by format like x.y

whymath — Fri, 25 Sep 2020 06:22:18 GMT

Yes, someone gives me the solution.

w.d Informat
Reads standard numeric data.
...
Syntax
w.d
Syntax Description
w specifies the width of the input field. Range 1–32
d specifies the power of 10 by which to divide the value. If the data contains decimal points, thedvalue is ignored. This argument is optional. Range 0–31

And here is the link: https://documentation.sas.com/?docsetId=leforinforref&docsetTarget=n14sqpf1cubqknn1vmkzkp1oph87.htm&docsetVersion=9.4&locale=en

Re: How does SAS input an integer by format like x.y

ballardw — Fri, 25 Sep 2020 15:13:14 GMT

Some ancient history may shed some light on this.

Once upon a time there were things called punchcards, actual physical cards that holes were punched in specific that early computers could read data. These were used for many things that had to share information between computers that were not connected and often incompatible. The cards and coding schemes were create long before computers so they became a standard of sharing data.

These cards only held 80 columns or positions. So to reduce how much had to be physically punched on the cards rules for reading would imply that a specific column was an implied decimal. So only 1234 had to be punched but the using program "knew" that there should be a decimal between the 2 and 3 and treat the value as 12.34.
The cards could often hold more values when there was no actual decimal. You might have a card that held something like:

1234599976323448504827634950560679583772722495506679

but a computer could read that as

12.34 599.976 .323448 504.82 76.3495 0.5606 7958.37 727.22 4955.06679

So the W.D and other formats when a decimal is used have this old behavior. It continued for things like text based files because transmission speeds or file sizes presented some challenges for a long time and the space saving was still useful. Or the old program still worked and the "if it ain't broke don't fix it" rule applied.

So the input function and input statement behavior maintains consistency with old behavior. Moral of the story: don't read integers with a decimal informat (other than 0 such as 5.0).