Computer-implemented systems and methods for defining events

Abstract

Computer-implemented systems and methods to process time-series data. As an example, a system and method can use a first data store to store time series data, and a second data store to store definitions of events. A dummy variable is generated when data from an event's definition is applied to time series data.

Description

TECHNICAL FIELD

The technology described in this patent document relates generally to the field of computer data modeling. More specifically, systems and methods are provided for modeling time-stamped data.

BACKGROUND

The effects of events on time-stamped data may be an important factor in creating an accurate computer model of the data, for example, to improve the predictive ability of the model. Examples of events that may affect time-stamped data include advertising campaigns, retail promotions, strikes, natural disasters, policy changes, a data recording error, etc.

The characteristics of an event may define the effect that an occurrence has on the time-stamped data and the duration of the occurrence. An event may include a single occurrence (e.g., a worker strike), multiple occurrences (e.g., a holiday), or irregular occurrences (e.g., new store openings.) Further, an occurrence may be on a fixed date or a relative date (e.g., an event may begin two weeks before Christmas.) In addition, an event may be a combination of occurrences (e.g., a retail sale that occurs over a holiday.) Thus, modeling events so that they increase the accuracy of a time series model can often be complicated.

SUMMARY

In accordance with the teachings provided herein, systems and methods for operation upon data processing devices are provided concerning the processing of time-series data. As an example, a system and method can use a first data store to store time series data, and a second data store to store definitions of events. A dummy variable is generated when data from an event's definition is applied to time series data.

As another example, a system and method can use a first data store to store time series data, and a second data store to store definitions of events. A dummy variable is generated when data from an event's definition is applied to time series data. The first and second data stores comprise separate data stores for storing their respective time series data and event definitions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting software and computer components utilized in generating dummy variables.

FIG. 2 is a block diagram depicting multiple data stores being used in a process for generating dummy variables.

FIG. 3 is a block diagram depicting different relationships that may exist between event data and time series data.

FIG. 4 depicts an example graphical user interface (GUI) for viewing a time series event.

FIG. 5 depicts another example of a GUI for viewing a time series event in which the component parts of the displayed combination event are displayed.

FIG. 6 depicts another example of a GUI for viewing a time series event in which a step-type event is displayed.

FIG. 7 depicts an example GUI for defining properties of a time series event.

FIG. 8 depicts an example dialog window that may be used to select an event type.

FIG. 9 is a block diagram illustrating definition of an event.

FIG. 10 is a block diagram wherein an event is be defined with parameters.

FIG. 11 is a block diagram wherein example parameters are shown that can be used to describe a timing value or values.

FIG. 12 depicts a table for use in calculating beginning and ending observations for events.

FIGS. 13 and 14 depict a table of different event types for infinite durations.

FIGS. 15-17 depict a table of different event types for finite durations.

FIG. 18 is a block diagram depicting an example of using a graphical user interface (GUI) for defining events.

FIG. 19 is a block diagram depicting an example of using predefined events.

FIG. 20 is a block diagram depicting an example of various methods by which a user may input event information.

FIG. 21 shows an example of PROC HPFEVENTS wherein the program is used to create events and dummies.

FIG. 22 depicts output of an event definition data set showing variables related to event definitions.

FIG. 23 depicts output of interpretation of an event into an event dummy data set.

FIG. 24 depicts code containing a set of HPFEVENTS statements.

FIG. 25 illustrates the data being saved in a condensed format.

FIG. 26 illustrates different statements and options that can be used with the HPFEVENTS procedure.

FIG. 27 depicts a table showing an example of holiday date keywords and definitions that can be used in a timing value list and their definitions.

FIG. 28 depicts a table showing an example of seasonal date keywords that can be used in a timing value list and their definitions.

FIGS. 29 and 30 depict a table showing default duration values and how the basic event shape depends on the duration value.

FIG. 31 depicts a table that explains how a RULE is interpreted when the value for an observation is defined by multiple timing values.

FIG. 32 depicts a table describing how to construct a predefined event keyword.

FIG. 33 depicts a table that provides a description of how date and observation numbers are encoded into AO and LS type predefined events.

FIG. 34 depicts a table describing predefined event group keywords.

FIG. 35 depicts code that defines a ramp for Christmas for certain observations.

FIG. 36 depicts output showing multiple timing values versus multiple events.

FIG. 37 depicts output for examining data sets.

FIG. 38 depicts an event output data set which is condensed and has the duplicate events eliminated.

FIG. 39 is a graph for examining amount of sales data and dummy data over a period of time.

FIG. 40 depicts code to illustrate how the HPFEVENTS procedure can be used to include events in the automatic forecasting of time series data.

FIG. 41 depicts results of a model selection process.

FIG. 42 depicts code for illustrating the use of predefined event keywords directly in other procedures.

FIG. 43 depicts output PROC HPFDIAGNOSE that shows that a model was selected that included the level shift occurring at October 1980.

FIGS. 44 and 45 depict code to create dummies.

FIG. 46 depicts output from code configured to create dummies.

FIG. 47 depicts code that is to produce a plot of finite and extended dummy variables.

FIG. 48 depicts a plot of finite and extended dummy variables.

DETAILED DESCRIPTION

FIG. 1 depicts at 30 a system for creating and managing events associated with one or more time series for the purpose of analysis. The system 30 can create events, read events from an event data store 40, and write events to an event data store 40. The system 30 can also create dummy variable data 60 based on those events if date information is provided.

An event is used to model any incident that disrupts the normal flow of the process that generated the time series. The characteristics of an event define the effect that an occurrence has on the time-stamped data and the duration of the occurrence.

When an event from an event data store 40 is applied to a time series, a dummy variable 60 is generated via a computer-implemented process 50 so that it may be used to analyze the impact of the event on the time series. The system 30 defines an event using a dummy variable that is independent of the time series. As an example of this independence, if the starting and ending dates of the time series change, observations are added or removed, or if the frequency of the time series changes, then dummy variable 60 is automatically generated based upon the change. The generated dummy variable(s) 60 can be saved if needed and used in analyzing a time series through a data modeling program 70, such as a time series analysis program that uses the time-stamped time series data and the generated dummy variable to generate a mathematical model.

The system 30 applies events such as Easter to any time series, applies periodic events such as every Monday to any time series, applies effects such as ramps and exponential growth or decay to any time series, and to appropriately adjust the definition when the time series is altered.

As shown in FIG. 2, one or more events can be stored in an event data store 40 that is separate from the data store 42 that stores the time series data. Moreover a time series data store 42 can store one or more time series. It should be understood that multiple event data stores can be used to store multiple events, and that multiple time series data stores can be used to store multiple time series. As shown in FIG. 3, an event can be applied to one or more time series because an event exists separate from any time series. Still further multiple events can be applied to the same time series.

FIGS. 4-8 illustrate an example event and a set of characteristics that the event in the example has. FIG. 4 depicts an example GUI 90 for viewing a time series event. A list of previously created events 91 along with their corresponding event types 92 are displayed in a first region 93 of the GUI 90. In addition, a graphical display of a selected event is displayed in a second region 94 of the GUI 90. Also included in the GUI 90 are a plurality of user input regions 95 (e.g., graphical buttons) for causing user input regions to open for managing stored events, such as creating a new event, combining two or more events, modifying a stored event, and deleting a stored event.

Selecting one of the stored events 91 listed in the first GUI region 93 causes the event to be displayed in the second GUI region 94. In the illustrated example, the event “Columbus Day” has been selected. A graph of the statistical properties 96 for the example “Columbus Day” event are displayed in the second GUI region 94. The example graph 96 shows the effect of the “Columbus Day” event on sales (y-axis) over a period of time (x-axis). Also displayed in the second GUI region 98 is a vertical reference 98 that indicates the present point in time. The portions of the event graph 96 that are displayed to the left of the vertical reference 98 represent the effect of the event on recorded time series data, and the portions of the event graph 96 to the right of the vertical reference are a time series model that is generated based on the recorded time series data and the defined event. The time series model displayed to the right of the vertical reference 98 provides a prediction of the effect of the event on future data.

The example “Columbus Day” event is a combination event, meaning that its statistical properties are defined from a combination of the statistical properties of two or more other stored events. In this example, the combination event is made up of a step-type event 100 and a decay-type event 102. For example, over the duration of the illustrated “Columbus Day” event, a new store may be opening, followed some period later by a sale. The result of the new store opening is a stepped increase in sales, represented by the step-type event 100, and the result of the sale is a temporary sharp increase in sales, represented by the decay-type event 102.

FIG. 5 depicts another example of a GUI 103 for viewing a time series event in which the component parts 104, 106 of the displayed combination event are displayed. As illustrated, the individual statistical properties 104, 106 that make up a combination event may be displayed in a region of the GUI 103 along with the combination event by selecting a Show Component Events user input region 107 of the GUI 103. In the illustrated example, a step-type event 104 and a decay-type event 106 are the displayed component parts of the example combination-type “Columbus Day” event.

