Actuarial Outpost
 
Go Back   Actuarial Outpost > Actuarial Discussion Forum > Software & Technology
FlashChat Actuarial Discussion Preliminary Exams CAS/SOA Exams Cyberchat Around the World Suggestions

DW Simpson International Actuarial Jobs
Canada  Asia  Australia  Bermuda  Latin America  Europe


Reply
 
Thread Tools Display Modes
  #61  
Old 05-24-2011, 04:27 PM
ADoubleDot's Avatar
ADoubleDot ADoubleDot is offline
Member
Non-Actuary
 
Join Date: Nov 2007
Location: Slightly Dusty South
Studying for the rest of my life
Posts: 37,034
Default

Code:
proc sort data = table1;
	by pol iteration;
run;

data table2;
	set table1;
	by pol iteration;
	if last.pol then output;
run;
__________________
ADoubleDot: I'm an actuarial icon.

**** Juan.
Reply With Quote
  #62  
Old 05-24-2011, 04:50 PM
BassFreq's Avatar
BassFreq BassFreq is offline
Member
CAS
 
Join Date: Jun 2003
Location: Chicago
Studying for all eternity
Favorite beer: Duff
Posts: 1,668
Blog Entries: 2
Default

Adoubledot's got the right answer. Another way is

proc sql;
create table table2 as
select *
from table 1
group by pol
having iteration=max(iteration);
quit;

but with 1M+ rows, this will be really inefficient.
__________________
If at first you don't succeed, you have one data point.
Res ipsa loquitur, sed quid in infernos dicet?
Reply With Quote
  #63  
Old 06-14-2011, 02:09 PM
Gareth Keenan's Avatar
Gareth Keenan Gareth Keenan is offline
Member
CAS
 
Join Date: Feb 2006
Location: by a pretty big bay
Studying for #9
Favorite beer: butter
Posts: 1,271
Default Where SAS starts executing a Where in a data step

Say I have a source body of data.



And I have a SAS query, where I am interested in all records that have "Lunch" as the meal, but I'm only interested in Lunches that are at or equal to Indicator 4, is there a way to do this in SAS and minimize CPU cycles or whatever?

Specifically, I want my oracle search to not even worry about lunches, until it gets to an indicator with a value of 4 then to worry about lunches. I also know that my source data is sorted by indicator, so that the values of the indicator are from smallest to largest.

Is there a way to do this? In the very large data set I am looking at so if I could get the query to start only at the precise indicator, the query would take less time to execute.

I have this statement executing in an elementary data step, but if there is a more efficient way to do this, I would love to hear it. Thanks!

Gareth Keenan
Reply With Quote
  #64  
Old 06-14-2011, 02:17 PM
ADoubleDot's Avatar
ADoubleDot ADoubleDot is offline
Member
Non-Actuary
 
Join Date: Nov 2007
Location: Slightly Dusty South
Studying for the rest of my life
Posts: 37,034
Default

Try creating indexes on your data. The index tells SAS where the unique values of the data exist on the table. This means that it only needs to search the correct partition.

Code:
proc datasets library = library_name;
	modify table_name;
	index create indicator;
	index create lunch;
run;

data table_name2;
	set table_name;
	where indicator >= 4 AND meal = 'lunch';
run;
Reply With Quote
  #65  
Old 06-18-2011, 06:20 PM
ZeroUrashima ZeroUrashima is offline
Member
 
Join Date: Apr 2010
Posts: 30
Default

Currently reading Learning SAS by Example: A Programmer's Guide and doing the questions...

I am doing Chapter 21's Question 10 and I wrote the thing that way:
Code:
data SALES INVENTORY;
input @16 Type 1. @;

if Type=1 then do;
	input @1 Date mmddyy10.
		  @12 Amount 4.;
	output Sales;
end;

else if Type=2 then do;
	input @1 PartNumber $6.
		  @8 Quantity 3.;
	output Inventory;
end;

drop type;

datalines;
10/21/2005  1001
11/15/2005  2001
A13688 250     2
B11112 300     2
01/03/2005 50001
A88778 19      2
;
run;

title "Listing of SALES";
proc print data=Sales;
run;

