About ArtC

ArtC · ‎04-06-2018

At just over 2300 miles from Anchorage, those of us coming from AK will probably be the furthest within US travelers. But that distance is nothing compared to those coming from down under. In CA distance is measured in units of time. It seems to me that same principle should apply when flying - hours in coach (half credit if flying business class).

ArtC · ‎04-03-2018

Most attendees wear business casual, although often presenters will step it up just a bit. Remember that convention center presentation rooms tend to be on the COLD side.

ArtC · ‎03-01-2018

One way would be to change the value of the missings to different non printable characters. This version of the CONTROL data set will insert nonprintable values into cells with missing values. because they are different they will not group but will still be blank. You would need to adjust the code if there are more than 30 or so missing values. data have; input variable $ @10 group $1. @13 num; datalines; name 1 drugA 2 drugB D 3 d_drug01 B 4 d_drug02 B 5 d_drug03 B 6 d_drug04 B 7 d_drug05 B 8 d_drug06 B 9 d_drug07 B 10 DrugF C 11 DrugX F 12 Drugy 13 Drugz 14 Drugq 15 Drugr 16 run; data control(keep=fmtname start label); retain fmtname 'numord'; set have(rename=(num=start)); if group=' ' then do; cnt+1; label=byte(4+put(cnt,3.)); end; else label=group; run; proc format cntlin=control; run; proc report data=have spanrows; column num variable; define num / order f=numord1. order=internal style(column)={vjust=c just=c}; define variable / display; run; The BYTE function creates a hex code. Hex codes from 0 - 31 are not printable so will appear as blanks (some nonprintable characters actually print in some fonts). This seems like a hack to me so i am hoping someone else will come up with something more robust.

ArtC · ‎02-27-2018

The SPANROWS option will get you closer, however the missing cells will also merge. proc report data=have spanrows; column num variable; define num / group f=numord. style(column)={vjust=c just=c}; define variable / display; run;

ArtC · ‎02-27-2018

You may want to try using a multilabel format. Note the (multilabel) option on the VALUE statement and the MLF option on the DEFINE statement. Unless you are writing to the LISTING destination, you can also eliminate a number of REPORT options e.g. HEADLINE, HEADSKIP, SKIP, OL Data TBl; INPUT grade $ Model $ Obligo; Cards; a.0 a 10 a.0 b 20 b.1-6 a 30 c.7-10 a 40 d.11 a 50 d.11 b 60 e.12 a 70 e.12 b 80 ; Run; proc format; value $grade (multilabel) 'a.0' = 'Primary' 'b.1-6' = 'Primary' 'c.7-10' = 'Primary' 'd.11' = 'Primary' 'a.0' = 'Secondary' 'b.1-6' = 'Secondary' 'c.7-10' = 'Secondary' 'd.11' = 'Secondary' 'e.12' = 'Secondary'; run; /*libname proclib 'SAS-library';*/ /*options nodate pageno=1 linesize=64 pagesize=60*/ /*fmtsearch=(proclib);*/ proc report data=TBl; column grade=ggroup grade Model Obligo ; define ggroup / group 'Grade Group' f=$grade. mlf; define grade / group 'Grade'; define Model / group 'Model'; define Obligo / analysis sum format=comma10. 'Ob'; /*total after each groupkCat*/ break after grade / /* ol*/ summarize suppress /*skip*/ ; /*global total*/ /*rbreak after / summarize;*/ /*compute after;*/ /*type = 'Total';*/ /*endcomp;*/ run;

ArtC · ‎02-27-2018

Do you want e.12 to appear in the report? I assume so otherwise you could eliminate it with a WHERE.

ArtC · ‎02-27-2018

I am not sure exactly what you mean by 'merged cells'. That term has a specific meaning that to me is not implied by your question., So let me take a guess and see if it gets us closer. Do you mean that you do not want the GROUP variable to not repeat? If so then we can control order and the display of the GROUP variable through the use of a format. The following creates a format that can then be used as a grouping variable without the complicating NUM variable on the COLUMN statement. data have; input variable $ @10 group $1. @13 num; datalines; name 1 drugA 2 drugB D 3 d_drug01 B 4 d_drug02 B 5 d_drug03 B 6 d_drug04 B 7 d_drug05 B 8 d_drug06 B 9 d_drug07 B 10 DrugF C 11 DrugX F 12 run; data control(keep=fmtname start label); retain fmtname 'numord'; set have(rename=(num=start group=label)); run; proc format cntlin=control; run; proc report data=have; column num variable; define num / group f=numord.; define variable / display; run;