FIG. 6 depicts another example of a GUI 110 for viewing a time series event in which a step-type event is displayed. In this example, a user has selected a step-type event 112, entitled “Buy 1 Get 1 Free,” from the first region 114 of the GUI 110. A graph 116 of the example step-type event 112 is displayed in the second GUI region 118. As illustrated, the step-type event causes a stepped increase in the time series data. Examples of events that may cause a step-type event are opening a new store, an extended sale, etc. In the illustrated example, the duration of the step-type event 116 extends beyond the displayed time period. However, step-type events may have a limited duration (e.g., in the case of an extended sale), or may have an indefinite duration (e.g., in the case of a new store).

FIG. 7 depicts an example GUI 120 for defining properties of a time series event. This GUI 120 may, for example, be provided by selecting the “New” user input 95 shown in FIG. 4. The GUI 120 includes user input regions 122, 124, 126 for naming the event, selecting an event type, and entering a description of the event. The GUI 120 also includes an event selection region having an Occurrence tab 127 and an Associated Series Tab 128. The Occurrence tab 127 of the event selection region may be used for defining when the event occurs and for defining the duration and recurrence of the event. The Associated Series tab 128 of the event selection region may be used for associating one or more time series 132 with the event. In addition, a display region 130 is provided for displaying a graph of the event 131 along with the associated time series data 132.

In the illustrated example, a time series event 131 having three occurrences (1, 2 and 3) is displayed in the display region 130 along with a graph of the associated time series data 132. The example event 131 is a pulse-type event having occurrences on three days, October 24, October 28 and November 4. The event 131 may, for example, have been defined by examining the graph 132 of the time series data and noting the pulse-type increases in the data and recognizing that the data spikes correspond with some particular event. For instance, a one day sale may have occurred on each of these three days, resulting in the temporary pulse-type spikes in the time series data 132. If the recurrence of the event is know (e.g., the sale will continue one a week for several months), then the event 131, which is defined with reference to the stored time series data, may be incorporated into a time series model of the data in order to predict how the event will effect future data. For instance, in the illustrated example the time series model, which is displayed to the right of the vertical reference 133, may show another pulse-type spike in the data if the event is scheduled to reoccur.

In one example, events may be added and/or modified using the display region 130 of the GUI 120. For instance, the duration of an event may be modified by clicking and dragging an edge of an event on the graph 131. A new event may be added to the graph 131, for example by right-clicking on a portion of the graph 131 or by some other suitable means.

FIG. 8 depicts an example dialog window 140 that may be used to select an event type. The event selection window 140 may, for example, be provided by selecting “Edit” in the user input region 124 shown in FIG. 7. The event selection window 140 includes user input regions 141-144 for selecting one of a plurality of predefined event types. Example predefined event types that may be selected include a pulse-type event 141 indicating a temporary spike in the time series data, a level shift event 142 indicating a sharp increase in the time series data, a ramp-type event 143 indicating a gradual increase in the time series data, and a decay-type event 144 indicating a sharp increase in the time series data followed by a gradual decrease. In addition, the event selection window 140 includes a user input region 145 for entering a user defined event type. For example, selecting the user defined event type region 145 may provide another user input region in which a user may insert software code to define an event type.

FIG. 9 illustrates that an event 150 can be defined via a definition process 152 by creating an association 154 between the event 150 and a set of parameters 156. For example and as shown at 158 on FIG. 10, an event 150 can be defined with such parameters 156 as a reference name, a date or dates associated with the event, and other parameters. A reference name is an event's variable name. After the user defines an event 150, the reference name can be used within a data analysis program, such as being used in the grammar of a SAS program wherever appropriate. This provides a user with the capability to customize the SAS system to unique user needs. Predefined event names can also be made available that describe common events such as holidays.

One or more dates can be associated with an event. As an illustration, an event may include a single occurrence (e.g., a worker strike), multiple occurrences (e.g., a holiday), or irregular occurrences (e.g., new store openings). Further, an occurrence may be on a fixed date or a relative date (e.g., an event may begin two weeks before Christmas). In addition, an event may be a combination of occurrences (e.g., a retail sale that occurs over a holiday).

Class parameters can be used to specify whether an event is a simple, combination or complex, or a predefined type of event. Events can be simple (defined only by parameters), combination (a combination of other events), complex (a group of events that must be fit into the model as a unit), or predefined (an event which will be custom made based on the times series).

A keyname parameter specifies date keywords (SIMPLE EVENT) or a predefined EVENT variable name (PREDEFINED EVENT), or an event name (COMBINATION event or COMPLEX event). This allows for compact storage of the different classes of events in a single data set.

An event occurs around a timing value or values. Type, value, shift, pulse, duration, slope, and temporary change (e.g., tcparm) parameters describe the event around each timing value. A timing value could be considered as the “center of mass” of the event. Timing values can be specified as observation numbers, date values (e.g., SAS Date values), date-time values (e.g., SAS Datetime values), date keywords (e.g., SAS Date Keywords), or a do-list of observation numbers, a do-list of dates or a do-list of datetimes. This provides flexibility in allowing the user to specify timing values in so many different ways.

FIG. 11 depicts at 160 example parameters that can be used to describe a timing value or values. A type parameter specifies the type of the event. This is the basic shape of the event. As an illustration, shapes could be point, level shift, ramp, temporary ramp, temporary change, linear, quadratic, cubic, inverse and logarithmic.

A value parameter controls the amplitude of the event. For events of finite duration in which timing values do not overlap, the value is the maximum amplitude.

A shift parameter shifts the event to after (positive) or before (negative) the timing value. The shift is the number multiplied by the pulse interval.

A pulse parameter is an interval that defines the units for the duration and shift values.

A duration parameter represents the number of durations before and after the timing value. The duration values are used in conjunction with the pulse values. The default pulse value is one observation. Duration and pulse parameters guarantee that a continuous effect can be maintained over a fixed time interval which adapts to time series of different frequencies.

A slope parameter (for before and after the timing value) determines what type of curve is involved. For example for type=ramp, type=rampramp, and type=tc, the slope parameter determines whether the curve is growth or decay before and after the timing value.

A temporary change parameter (e.g., tcparm) is for an event of type=tc (i.e., temporary change) which determines the rate of decay or growth.

A rule can be specified when combining events (combination event) or when timing values of an event overlap. The values of the event can be added, or chosen by maximum, minimum, minimum non-zero, or minimum magnitude.

A period parameter represents the frequency interval at which the event should be repeated.

Interpretation of events into dummy variables is based on the event definition, the ID statement, and the time ID values of the time series.

Timing values for an event can be defined in many different ways, such as through a formula. The tables in FIGS. 12-17 illustrate examples of formulas. In the formulas, t, is the observation specified by the ith timing value in the timing value list, VALUE=ν, TCPARM=φ, AFTER=(DURATION=n SLOPE=s_a), BEFORE=(DURATION=m SLOPE=s_b), and PULSE=interval.

The table in FIG. 12 shows how to calculate t_b and t_c which are based on the DURATION=values. The terms t_b and t_c are the beginning and ending observations of the event definition. (For TYPE=RAMP, the ramp persists past the top of the ramp.) Note that undefined values are set to zero after all timing values have been evaluated.

FIGS. 13-14 depict a table of different event types for infinite durations (m=all and n=all). In the figures, ξ_it is the dummy function value for the ith timing value at observation t. Example event types in this table with associated definitions include a point event type, level event type, ramp event type, temporary ramp (tr) event type, temporary change (tc) event type, linear trend event type, quadratic trend event type, and cubic trend event type.

FIGS. 15-17 depict a table of different event types for finite durations (e.g., for finite m, n). Example event types in this table with associated definitions include a point event type, level event type, ramp event type, temporary ramp (tr) event type, temporary change (tc) event type, linear trend event type, quadratic trend event type, and cubic trend event type.

FIGS. 18-20 illustrate several of the mechanisms by which formulae and/or parameters can be associated with SAS events. FIG. 18 depicts an example of using a graphical user interface (GUI) for defining events. At process block 200, a user interacts with the GUI to define properties of an event and to associate the event with time-stamped data. The properties of the event defined using the GUI may include one or more statistical properties that indicate how the event statistically affects the time-stamped data. An example of such a GUI for defining events is disclosed in the commonly assigned patent application entitled “Systems And Methods For Handling Time-Stamped Data” (Ser. No. 11/124,920 filed May 9, 2005), which is incorporated herein by reference in its entirety.

After the user has defined one or more events using a GUI, process block 202 stores the event definitions and generates dummy variables. At process block 210, the user requests that a time series be modeled via the GUI. Process block 212 identifies the model which includes events. The model information is then stored for subsequent use by process block 222. Process block 214 provides process block 212 with the dummy variables that fit the time series that had been requested to be modeled at process block 210.

At process block 220, the user requests a forecast via the GUI. In response to the request, process block 222 fits the model and forecasts the time series using the model information. Process block 224 provides process block 222 with the dummy variables based upon what events are applicable for the situation at hand. This can be based upon predefined events as well as user predefined events.