title "Listing of INVENTORY";
proc print data=inventory;
run;
Question asks to create two SAS data sets in one DATA Step and the result they want only have the columns that have non-missing Data.

Currently, Sales have a column of PartNumber and Quantity and Inventory has a column of Date and Amount. I suppose I could use var in the procedure to get rid of those but I don't think that's what the question wants since they are still in the Data Set but we just don't see them. Anyone can tell me if there is a way to create 2 Data Sets in one Data Step and the columns with missing values are not there?
Reply With Quote
  #66  
Old 06-27-2011, 11:04 PM
Olrich Olrich is offline
Member
 
Join Date: Jan 2008
Posts: 144
Default

I'm sure a lot of people are already aware of them, but I just recently learned about hash tables (as an alternative to sort and merge for joining tables together) and they are making a big difference in the run time of a lot of stuff I use.

They aren't perfect for every situation, but anytime you're merging a relatively small table to a very large dataset (pulling mortality rates into an inforce file or whatever), it dramatically cuts runtime.

The following is a good introduction, there's some other documentation floating around how to some fancier things with hash tables.

http://www2.sas.com/proceedings/forum2007/039-2007.pdf
Reply With Quote
  #67  
Old 11-15-2011, 10:14 AM
Gareth Keenan's Avatar
Gareth Keenan Gareth Keenan is offline
Member
CAS
 
Join Date: Feb 2006
Location: by a pretty big bay
Studying for #9
Favorite beer: butter
Posts: 1,271
Default Sum of a character field?

Is there a way in SAS to take the sum of a character field?

Lets say I have a field called "field" in a table in my work library called "table". I've visually confirmed by looking up distinct values that for all of my rows in "field" are values that are numbers.

Is there a way in Sas I could take the some of "field"? Normally, If I wanted to quickly spot check something, I might just use PROC Means, and review the output, but it looks to me like PROC means does not work on character fields.

suggestions?

Thanks,

Gareth Keenan
Reply With Quote
  #68  
Old 11-15-2011, 10:22 AM
BassFreq's Avatar
BassFreq BassFreq is offline
Member
CAS
 
Join Date: Jun 2003
Location: Chicago
Studying for all eternity
Favorite beer: Duff
Posts: 1,668
Blog Entries: 2
Default

This would do it...
Code:
 
data table;
input field $2.;
datalines;
10
21
68
;
run;
proc sql;select sum(input(field,best32.)) from table;quit;
...but typically I would just convert the character field into numeric using the input funtion and then you could use proc means on that.
__________________
If at first you don't succeed, you have one data point.
Res ipsa loquitur, sed quid in infernos dicet?
Reply With Quote
  #69  
Old 11-15-2011, 10:23 AM
BassFreq's Avatar
BassFreq BassFreq is offline
Member
CAS
 
Join Date: Jun 2003
Location: Chicago
Studying for all eternity
Favorite beer: Duff
Posts: 1,668
Blog Entries: 2
Default

Actually, not convert the character field, but rather, create a numeric version of it.
__________________
If at first you don't succeed, you have one data point.
Res ipsa loquitur, sed quid in infernos dicet?
Reply With Quote
  #70  
Old 11-29-2011, 02:21 PM
Gareth Keenan's Avatar
Gareth Keenan Gareth Keenan is offline
Member
CAS
 
Join Date: Feb 2006
Location: by a pretty big bay
Studying for #9
Favorite beer: butter
Posts: 1,271
Default if vs else if vs else

Is there a logic for when to use if vs else if vs else ?

I'm creating a new variable in a data step based on another variable I all ready have. I feel like you should end with else, which is like saying, "if none of the above criteria matched, just do whatever the else tells you to do."

I also imagine, you have to begin with an if, otherwise beginning with an else if doesn't make logical sense. It probably doesn't make syntax sense, but if I understood this situation, I would not be posting here for help.

when after your first "if" do you use "if" or "if else" or "else"

Cheers,

Gareth Keenan
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT -4. The time now is 08:18 PM.


Powered by vBulletin®
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
*PLEASE NOTE: Posts are not checked for accuracy, and do not
represent the views of the Actuarial Outpost or its sponsors.
Page generated in 0.26465 seconds with 10 queries