ArtC · ‎02-26-2018

Thank you @Tom for touching on the use of the %NRSTR quoting function with CALL EXECUTE - nice explanation. I have found that whether to use the PUT / %INCLUDE vs CALL EXECUTE to build the call to mostly be a personal preference. Some find it easier and others find it more confusing. I would recommend that the reader have a good understanding of both techniques and use the one that seems easiest for them. This paper does not deal with the specifics of CALL EXECUTE and as @Tom indicates there can be some 'subtle' gotchas with its use. If his comment on %NRSTR was not just a reminder, you may want to read http://www2.sas.com/proceedings/sugi22/CODERS/PAPER70.PDF .as a starter for CALL EXECUTE.

ArtC · ‎02-23-2018

Abstract and online materials for this paper prepared for WUSS 2017. Abstract When faced with generating a series of reports, graphs, and charts; we will often use the macro language to simplify the process. Commonly we will write a series of generalized macros, each with the capability of creating a variety of outputs that depend the macro parameter inputs. For large projects, potentially with hundreds of outputs, controlling the macro calls can itself become difficult. The use of control files (metadata) to organize and process when a single macro is to be executed multiple times was discussed by Rosenbloom and Carpenter (2015). But those techniques only partially help us when multiple macros each with its own set of parameters are to be called. This paper discusses a technique that allows you to control the order of macro calls along with each macro's parameter set using a metadata control file. Excerpt from an example in the paper Online Materials View the PDF version of the complete paper here. Sample code and control files are attached as a ZIP file

ArtC · ‎02-23-2018

This is the abstract for a SAS Global Forum paper from 2014. Original title is Before You Get Started: A Macro Language Preview in Three Parts by Arthur L. Carpenter Using the macro language adds a layer of complexity to SAS programming that many programmers are reluctant to tackle. The macro language is not intuitive, and some of its syntax and logic runs counter to similar operations in the DATA step. This makes the transfer of DATA step and PROC step knowledge difficult when first learning the macro language. So why should one make the effort to learn a complex counterintuitive language? Before you start to learn the syntax; where to put the semicolon, and how to use the ampersand and percent sign; you need to have a basic understanding of why you want to learn the language in the first place. It will also help if you know a bit about how the language thinks. This overview provides the background that will enable you to understand the way that the macro language operates. This will allow you to avoid some of the common mistakes made by novice macro language programmers. First things first – before you get started with the learning process, you should understand these basic concepts. This paper covers: Macro language preview: part 1 - What the language is, what it does, and what it can do Macro language preview: part 2 - It is all about the timing; why the macro language comes first Macro language preview: part 3 - Creating macro variables and demystifying their scope View the paper from the SAS Global Forum proceedings (PDF file) Presentation slides are attached as a PDF.

ArtC · ‎01-24-2018

As you finalize your code, be sure to make the name of the array consistent.

ArtC · ‎01-16-2018

Although not immediately obvious (and a continuing source of confusion) there is a difference between INFORMATs (used by the INPUT statement and the INPUT function) and FORMATs (used by the PUT statement and the PUT function). The INVALUE statement in PROC FORMAT creates INFORMATs and you will notice from the previous post by @Kurt_Bremser that the type of the INFORMAT depends on the result (numeric INFORMATS yield a numeric result). FORMATS created by the VALUE statement are numeric if the incoming value is numeric.

ArtC · ‎01-14-2018

@stat_sasNice use of the ODS OUTPUT statement. If more than one variable needs to be dropped a SEPARATED BY phrase could be added to the SQL step which creates &DROP_VARS: select Variable into :drop_vars separated by ' ' from stats Also this will eliminate any variable with constant value, other than all missing, not just all 1's.

ArtC · ‎01-12-2018

I am not sure that i understand your question, but i can see in your DATA step that you call your FCMP function. That function calls your macro and that macro (M_SeleccionaCalle), which in turn executes a number of data reads (potentially lots of I/O). All of this I/O will happen for every observation in the original incoming data set (PT_V_NEW_SALES_LOTE_ORDER_TEMP1). Without understanding your intent/objective/logic, my first thought is to try to minimize all of this I/O. Can you restructure so that the macro (M_SeleccionaCalle) is called only once instead of N times?

ArtC · ‎01-11-2018

@Ksharp cool code, but would the following be a simpler approach? data want2; set data_1; random_no=1+floor(id_no*rand('uniform')); run; Do we need to be sure that the random identifiers are unique?

Online Status	Offline
Date Last Visited	‎06-20-2021 07:11 PM