At process block 230, the time series is altered. The altering can be due to many reasons, such as the starting and ending dates of the time series have changed, observations have been added or removed, or the frequency of the time series has changed. At process block 230, when the user requests via the GUI a forecast of the altered time series using the previous model, process block 242 fits the model and forecasts the time series using the previous model information as well as the new time series. Process block 244 automatically generates the dummy variable data based upon the previous definition and the new time series. Process block 244 provides this to process block 242 so that process block 242 can refit the model and generate a forecast of the new time series.

Another way to specify events is shown in FIG. 19 which depicts an example of using predefined events. At process block 300, a user requests via a GUI that one or more predefined events or outliers be included in a model. At process block 310, the user requests via the GUI that a time series be modeled. To accomplish this, process block 312 identifies the model which includes the events. The model information is stored for subsequent use by process block 322. Process block 314 provides process block 312 with dummy variables that are generated based upon predefined events (including any outliers).

At process block 320, the user requests that a forecast be generated. Process block 322 fits the model and forecasts the time series using the model information identified by process block 312. Process block 324 provides process block 322 with the dummy variables that are generated based upon the predefined events.

It should be understood that similar to the other process flows described herein, the steps and the order of the steps of the process flows described in FIGS. 18 and 19 may be altered, modified, removed, and/or augmented and still achieve the desired outcome. As an illustration, FIG. 20 depicts additional methods by which a user may input event information. At process block 400, a user has event information contained in a calendar application, such as Microsoft Outlook®. At process block 410, the user builds a data set using event information imported from the calendar application. Process block 412 stores the event definitions and provides prototype dummy variables. Process block 414 identifies the model which includes events. The model information is stored for subsequent use by process block 418. Process block 414 interacts with process block 416 so that it may receive dummy variables that have been generated by process block 416 based upon predefined events and user-defined events.

Process block 418 fits the model and forecasts the time series using the model information stored by process block 414. Process block 418 interacts with process block 420 so that it may receive dummy variables that have been generated by process block 420 based upon predefined events and user-defined events.

While examples have been used to disclose the invention, including the best mode, and also to enable any person skilled in the art to make and use the invention, the patentable scope of the invention is defined by claims, and may include other examples that occur to those skilled in the art. Accordingly the examples disclosed herein are to be considered non-limiting. As an illustration of the wide scope of the systems and methods disclosed herein, a software program PROC HPFDIAGNOSE can be configured to provide a comprehensive set of tools for automated univariate time series model identification, a software program PROC HPFEVENTS can be configured to generate event definitions and dummies, and a software program PROC HPFENGINE can be configured to provide an automatic way to generate forecasts for many time series or transactional data in one step. These programs can perform the functions as indicated by their respective names in the blocks of FIGS. 18-20.

More specifically with respect to the HPFDIAGNOSE program, time series data can have outliers, structural changes, and calendar effects. In the past, finding a good model for time series data usually required experience and expertise in time series analysis. The HPFDIAGNOSE procedure automatically diagnoses the statistical characteristics of time series and identifies appropriate models. As an example, the models that HPFDIAGNOSE can consider for each time series could include ARIMAX, Exponential Smoothing, and Unobserved Components models. Log transformation and stationarity tests are automatically performed. The ARIMAX model diagnostics find the AR and MA orders, detect outliers, and select the best input variables. The Unobserved Components Model diagnostics find the best components and select the best input variables. The HPFDIAGNOSE program can be configured to provide the following functionality:

• • intermittency (or interrupted series) test
  • functional transformation test
  • simple differencing and seasonal differencing tests
  • tentative simple ARMA order identification
  • tentative seasonal ARMA order identification
  • outlier detection
  • significance test of events (indicator variables)
  • transfer function identification
    • intermittency test
    • functional transformation for each regressor
    • simple differencing order and seasonal differencing order for each regressor
    • time delay for each regressor
    • simple numerator and denominator polynomial orders for each regressor
  • intermittent demand model (automatic selection)
  • exponential smoothing model (automatic selection)
  • unobserved components model (automatic selection)

The HPFENGINE procedure provides an automatic way to generate forecasts for many time series or transactional data in one step. The procedure can automatically choose the best forecast model from a user-defined model list. Specifications for the candidate forecast models are independent of any data series and can be generated by the user or chosen from a default set. Supported model families include: Smoothing; Intermittent Demand; Unobserved Component; and ARIMA. The HPFENGINE and HPFDIAGNOSE programs are discussed in U.S. Provisional Patent Application 60/679,093 filed May 9, 2005 entitled “Computer-Implemented Forecasting Systems And Methods,” the entire document (e.g., specification, drawings, etc.) of which is herein expressly incorporated by reference.

The HPFEVENTS program generates dummies that are automatically extended, shortened, or changed as observations are added and deleted from a time series. Thus, a single EVENT definition can be used for several time series or for different spans of the same series. PROC HPFEVENTS can be used to define dummies that function equally well for time series of various intervals, for instance weekly or monthly data. The same EVENT definition can model daily data or weekly totals. EVENT definitions can be stored in a data set. EVENT definitions can later be changed, new EVENTS added, or additional dummies generated from an existing data set.

EVENT definitions stored in a data set can be passed directly to PROC HPFENGINE and PROC HPFDIAGNOSE. SAS predefined EVENT definitions can be accessed directly from PROC HPFENGINE and PROC HPFDIAGNOSE. PROC HPFEVENTS can generate a data set that can be used in other procedures such as PROC REG which module is available from the SAS Institute Inc. located in Cary, N.C.

PROC HPFEVENTS recognizes predefined variables and dates. Thus, events involving holidays such as Easter and Thanksgiving can be modeled easily, even though the dates of the events change from year to year. It provides results in output data sets that may be interpreted in other SAS procedures.

FIG. 21 provides an example of PROC HPFEVENTS wherein the program is used to create events (e.g., Labor Day, Summer, etc.) and dummies and output the event definitions to a data set named EVDSOUT1 (see FIG. 21) and dummies to a data set named EVDUMOUT1 (see FIG. 21). With reference to the code of FIG. 21, line 500 identifies that PROC HPFEVENTS is to be used. The “data” term names the SAS data set containing the variables used in the VAR line 502 and ID line 504. The VAR statement 502 is used with PROC HPFEVENTS to copy input variables to the output dummy data set. The ID statement 504 names a numeric variable (e.g., “date” in this example) that identifies observations in the input and output data sets. The “air” variable (which represents airline sales data) is retrieved from the sashelp.air dataset and whose values are shown at various date values in column 614 in FIG. 23. As an illustration, the “air” variable value for observation #9 is the value 136 for the date value of September 1949. As defined by the ID statement 504, the date values have an interval of every month with an end date of Dec. 31, 1952. This is illustrated in FIG. 23 within the date column 612.

With reference to FIG. 21, EVENTDEF statements appear at lines 506, 508, 510, 512, 514, 516, 518, and 520. An EVENTDEF statement is used to define an event. Although an event occurs at one or more time values, the event definition is independent of the time ID; that is, the event is a function that operates on a time ID variable.

For example, a labor day event is created via the EVENTDEF statement 506 for the term “LABORDAY.” PROC HPFEVENTS recognizes that “LABOR” is a date keyword. As shown in the labor day column 616 of FIG. 23, when PROC HPFEVENTS creates a dummy variable for this event, a timing value is generated for each Labor Day that falls in the span of the time, series. Each observation that matches the date of Labor Day has a value of 2. As an illustration, observation #9 in FIG. 23 shows a value of 2 for the date September 1949.

With reference to the event “SUMMER” defined at statement 508, the do-list, ‘01Jun1900’D to ‘01Jun2005’D by year, generates 106 timing values on the first of June for each year from 1900 to 2005. The pulse for each timing value will last for three observations, the observation matching June 1st and the two following. For monthly data, this should generate a pulse for June, July, and August of each year from 1900 to 2005. As an illustration, FIG. 23 shows that a value of one has been placed for June observation #18, July observation #19, and August observation #20 in Column 618. If you add PULSE=MONTH to this statement, then the EVENT always specifies June, July, and August, regardless of the interval of the data. The PULSE term specifies the interval to determine the width of the event. If you specify only the timing value ‘01Jun1900’D and add PERIOD=YEAR, then you have the same effect for all years, even years before 1900 and after 2005.

With reference to the event “YR1950” defined at statement 510 by specifying a timing value within the year 1950 and using PULSE=YEAR, this event is a pulse for any observations within the year 1950. This is illustrated on FIG. 23 in column 620 for observations #13-#24.

