05-28-2014 08:11 AM
In what context would you like the display to be different to the number, e.g., is it in a data step or proc output?
Is it just for this one number or are there multiple numbers or which the same display format has to be applied?
00014 looks more like a character value than a numeric value based on the leading zeros, are you just dealing with character variables that will only hold numbers?
For a single case in a data step you could just code:
if var="00014" then
05-28-2014 09:24 AM
You can't have a numeric with a non-numeric character = "-", however you could as data _null_; suggested apply a format to the variable. Myself I avoid formats completely, so I would have a display variable:
attrib disp_var format=$20.;
You can retain your numeric and your character separately and use either. Alternatively you could change it in the proc report statement if you really wanted.
05-28-2014 10:09 AM
Myself I avoid formats completely, so I would have a display variable:
That is an interesting statement. You can't "see" numeric variable values without some kind of format, can you?
05-28-2014 10:23 AM
Yes, sorry. Let me clarify. When dealing with a numeric for which I want to display in a different way, then I would have two variables. One being an underlying numeric, one being a character variable. There are numerous reasons why I do this, and its not just me (I hope :smileyshocked. For instance if you look at the CDISC models, quite often there is three variables for the same data, a coded, long, and numeric - e.g.
M, Male, 1
F, Female, 2
05-28-2014 12:11 PM
For the encoding in your example I would use the INFORMATS from the controlled terminology. Assuming the starting point is the character variable SEX. Are you saying you don't use PROC FORMAT or use user defined formats?
05-28-2014 02:22 PM
Nope, haven't used proc format in around 8 years or user defined (oh tell a lie, I occasional use MLF formats for analysis). I do admittedly have date/time format on some variables for readability, and significant digits. If you have your metadata loaded already then I would use that:
From my define list of codes have a panel decodes:
SOURCE CODELIST CODE DECODE...
DB SEX 1 M
DB SEX 2 F
SDTM SEX M Male
SDTM SEX F Female
Then one example of code would be something along the lines of (and this is just an example, am not saying to do it this way):
create table WANT as
select DB.SEX as SEX,
%DECODE(DB.SEX,DB,SEX) as SEXC,
%DECODE(CALCULATED SEXC,SDTM,SEX) as SEXD
from DATABASE.DM DB;
Where the %DECODE is a basic macro:
%macro DECODE (VAR,DOM,DVG);
(select THIS.DECODE from META.DECODES THIS where THIS.SOURCE="&DOM." and THIS.CODELIST="&DVG." and THIS.CODE=&VAR.)
The reason being is trying to separate metadata from the data, i.e. not all DVGs would be formats (such as multi-group lab tests, however a table set up in such a way could use one decode function to cover formats, multi-level decodes. So not a huge difference between the way formats work, although one other small bonus is when using other tools, the above SQL could be ported directly to an outside application which has an SQL parser, with the two tables and it would still work, whereas formats are a SAS specific thing.
Sorry, have started rambling