Learning SAS

[troyandabed]

Maybe a little background first: I was a pure math BS and MA, and now want to get into P&C actuarial work. I'd really like to learn SAS, but the official programming course and the software are both too expensive for me, I just can't afford them.

I don't have much of a background in programming, just some basic Java and Matlab that I had to take for my undergrad degree. Can anyone recommend texts or learning tools for SAS on the cheap? I guess my tilt would be towards things that will help me land a job and work in the P&C field. Thanks.

[IKnewIt]

Pick up SAS on the job like most actuaries working in the field. Put that time towards passing more exams instead.

[emg3000]

I'm currently in the middle of learning SAS myself. After over a year, I'd finally say I'm comfortable with performing basic tasks (meaning I don't have to reference prior code or google basic syntax). Still, it's a never-ending, continuous process. Given time and references, I can solve most any problem. But, the purpose of programming is to be efficient, and I'm always trying to balance variously more skilled ways of completing problems versus doing them in some more hackish, manual way. But I digress...

As for the best way to go about learning, my advice might be a bit dismal:
Unfortunately, I regard textbook learning of any programming language as an uphill battle. This is not to say I don't use "textbooks" or other academic resources/documentation when practicing the craft. But I'd offer that nearly all workable, actionable knowledge I have about a programming language's functioning came from facing of a real programming problem, not from abstract study. With this in mind, unless you are being tasked to perform some function with the SAS, I would think it difficult to learn.

Furthermore, although I like SAS, it can be expensive if outside corporate or academic walls. You'd do just as well fiddling with R, which is free.

As for things to practice, you could try the problems associated with programming competitions. Scour google for a site that offers some introductory tests. These problems are typically meant to be solvable with different programming languages. I believe most of the students who compete do so with C++ or some variant thereof, but there's no reason you couldn't do them with R (or SAS, if you have a personal copy).


Also, if your goal is to learn some kind of data management language, SQL is essential. W3schools.com has a great basic tutorial, but it's by no means the only one.

Now, if you really have your sights set on SAS, and you want an all purpose text, the SAS language reference is free. Here's the concepts section:
http://support.sas.com/documentation...ault/lrcon.pdf. There are other sections you can best find by googling, including one for the macro engine.

Hope this helps...

[troyandabed]

Thanks for the advice. From applying to jobs it seemed that SAS skills were high on the list, but if SQL is used just as much in the field I should probably spend some time on that as well.

[emg3000]

In terms of managing datasets/tables, base SAS steps through records one-by-one, where as SQL tends to use more efficient, if less transparent, algorithms. Which one is better is a debate that depends on the cirucumstances. But fact is, SAS provides compatibility for both anyway. Obviously base SAS supports the SAS way of stepping through table records one-by-one. It also supports SQL by using the SQL procedure. So, with SQL, you kinda can't go wrong. Furthermore, you may find a job that uses SAS. You might also find a job that uses SPSS, or R. But SQL is pretty universal across platforms. SQL in SAS ~ SQL in MS SQL Studio ~ SQL on Oracle ~ SQL on MySQL...

Again, I think it's hard to learn this stuff without a tangible application, but if you're to try it, SQL would be a good start.

[sama]

Originally Posted by troyandabed

Thanks for the advice. From applying to jobs it seemed that SAS skills were high on the list, but if SQL is used just as much in the field I should probably spend some time on that as well.

SAS has a procedure called "proc sql". It essentially allows you to use SQL codes in SAS. I mainly use "proc sql" when I code because I'm too lazy to remember the syntax of all the other procedures. I think learning SQL is a good idea since there are more free resources on the internet and then that knowledge can be recycled back into SAS coding.

[JasonScandopolous]

Originally Posted by sama

SAS has a procedure called "proc sql". It essentially allows you to use SQL codes in SAS. I mainly use "proc sql" when I code because I'm too lazy to remember the syntax of all the other procedures. I think learning SQL is a good idea since there are more free resources on the internet and then that knowledge can be recycled back into SAS coding.

Completely agree. You will need to use row-by-row processing for certain things you want to do, and will find great potential use for the other PROCs that SAS has to offer, but essentially ALL basic data gathering can be done with just SQL. Learning SQL is 95% of the way to being a data gatherer/manipulator. It doesn't get you very far as a predictive modeler, report-producer (not that you should want to be a Statistical guy), etc., though.

[Ajay_Shekhar]

SAS provides SQL & R compatability using PROC SQL & PROC IML respectively.

Proc SQL for data manipulation, and IML for modeling.

As a more economical solution, you could try learning them individually and then integrating them into SAS when you start working on it, which should be a piece of cake really.

[Ron Weasley]

Base SAS certification would mean something on a resume. It can make a candidate that seems on the fence a bit more favorable, but it doesn't carry the same weight as someone who has used SAS on-the-job on a regular basis. Real SAS skills are generally learned in a corporate environment, and the SAS certification program and licensing practices reflect this.

A less expensive way to say "I know SAS" on a resume may be to take a course in a local community college. That would give you access to the language, some level of instruction and experience, and a passing grade would give grounds on a resume to say "I know SAS."

Knowing SQL and/or R is knowing SQL and/or R. Both say something positive. However, even though proc SQL is my preferred way to work with data manipulation in SAS, if someone said "I know SQL well and therefore know SAS because of proc SQL", I would be interested in their SQL skills, not their SAS skills.

[AlexNZ]

I wonder what people think about temporary arrays (i.e. ARRAY with _TEMPORARY_ at the end) in SAS data step. We use it to loop through records in any order we like, particularly to process data when it is stored at different levels (e.g. policy, item, coverage), trying to match by dates (when they don't match exactly), trying to apply restrictions on coverage periods based on information at higher levels, testing of gaps and overlaps of coverages... tasks like these.

Has anyone done similar tasks in SQL? Is this easy to do in SQL?