Because of the definition at statement 512, the event “LEVELSHIFT” (e.g., TYPE=LS) has, by default, AFTER=(DURATION=ALL). The pulse begins at the observation matching Jan. 1, 1950 (i.e., observation #13), and continues to the end of the series (i.e., observation #48). A special missing value of “A” is shown in the _DUR_AFTER_ variable of the events definition data set to represent AFTER=(DURATION=ALL).

The event NOVDEC is defined at statement 514. Here the date keyword CHRISTMAS is used. CHRISTMAS produces the same result as a timing value of ‘25Decyyyy’D and PERIOD=YEAR. The options BEFORE=(DURATION=1) and PULSE=MONTH specify the months of November and December for any year in the span of the series. This is illustrated on FIG. 23 in column 624 at observations #11 and #12. If the intent is to specify certain months of the year, this is preferable to the syntax used in SUMMER.

The event FIRST10OBS is defined at statement 516. The integers in a timing list specify observation numbers. This dummy is a pulse from observation 1 to observation 10, regardless of the value of the timing ID variable. This is illustrated on FIG. 23 in column 626 from observations #1 to #10.

The event EVERYOTHEROBS is defined at statement 518. Like FIRST10OBS, this dummy specifies every other observation starting at observation 1 and ending at observation 199. This is illustrated on FIG. 23 in column 628 for ever other observation from observations #1 to #48.

The event SATURDAY is defined at statement 520. WEEK.7 in the do-list specifies Saturday dates. The do-list produces timing values that are the Saturdays in January of 1950. This is illustrated on FIG. 23 in column 630 at observation #13. If the data is daily, there are 4 pulses in January of 1950, one on each Saturday. If the data is weekly, a pulse is formed for 4 successive observations in January of 1950. If the data is monthly and RULE=ADD, which is the default, then the observation for January 1950 counts the number of Saturdays in January.

The EVENTKEY term is used at statement 522. AO15OBS is a predefined event that means a pulse placed on the 15th observation. This is illustrated on FIG. 23 in column 632 at observation #15.

LS01JAN1950D used in statement 524 is recognized as an event keyword. LS01JAN1950D is a predefined event that means a level shift beginning at ‘01Jan1950’D. The qualifier AFTER=(DURATION=5) modifies the predefined event. This is illustrated on FIG. 23 in column 636 at observations #13 to #19.

The EVENTKEY GARBAGE at 526 is ignored as garbage because it is not an event keyword. A warning is printed to a log.

An EVENTDATA statement 528 is used to input events from an events data set and to output events to an events data set. Statement 528 generates an event definition data set showing variables related to event definitions. (The output is shown in FIG. 22.)

An EVENTDUMMY statement 530 is used to output dummy variables for events to a data set. Statement 530 generates the output shown in FIG. 23 which is an interpretation of an event into an event dummy data set.

The RUN statement 532 executes the procedure.

FIG. 22 shows a data set showing variables related to event definitions. At 550 and 560, the following columns are shown that describe attributes of the defined events: observation, name, class, keyname, start date, end date, date interval, startdt (e.g., this contains either the datetime timing value or the first datetime timing value to use in a do-list), enddt (e.g., this contains the last datetime timing value to use in a do-list), dtinterval (e.g., this contains the interval for the datetime do-list), start observation, end observation, observation interval, type, value, pulse, duration before, duration after, slope before, slope after, shift, tc parm, rule and period. As an illustration, the event labor day is the first observation and has the following attributes: “simple” class; “labor” keyname; “point” type; value of “2”; 0 duration before; 0 duration after; “growth” slope before; and “growth” slope after.

FIG. 23 shows an interpretation of an event into an event dummy data set 602 with the following columns: OBSERVATION column 610; DATE column 612; airline sales data column 614; LABORDAY column 616; SUMMER column 618; YR1950 column 620; LEVELSHIFT column 622; NOVDEC column 624; FIRST10OBS column 626; EVERYOTHEROBS column 628; SATURDAY column 630; AO15OBS column 632; and LS01JAN1950D column 634. Example values for these columns have been discussed in the example above.

As another example, consider a set of EVENT definitions that has only a few variables that apply. Code for this example is shown in FIG. 24. Statement 700 identifies that PROC HPFEVENTS is to be used with the dataset “sashelp.air” that contains a time series of airline sales time data. The ID statement 702 names a numeric variable (e.g., “date” in this example) that identifies observations in the input and output data sets. The code reads the event definition data set (as defined in the above example) and saves in a condensed format. FIG. 25 illustrates the data being saved in a condensed format. As an illustration of the use of the condensed format, consider that in the previous example, no datetime timing values are specified, so the variables _STARTDT_, _ENDDT_, and _DTINTRVL_ have all missing values. In such a case, the user can specify the CONDENSE option in the EVENTDATA statement, and PROC HPFEVENTS automatically determines if any variables in the EVENT definition data set contain only the default values; those variables are not included in the output data set. In addition to the missing datetime values the variables _SLOPE_BEF_, _SLOPE_AFT_, _TCPARM, RULE_ and _PERIOD_ also contain default values and are omitted in this example from the condensed data set. When PROC HPFEVENTS reads a data set, any variables not in the data set are automatically set to the default value. Thus, it is not necessary to specify CONDENSE when using the EVENTDATA IN=option. PROC HPFEVENTS automatically reads condensed data sets.

FIG. 26 illustrates that a wide assortment of statements 800 and options (802, 804, and 806) can be used with the HPFEVENTS procedure. The procedure can have the following structure:

• • PROC HPFEVENTS options;
    • VAR variables;
    • BY variables;
    • ID variable INTERVAL=interval options;
    • EVENTDEF variable=do-list/options;
    • EVENTKEY <variable=> predefined-event-keyword/options;
    • EVENTCOMB variable=variable-list/options;
    • EVENTGROUP <variable=> predefined-event-keyword;
    • EVENTGROUP variable=variable-list;
    • EVENTDATA options;
    • EVENTDUMMY options;

The statements and options controlling the HPFEVENTS procedure are summarized in the table of FIG. 26.

The following options can be used in the PROC HPFEVENTS statement:

• • DATA=SAS-data-set
    • names the SAS data set containing the variables used in the VAR, ID, and BY statements. If the DATA=option is not specified, the most recently created SAS data set is used.
  • LEAD=n
    • specifies the number of periods to extend the dummy variable beyond the time series. The default is LEAD=0. The LEAD=value is relative to the last observation in the input data set and not to the last nonmissing observation of a particular series. Thus, if a series has missing values at the end, the actual number of dummy values beyond the last nonmissing value will be greater than the LEAD=value.
  • MAXERROR=number
    • limits the number of warning and error messages produced during the execution of the procedure to the specified value. The default is MAXERROR=25. This option is useful in BY-group processing where it can be used to suppress the recurring messages.
  • SORTNAMES
    • specifies that the events and variables in the output data sets are printed in alphabetical order.

A BY statement can be used with PROC HPFEVENTS to obtain separate dummy variable definitions for groups of observations defined by the BY variables.

The ID statement names a numeric variable that identifies observations in the input and output data sets: ID variable INTERVAL=interval options;

The ID variable's values are assumed to be date, time, or datetime values. In addition, the ID statement specifies the (desired) frequency associated with the actual time series. The information specified affects all dummy variables output using the EVENTDUMMY statements. If no dummy variables are requested, the ID statement has no impact on processing, since the EVENTDEF definitions are independent of the time identification values of a time series. If the ID statement is specified, the INTERVAL=option is also be specified. If an ID statement is not specified, the observation number, with respect to the BY-group, is used as the time ID. When the observation number is used as the time ID, only EVENT timing values that are based on observation numbers are applied to the time series to create dummy variables; timing values based on SAS date or datetime values are ignored. The following options can be used with the ID statement:

• • ALIGN=option
    • controls the alignment of SAS dates used to identify output observations. The ALIGN=option accepts the following values: BEGINNING|BEG|B, MIDDLE|MID|M, and ENDING|END|E. BEGINNING is the default.
  • END=option
    • specifies a SAS date, datetime, or time value that represents the end of the data. If the last time ID variable value is less than the END=value, the series is extended with missing values. If the last time ID variable value is greater than the END=value, the series is truncated. For example, END=“&sysdate”D uses the automatic macro variable SYSDATE to extend or truncate the series to the current date. This option and the START=option can be used to ensure that data associated with each BY-group contains the same number of observations.
  • INTERVAL=interval
    • specifies the frequency of the input time series. For example, if the input data set consists of quarterly observations, then INTERVAL=QTR should be used.
  • SETMISSING=option|number
    • specifies how missing values are assigned in the time series copied to the dummy data set when there is no observation matching the time ID in the input data set. If a number is specified, missing values are set to number. If a missing value indicates an unknown value, this option should not be used. If a missing value indicates no value, a SETMISSING=0 should be used. You would typically use SETMISSING=0 for transactional data because no recorded data usually implies no activity. The following options can also be used to determine how missing values are assigned:
  • MISSING:
    • Missing values are set to missing. This is the default option.
  • SKIP:
    • If the observation for the time ID value is missing in the input data set, then the corresponding observation is skipped in the dummy data set. This option may be useful if dummies are to be used as predictor values and you wish apply the PROC HPFENGINE ACCUMULATE option to the dummy data.
  • START=option
    • specifies a SAS date, datetime, or time value that represents the beginning of the data. If the first time ID variable value is greater than the START=value, the series is prepended with missing values. If the first time ID variable value is less than the START=value, the series is truncated. This option and the END=option can be used to ensure that data associated with each by group contains the same number of observations.
  • An EVENTDEF statement can be used with PROC HPFEVENTS to define an event: EVENTDEF: SAS-variable-name=timing-value-list/qualifier options;

Although an event occurs at one or more time values, the event definition is independent of the time ID; that is, the event is a function that operates on a time ID variable. Once defined, the event can be output using the OUT=option of the EVENTDATA statement. A dummy variable for the event can be output using the OUT=option of the EVENTDUMMY statement. The dummy variable can be created by evaluating the event with respect to the time ID. If a time ID is not specified using the ID statement, then the BY-group observation number is used as the time ID. More than one EVENTDEF statement can be specified. Once defined, an event will be referenced using its variable-name. When the event is output using the EVENTDATA statement, the event will be identified by its variable-name. When a dummy is created using the event definition, the dummy variable name will be the same as the event SAS-variable-name.

Each event has a unique variable-name. If two event definitions have the same name, the following rules apply. If two EVENTDEF statements exist using the same name, the later statement is used. If an event is defined in both an EVENTDEF statement and in a data set specified using the EVENTDATA statement, the definition in the EVENTDEF statement is used. Any event defined using an EVENTDEF or EVENTDATA statement is used rather than a SAS predefined event.

Each EVENTDEF statement is defined using one or more event timing values. The timing values may be specified using a list. Each item in the list may be a SAS date keyword, an integer, a SAS-date, a SAS-datetime, or a do-list. For example, the EVENTDEF statement below specifies timing values using each of these methods in the order listed:

• • EVENTDEF EVENT1=USINDEPENDENCE 10 ‘25Dec2000’D
    • ‘01Mar1990:15:03:00’DT
    • ‘01Jan2000’D to ‘01Mar2000’D by month;

The timing values are interpreted as: any July 4 in the series; the 10th observation; Dec. 25, 2000; Mar. 1, 1990 at 3:03 PM; Jan. 1, 2000; Feb. 1, 2000; and Mar. 1, 2000. The following two EVENTDEF statements specify identical timing values:

• • EVENTDEF MYFIRSTEVENT=‘01Jan2000’D to ‘01Mar2000’D by month; EVENTDEF MYNEXTEVENT=(‘01Jan2000’D, ‘01Feb2000’D, ‘01Mar2000’D);

The timing value list may be enclosed in parentheses, and commas may separate the items in the list. Numbers are interpreted as observation numbers. The do-list may be based on observation numbers, SAS-dates, or SAS-datetimes. However, the first and second values in the list are of the same type. The SAS grammar expects the type of the second value to be the same as the type of the first value, and tries to interpret the statement in that fashion.

The table in FIG. 27 shows an example of holiday date keywords and definitions that can be used in a timing value list and their definitions. The date of Easter is calculated using a method described by (Montes 2001b). The table in FIG. 28 shows an example of seasonal date keywords that can be used in a timing value list and their definitions.

When dummies are created, each timing value is evaluated with respect to the time ID.

The event timing value(s) should be consistent with the time ID. In particular, date and datetime timing value(s) are ignored when the time ID is based on the observation number.

The qualifier options define a function to be applied at each timing value. The following qualifier options can be used with the EVENTDEF statement:

• • TYPE=option
    • specifies the type of event variable. Each type uses a different formula to create the dummy variables. The formula for each TYPE=option is dependent on the other qualifiers that are specified in the EVENTDEF options. The formula is applied to each timing value specified in the timing-value list. The TYPE=option accepts the following values: POINT|LS|RAMP|TR|TEMPRAMP|TC|LIN|LINEAR|QUAD|CUBIC|INV|INVERSE|LOG|LOGARITHMIC. The table in FIG. 29 illustrates the basic shape for each TYPE=value. POINT is the default type.
    • The table in FIGS. 13 and 14 shows the formula used for each type of event when the event extends infinitely both before and after the timing value. The table in FIGS. 15-17 shows the formula used for each type of event for finite duration values. In the formulas, t_i is the observation specified by the ith timing value in the timing value list, VALUE=ν, TCPARM=φ, AFTER=(DURATION=n SLOPE=s_a), BEFORE=(DURATION=m SLOPE=s_b), and PULSE=interval. The table in FIG. 12 shows how to calculate t_b and t_e, which are based on the DURATION=values. The terms t_b and t_e are the beginning and ending observations of the event definition. (For TYPE=RAMP, the ramp persists past the top of the ramp.)
  • VALUE=number
    • specifies the event indicator value, ν. The default event indicator value is one (ν=1.0). The table 5 in FIGS. 15-17 provides details about the effect of the event indicator value on the dummy variables. However, for TYPE=POINT|LS|RAMP|TR|TC events consisting of a single timing value with finite duration, the user can think of the event indicator value as the maximum amplitude: the values of the dummy should be bounded below by zero and above by the event indicator value. For trend events (TYPE=LINEAR|QUAD|CUBIC|INV|LOG), the event indicator value is the coefficient of the term.
  • SHIFT=number
    • specifies the number of pulses to shift the timing value, δ. The default is not to shift the timing value (δ=0). When the SHIFT=option is used, all timing values in the list, including those generated by date keywords will be shifted. Thus, SHIFT=may be used with EASTER to specify Ecclesiastical Holidays which are based on Easter. For example,
      • EVENTDEF GoodFriday=EASTER/SHIFT=−2 PULSE=DAY;
    • specifies Good Friday, which is defined as 2 days before Easter (Montes 2001a).
  • PULSE=interval
    • specifies the interval to be used with the DURATION=option to determine the width of the event. The default pulse is one observation. When no DURATION=values are specified, and the PULSE=option is specified, the DURATION=values will be set to zero.
  • BEFORE=(option-list) and AFTER=(option-list)
    • specify options that control the event definition before and after the timing value. The DURATION=and SLOPE=options are used within the parentheses in the BEFORE=( ) and AFTER=( ) options. The SLOPE=option is ignored if the corresponding DURATION=0.
  • DURATION=number
    • specifies the event duration before the timing value when used in the BEFORE=( ) option or after the timing value when used in the AFTER=( ) option. The event always occurs at the timing value. You would specify 3 observations before, 1 observation at the timing value, and 4 after the timing value for a total of 3+1+4=8 observations as follows: EVENTDEF E1=‘01JAN1950’D/BEFORE=(DURATION=3) AFTER=(DURATION=4); You would specify 3 weeks before, the week of the timing value, and 4 weeks after the timing value using a combination of the BEFORE=, AFTER=, and PULSE=options as follows:
      • EVENTDEF E1=‘01JAN1950’D/BEFORE=(DURATION=3) AFTER=(DURATION=4) PULSE=WEEK;
  • DURATION=ALL
    • implies that the event should be extended to the beginning (BEFORE=) or end (AFTER=) of the series. If only one DURATION=value is specified, the other value is assumed to be zero. When neither DURATION=value is specified, and the PULSE=value is specified, both DURATION=values are set to zero. When neither DURATION=value is specified, and the PULSE=value is not specified, then both DURATION=values are assigned default values based on the TYPE=option. For polynomial trend events (TYPE=LINEAR|QUAD|CUBIC), the default DURATION=value is ALL for both the BEFORE=( ) option and the AFTER=( ) option. For other events, the default value for the BEFORE=( ) option is always zero, and the default event duration for the AFTER=( ) option depends on the TYPE=option. The table in FIGS. 29 and 30 shows default duration values by TYPE=value and how the basic event shape depends on the duration value. DURATION=ALL is represented in the event definition data set as a special missing value displayed as “A”.
  • SLOPE=option
    • specifies whether a ramp or temporary change type is growth or decay. SLOPE is ignored unless TYPE=RAMP, TYPE=TR, TYPE=TEMPRAMP, or TYPE=TC. SLOPE=is also ignored if the corresponding DURATION=0. The SLOPE=value in the BEFORE=option controls the slope before the timing value and the SLOPE=value in the AFTER=option controls the slope after the timing value. The SLOPE=option accepts the values: GROWTH|DECAY. GROWTH is the default. The following statement:
      • EVENTDEF E1=‘01JAN1950’D/BEFORE=(DURATION=3 SLOPE=GROWTH) AFTER=(DURATION=4) SLOPE=DECAY) TYPE=RAMP;
    • specifies a ramp up, followed by a ramp down. The event dummy observations immediately preceding the timing value contain the following values: 0,

$\frac{1}{3},\frac{2}{3}.$ The observation at the timing value has a value of 1. The observations immediately after the timing value are

$\frac{3}{4},\frac{2}{4},\frac{1}{4},$ 0.

• • TCPARM=number
    • specifies a parameter 0≦φ≦1 used in the growth/decay equation for TYPE=TC given in the table 5 of FIGS. 13 and 14. The TCPARM=value is the rate of growth or decay. A larger TCPARM=value causes faster growth or decay. TCPARM is ignored unless TYPE=TC. The default value is 0.5.
  • RULE=
    • specifies the action to take when the defined event has multiple timing values which overlap. The RULE=option accepts the following values: ADD|MAX|MIN|MINNZ|MINMAG. ADD is the default. The table in FIG. 31 explains how the RULE=option is interpreted when the value for an observation is defined by multiple timing values. Because the range of the event associated with a timing value may not include the all the observations in the series, RULE=may be interpreted differently when using multiple timing values in one EVENTDEF statement versus defining a combination event using the EVENTCOMB statement. Thus, the dummy variables TWOTIMING and TWOEVENTS defined in the following statements are different:
      • eventdef xmasrp=CHRISTMAS/BEFORE=(SLOPE=GROWTH DURATION=3) TYPE=RAMP RULE=MIN;
      • eventdef easterrp=EASTER/BEFORE=(SLOPE=GROWTH DURATION=3) TYPE=RAMP RULE=MIN;
      • eventdef twotiming=EASTER CHRISTMAS/BEFORE=(SLOPE=GROWTH DURATION=3) TYPE=RAMP RULE=MIN;
      • eventcomb twoevents=easterrp xmasrp/RULE=MIN;
  • PERIOD=interval
    • specifies the interval for the frequency of the event. For example, PERIOD=YEAR should produce a dummy value that is periodic in a yearly pattern. If the PERIOD=option is omitted, the event is not periodic. The PERIOD=option also does not apply to observation numbers, which are not periodic, or to date keywords, which have their own periodicity.
  • LABEL=‘SAS-label’
    • specifies a label for the dummy variable for this event. ‘SAS-label’ is a quoted text string of up to 256 characters. The default label is: “Dummy Variable for Event <variable-name>” where <variable-name> is the name specified in the EVENT statement.

An EVENTKEY statement can be used with PROC HPFEVENTS to make a SAS predefined event available for processing:

• • EVENTKEY <variable=> predefined-event-keyword/options;

The EVENTKEY statement will construct a SAS simple EVENT for each SAS predefined event keyword. The SAS predefined events are also available directly through PROC HPFDIAGNOSE and PROC HPFENGINE. Each EVENTKEY variable has a predefined set of timing values and qualifiers associated with the predefined event keyword. The options are the same as in the EVENTDEF statement and can be used to redefine the qualifiers associated with the predefined event. The default variable name for the predefined event is the predefined event keyword. However, the user can specify a variable name for the event. For example, you can rename the CHRISTMAS predefined EVENT to XMAS using the following statement:

• • EVENTKEY XMAS=CHRISTMAS;

If the user redefines the qualifiers associated with a SAS predefined EVENT and does not rename the event, then that has the impact of redefining the SAS predefined event, since any user definition takes precedence over a SAS predefined definition. The following example produces an event FALLHOLIDAYS with a pulse of 1 day at Halloween and a pulse of 1 month at Thanksgiving.

• • EVENTKEY THANKSGIVING/PULSE=MONTH;
  • EVENTCOMB FALLHOLIDAYS=HALLOWEEN THANKSGIVING;SAS predefined events are based on either a SAS date keyword or an additive outlier or level shift based on a timing value. The table in FIG. 32 describes how to construct a SAS predefined event keyword. It also gives the default qualifier options for those predefined events.

The table in FIG. 27 shows the date keywords that can be used as SAS predefined event keywords and their definitions. The table in FIG. 28 shows the seasonal keywords that can be used as SAS predefined event keywords and their definitions. The table in FIG. 33 gives a more detailed description of how date and observation numbers are encoded into AO and LS type predefined events.

An EVENTCOMB statement can be used with PROC HPFEVENTS to create a new event from one or more events that have previously been defined:

• • EVENTCOMB variable=variable-list/options;

The following options can be used with the EVENTCOMB statement.

• • RULE=
    • specifies the action to take when combining events. The RULE=option accepts the following values: ADD|MAX|MIN|MINNZ|MINMAG. ADD is the default. The table in FIG. 31 explains how the RULE=option is interpreted.

An EVENTGROUP statement can be used with PROC HPFEVENTS to create an event group or make a predefined event group available for processing:

• • EVENTGROUP <variable=> predefined-eventgroup-keyword;
  • EVENTGROUP variable=variable-list;

The EVENTGROUP statement will construct a SAS complex EVENT. A complex EVENT is an event which is represented by multiple dummy variables. For example, seasonal effects usually require multiple dummy variables. The SAS predefined event groups are also available directly through PROC HPFENGINE. Each EVENTGROUP predefined group keyword has a predefined set of event keywords associated with the predefined group. The default variable name for the predefined event is the predefined event keyword. However, the user can specify a SAS variable name for the event. For example, you can rename the DAYS predefined EVENT group to TD using the following statement:

• • EVENTGROUP TD=DAYS;The table in FIG. 34 describes the SAS predefined event group keywords. The SEASONAL group is a PREDEFINED COMPLEX EVENT; the SEASONAL group is interpreted to be one of the other SEASONAL groups at the time that dummy variables are created based on the ID statement. The ID statement could be the ID statement associated with either PROC HPFEVENTS or PROC HPFENGINE.

The table in FIG. 32 provides more detail on the seasonal and trend SAS predefined EVENTS that are compose the EVENT groups.

An EVENTDATA statement can be used with PROC HPFEVENTS to input events from an events data set and to output events to an events data set:

• • EVENTDATA options;Either the IN=or the OUT=option are specified. The following options can be used with the EVENTDATA statement:
  • IN=SAS-data-set
    • names an input data set that contains event definitions to be used in the PROC HPFEVENTS procedure.
  • OUT=SAS-data-set
    • names the output data set to contain the event definitions as specified in the EVENTDATA IN=data sets and the EVENTDEF, EVENTKEY, EVENTGROUP and EVENTCOMB statements. The OUT=data set can then be used in other SAS procedures to define events.
  • CONDENSE
    • specifies that the EVENTDATA OUT=data set is condensed; any variables that contain only default values are omitted from the data set. The EVENTDATA IN=option reads both condensed data sets and data sets that have not been condensed. For more details, see “EVENTDATA OUT Data Set”.

An EVENTDUMMY statement can be used with PROC HPFEVENTS to output dummy variables for events to a data set. Options can be specified as follows with an EVENTDUMMY:

• • EVENTDUMMY options;The OUT=option should be specified. The following option can be used with the EVENTDUMMY statement:
  • OUT=SAS-data-set
    • names the output data set to contain the dummy variables for the specified events based on the ID information as specified in the ID statement. The OUT data set also includes variables as specified in the VAR, BY, and ID statements.

A VAR statement can be used with PROC HPFEVENTS to copy input variables to the output dummy data set:

• • VAR variables;Numeric variables are specified. If the VAR statement is omitted, all numeric variables are selected except those appearing in a BY or ID statement.

When the EVENTDUMMY statement is used to create dummy variables, you may need to specify the handling of missing observations in the input data set, that is, where the observation corresponding to a time ID is missing from the data set. In that case, the input data set does not contain a value for the variables to be copied to the EVENTDUMMY OUT=data set. Sometimes missing values should be interpreted as unknown values. The forecasting models used by the HPFENGINE procedure can effectively handle missing values (see Chapter 16, “The HPFENGINE Procedure” of the above-referenced 60/679,093 provisional application). In this case, SETMISSING=MISSING can be used. But sometimes missing values are known, such as when no observations should be interpreted as no (zero) value. In this case, the SETMISSING=0 option should be used. In other cases, missing time IDs should be skipped, such as when the data is to be accumulated at a later time. In this case, SETMISSING=SKIP should be used.

The HPFEVENTS procedure can create the EVENTDATA OUT and EVENTDUMMY OUT=data sets. The EVENTDATA OUT=data set contains the EVENT definitions that may be used for input to another SAS procedure. The EVENTDUMMY OUT=data set contains the variables listed in the BY statement, the ID variable, any variables defined by the VAR statement, and any dummy variables generated by the procedure.

The EVENTDATA OUT=data set contains the variables listed below. The default values for the CONDENSE option are also given. (When all the observations in the variable are equal to the default value, the variable can be omitted from the event definition data set.)

• • _NAME_—
    • EVENT variable name. The _NAME_ variable is required; there is no default.
  • _CLASS_—
    • Class of EVENT: SIMPLE, COMBINATION, PREDEFINED. The default for _CLASS_ is SIMPLE.
  • _KEYNAME_—
    • Contains either a date keyword (SIMPLE EVENT) or a predefined EVENT variable name (PREDEFINED EVENT) or an event name (COMBINATION event or an event name (GROUP event)). The default for _KEYNAME_ is no keyname, designated by “.”.
  • _STARTDATE_—
    • Contains either the date timing value or the first date timing value to use in a do-list. The default for _STARTDATE_ is no date, designated by a missing value.
  • _ENDDATE_—
    • Contains the last date timing value to use in a do-list. The default for _ENDDATE_ is no date, designated by a missing value.
  • _DATEINTRVL_—
    • Contains the interval for the date do-list. The default for _DATEINTRVL_ is no interval, designated by “.”.
  • _STARTDT_—
    • Contains either the datetime timing value or the first datetime timing value to use in a do-list. The default for _STARTDT_ is no datetime, designated by a missing value.
  • _ENDDT_—
    • Contains the last datetime timing value to use in a do-list. The default for _ENDDT_ is no datetime, designated by a missing value.
  • _DTINTRVL_—
    • contains the interval for the datetime do-list. The default for _DTINTRVL_ is no interval, designated by “.”.
  • _STARTOBS_—
    • Contains either the observation number timing value or the first observation number timing value to use in a do-list. The default for _STARTOBS_ is no observation number, designated by a missing value.
  • _ENDOBS_—
    • Contains the last observation number timing value to use in a dolist. The default for _ENDOBS_ is no observation number, designated by a missing value.
  • _OBSINTRVL_—
    • Contains the interval length of the observation number do-list. The default for _OBSINTRVL_ is no interval, designated by “.”.
  • _TYPE_—
    • Type of EVENT. The default for _TYPE_ is POINT.
  • _VALUE_—
    • Value for nonzero observation. The default for _VALUE_ is 1.0.
  • _PULSE_—
    • INTERVAL that defines the units for the DURATION values. The default for _PULSE_ is no interval, designated by “.”.
  • _DUR_BEFORE_—
    • Number of durations before the timing value. The default for _DUR_BEFORE_ is 0.
  • _DUR_AFTER_—
    • Number of durations after the timing value. The default for _DUR_AFTER_ is 0.
  • _SLOPE_BEFORE_—
    • For TYPE=RAMP, TYPE=RAMPP, and TYPE=TC, this determines whether the curve is GROWTH or DECAY before the timing value. The default for _SLOPE_BEFORE_ is GROWTH.
  • _SLOPE_AFTER_—

For TYPE=RAMP, TYPE=RAMPP, and TYPE=TC, this determines whether the curve is GROWTH or DECAY after the timing value. The default for _SLOPE_AFTER_ is GROWTH.

• • _SHIFT_—
    • Number of PULSE=intervals to shift the timing value. The shift may be positive (forward in time) or negative (backward in time). If PULSE=is not specified, then the shift is in observations. The default for _SHIFT_ is 0.
  • _TCPARM_—
    • Parameter for EVENT of TYPE=TC. The default for _TCPARM_ is 0.5.
  • _RULE_—

Rule to use when combining events or when timing values of an event overlap. The default for _RULE_ is ADD.

• • _PERIOD_—

Frequency interval at which the event should be repeated. If this value is missing, then the event is not periodic. The default for _PERIOD_ is no interval, designated by “.”.

The following example illustrates how the HPFEVENTS procedure interprets multiple timing values that overlap as well as the results of the same timing values used in separate EVENTDEF statements that are combined using EVENTCOMB (e.g., use of multiple timing values in a single event vs. using multiple events and the EVENTCOMB statement). Airline sales data is used for this illustration.

The code in FIG. 35 defines a ramp for Christmas for observations 9 through 14. When XMASRP is evaluated, the undefined values in observations 1 through 8 are replaced with zeroes. The ramp for Easter is defined for the entire time series, as shown in the variable EASTERRP. When both timing values are used in one EVENTDEF statement for variable TWOTIMING, the values from the Easter ramp are used in observations 1 through 8, and the RULE=MIN is applied to observations 9 through 14. For the EVENTCOMB statement that defines the variable TWOEVENTS, the RULE=MIN option applies to all observations in the series. The output shown in FIG. 36 depicts multiple timing values versus multiple events.

As another example, the following example uses the DATA step to automatically construct potential outliers related to the price data found in the data set SASHELP.PRICEDATA. The following code is executed as a first step:

• • data orders(keep=date region line product sale);
    • set SASHELP.PRICEDATA;
    • format date monyy;
  • run;

The following SAS code constructs an EVENTDATA IN=data set for potential outliers (identified as sale >450). Only the _NAME_ and _STARTDATE_ variable are needed.

• • data outliers(keep=_NAME_ _STARTDATE_);
    • set orders;
    • if (sale >450) then do;
      • _NAME_=trim(‘AO’)∥trim(left(put(YEAR(date),8.)))∥’_’∥trim(left(put(MONTH(date),8.)));
      • _STARTDATE_=date;
      • end;
    • else delete;
    • format _STARTDATE_ monyy;
  • run;

Next, an identification is done as to which outliers apply to each product.

• • data product_event_list (keep=region line product _NAME_);
    • set orders;
    • if (sale >450) then do;
      • _NAME_=trim(‘AO’)∥trim(left(put(YEAR(date),8.)))∥’_’∥trim(left(put(MONTH(date),8.)));
      • end;
    • else delete;
  • run;

The potential outliers in the data set OUTL_REG1_LINE1_PROD1 apply to Region 1, Line 1, and Product 1.

• • data outl_reg1_line1_prod1;
    • set product_event_list;
    • if ((region ˜=1)|(line ˜=1)|(product ˜=1)) then delete;
  • run;

Dummy variables are created and duplicate outlier events are eliminated from the events definition data set.

• • proc hpfevents data=orders;
    • id date interval=month;
    • by region line product;
    • eventdata in =outliers;
    • eventdata out=outidatabase (label=‘outlier definitions’) condense;
    • eventdummy out=dummies (label=‘dummy variables’);
  • run;

Examining the data set OUTL_REG1_LINE1_PROD1 (depicted in FIG. 37) shows that we might want to look for outliers for May 1998, October 1999, March 2000, February 2001, June 2001, and September 2002.

PROC HPFEVENTS produced this data set (depicted in FIG. 38), which is condensed and has the duplicate events eliminated.

There is a selection of the observations related to Region 1, Line 1, Product 1 and scaling of the dummies that apply so that they are visible when plotted with the original data via the following code:

• • data pid1;
  • set dummies;
  • if ((region ˜=1)|(line ˜=1)|(product ˜=1)) then delete; else do;
    • AO1998_—5=100*AO1998_—5;
    • AO1999_—10=100*AO1999_—10;
    • AO2000_—3=100*AO2000_—3;
    • AO2001_—2=100*AO2001_—2;
    • AO2001_—6=100*AO2001_—6;
    • AO2002_—9=100*AO2002_—9;
  • end;
  • run;

PROC GPLOT is used to visually verify that these potential outliers are appropriate for the original data.

• • axis2 label=(angle=90 ‘time series data for decomposition’);
  • symbol1 i=join v=‘star’ c=black;
  • symbol1 i=join v=‘circle’ c=red;
  • legend1 label=none value=(‘Dummy for Event AO1998_—5’
    • ‘Dummy for Event AO1999_—10’
    • ‘Dummy for Event AO2000_—3’
    • ‘Dummy for Event AO2001_—2’
    • ‘Dummy for Event AO2001_—6’
    • ‘Dummy for Event AO2002_—9’
    • ‘Amount of Sales’);
  • proc gplot data=pid1;
    • plot AO1998_—5*date=2
    • AO1999_—10*date=2
    • AO2000_—3*date=2
    • AO2001_—2*date=2
    • AO2001_—6*date=2
    • AO2002_—9*date=2
    • sale*date=1/overlay legend=legend1 vaxis=axis2;
  • run;The graphical results of running this code are shown in FIG. 39. The plot 900 contains a graph of the amount of sales 902 and the dummy 904 over a period of time. The period of time in this example is from January 1998 to January 2003.

The following example illustrates how a data set is prepared for PROC HPFENGINE as well as how the HPFEVENTS procedure can be used to include events in the automatic forecasting of time series data. The code in FIG. 40 makes the data set via the statements at 1000 and alters the data by adding a levelshift of 100 beginning at October, 1980. At 1002, PROC HPFEVENTS is used to create an event named PROMOTION as a level shift occurring at Oct. 1, 1980. At 1004 and 1006, model specifications are created through PROC HPFARIMASPEC. The HPFARIMASPEC procedure is used to create an ARIMA model specification file. The output of this procedure is an XML file that stores the intended ARIMA model specification. This XML specification file can be used for different purposes; for example, to populate the model repository used by the HPFENGINE procedure. You can specify very general ARIMA models using this procedure. In particular, any model that can be analyzed using the ARIMA procedure can be specified. Moreover, the model specification can include series transformations such as log or Box-Cox transformations. The procedure is discussed further in of the above-referenced 60/679,093 provisional application.

At 1008, the HPFSELECT procedure is used to make a model selection list. The HPFSELECT procedure enables you to control the forecasting model selection process by defining lists of candidate forecasting models. Using model selection lists created by HPFSELECT, you can control which forecasting model or models are used to forecast particular time series. The HPFSELECT procedure creates model selection files and stores them in a repository for later use by the HPFENGINE procedure. (The procedure is discussed further in of the above-referenced 60/679,093 provisional application.) These model selection files list model specifications previously created and stored in a model repository by the HPFARIMASPEC, HPFESMSPEC, HPFEXMSPEC, HPFIDMSPEC, or HPFUCMSPEC procedures.

At 1010, the HPFENGINE procedure is used to select a model to forecast for the electric variable. The results of the model selection using events are shown in FIG. 41. The output shows that PROC HPFENGINE has identified the parameter of the event PROMOTION as 97.6728, which is used in conjunction with the model named SP1 described as “ARIMA(0, 1, 1) No Intercept” to describe the forecasted variable electric.

In this example (whose code is shown in FIG. 40), the user can use the EVENTS system directly without using PROC HPFEVENTS. Instead of creating an event named PROMOTION, the user can use the SAS predefined event keyword LS01OCT1980D. The following example uses the data set generated from the code of FIG. 40 and the EVENT statement in PROC HPFDIAGNOSE to illustrate this method.

The code for this example is shown in FIG. 42. The data set is created at 1050 and the HPFDIAGNOSE procedure provides a forecast for the variable electric. The output in FIG. 43 from PROC HPFDIAGNOSE shows that a model was selected that included the level shift occurring at October 1980.

The following example illustrates how the HPFEVENTS procedure can be used to create dummies. With reference to the code of FIGS. 44 and 45, line 1100 identifies that PROC

HPFEVENTS is to be used. The “data” term names the SAS data set containing the variables used in the VAR line 1102 and ID line 1104. The VAR statement 1102 is used with PROC HPFEVENTS to copy input variables to the output dummy data set. The ID statement 1104 names a numeric variable (e.g., “date” in this example) that identifies observations in the input and output data sets. The “air” variable (which represents airline sales data) is retrieved from the sashelp.air dataset. The events are defined at 1110 and 1112 whose interpretation is shown in FIG. 46.

This example illustrates the behavior of ramp variables when used with the SLOPE=option. This example also shows that when one DURATION=value is finite, and the other is infinite, this is equivalent to extending the finite portion of the event infinitely in one direction. This principle may be understood by examining the results of the following EVENTDEF statements in the code of FIGS. 44 and 45:

• • eventdef monlygg=‘01Jun1951’D/TYPE=RAMP
    • BEFORE=(SLOPE=GROWTH DURATION=4);
  • eventdef minfgg=‘01Jun1951’D/TYPE=RAMP
    • BEFORE=(SLOPE=GROWTH DURATION=4)
    • AFTER=(SLOPE=GROWTH DURATION=ALL);
  • eventdef minfgd=‘01Jun1951’D/TYPE=RAMP
    • BEFORE=(SLOPE=GROWTH DURATION=4)
    • AFTER=(SLOPE=DECAY DURATION=ALL);

These dummy variables can then be viewed using SASGRAPH, such as via the code shown in FIG. 47 which produces the graph of FIG. 48. The graph of FIG. 48 is a plot of finite and extended dummy variables. For example, the ramp with extended growth is shown at 1200, the finite ramp is shown at 1202, and the ramp with extended decay is shown at 1204.

It is noted that the systems and methods may be implemented on various types of computer architectures, such as for example on a single general purpose computer or workstation, or on a networked system, or in a client-server configuration, or in an application service provider configuration.

It is further noted that the systems and methods may include data signals conveyed via networks (e.g., local area network, wide area network, internet, etc.), fiber optic medium, carrier waves, wireless networks, etc. for communication with one or more data processing devices. The data signals can carry any or all of the data disclosed herein that is provided to or from a device.

Additionally, the methods and systems described herein may be implemented on many different types of processing devices by program code comprising program instructions that are executable by the device processing subsystem. The software program instructions may include source code, object code, machine code, or any other stored data that is operable to cause a processing system to perform methods described herein. Other implementations may also be used, however, such as firmware or even appropriately designed hardware configured to carry out the methods and systems described herein.

The systems' and methods' data (e.g., associations, mappings, etc.) may be stored and implemented in one or more different types of computer-implemented ways, such as different types of storage devices and programming constructs (e.g., data stores, RAM, ROM, Flash memory, flat files, databases, programming data structures, programming variables, IF-THEN (or similar type) statement constructs, etc.). It is noted that data structures describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program.

The systems and methods may be provided on many different types of computer-readable media including computer storage mechanisms (e.g., CD-ROM, diskette, RAM, flash memory, computer's hard drive, etc.) that contain instructions for use in execution by a processor to perform the methods' operations and implement the systems described herein.

The computer components, software modules, functions, data stores and data structures described herein may be connected directly or indirectly to each other in order to allow the flow of data needed for their operations. It is also noted that a module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code. The software components and/or functionality may be located on a single computer or distributed across multiple computers depending upon the situation at hand.

It should be understood that as used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise. Finally, as used in the description herein and throughout the claims that follow, the meanings of “and” and “or” include both the conjunctive and disjunctive and may be used interchangeably unless the context expressly dictates otherwise; the phrase “exclusive or” may be used to indicate situation where only the disjunctive meaning may apply.

Claims

1. A computer-implemented method for processing time-series data, comprising: accessing, using one or more data processors, time series data including one or more time series;accessing, using the one or more data processors, one or more event definitions, wherein each event definition corresponds to an association between an event and a set of one or more parameters;generating, using the one or more data processors, one or more dummy variables for a time series, wherein a dummy variable is generated by applying an event to the time series, and wherein an event definition corresponding to the event is used to apply the event to the time series;identifying, using the one or more data processors, a model including the event;forecasting, using the one or more data processors, the time series, wherein forecasting includes fitting the model to the time series using the event definition corresponding to the event and the one or more dummy variables;adjusting, using the one or more data processors, the one or more dummy variables when the time series is altered, wherein adjusting includes applying the event to the altered time series to automatically generate one or more adjusted dummy variables; andforecasting, using the one or more data processors, the altered time series, wherein forecasting includes fitting the identified model to the altered time series using the event definition corresponding to the event and the one or more adjusted dummy variables.

2. The method of claim 1, wherein the time series data includes an initial time, an ending time, and a frequency.

3. The method of claim 1, further comprising: optimizing one of the one or more parameters associated with the event.

4. The method of claim 2 further comprising: selecting the event or an event group based upon the frequency of the time series data.

5. The method of claim 4, wherein the frequency is a seasonal frequency.

6. The method of claim 2, wherein the altered time series includes a different starting time and a different ending time than the time series.

7. The method of claim 1, further comprising: adjusting the one or more dummy variables when the event is altered.

8. The method of claim 1, wherein the one or more dummy variables indicate how the event impacts the forecasted time series.

9. The method of claim 1, wherein the set of one or more parameters includes event name parameters, class parameters, key name parameters, timing value parameters, event type parameters, value parameters, shift parameters, pulse parameters, duration parameters, slope parameters, period parameters, controls in an exponential curve, or event combination rules.

10. The method of claim 1, wherein the event is an Easter event, a United States Thanksgiving event, a boxing event, a Christmas event, a father's day event, a Halloween event, a United States Independence day event, a labor day event, a memorial day event, a mother's day event, a new year's day event, a Canadian Thanksgiving day event, or a valentine's day event.

11. The method of claim 1, wherein the time series data is stored in a first data store, and wherein the one or more event definitions are stored in a second separate data store.

12. The method of claim 1, wherein the time series includes an ID statement and one or more time ID values, and wherein the event is also based upon the ID statement and the one or more time ID values.

13. The method of claim 12, wherein the one or more time ID values are defined using a formula.

14. The method of claim 1, wherein the identified model is stored for subsequent use.

15. A system for processing time-series data, comprising: one or more processors;one or more computer readable storage mediums containing instructions configured to cause the one or more processors to perform operations including: accessing time series data including one or more time series;accessing one or more event definitions, wherein each event definition corresponds to an association between an event and a set of one or more parameters;generating one or more dummy variables for a time series, wherein a dummy variable is generated by applying an event to the time series, and wherein an event definition corresponding to the event is used to apply the event to the time series;identifying a model including the event;forecasting the time series, wherein forecasting includes fitting the model to the time series using the event definition corresponding to the event and the one or more dummy variables;adjusting the one or more dummy variables in response to an alteration of the time series, wherein adjusting includes applying the event to the altered time series to automatically generate one or more adjusted dummy variables; andforecasting the altered time series, wherein forecasting includes fitting the identified model to the altered time series using the event definition corresponding to the event and the one or more adjusted dummy variables.

16. A computer program product for processing time-series data, tangibly embodied in a machine readable storage medium, including instructions configured to cause a data processing apparatus to: access time series data including one or more time series;access one or more event definitions, wherein each event definition corresponds to an association between an event and a set of one or more parameters;generate one or more dummy variables for a time series, wherein a dummy variable is generated by applying an event to the time series, and wherein an event definition corresponding to the event is used to apply the event to the time series;identify a model including the event;forecast the time series, wherein forecasting includes fitting the model to the time series using the event definition corresponding to the event and the one or more dummy variables;adjust the one or more dummy variables in response to an alteration of the time series, wherein adjusting includes applying the event to the altered time series to automatically generate one or more adjusted dummy variables; andforecast the altered time series, wherein forecasting includes fitting the identified model to the altered time series using the event definition corresponding to the event and the one or more adjusted dummy variables.