JMP has some very easy to use hooks into SAS and ODBC databases for retrieving data, but JMP is not meant to be used as a database system itself. Because of this design decision, I have found that it is non-trivial to aggregate data and charting capabilities amongst multiple similar tables of data and forecasts in JMP.
A few examples of how this feature would be useful are as follows: in time series forecasting of multiple data channels, linear regression of multiple lines of business that form groups of data series and need to be viewed in aggregate, or other analysis packages and charting features that JMP excels at when you need to combine and aggregate data repeatedly over time. This how-to may not be the optimal solution, but these tips and tricks works at a basic level:
dt1<<Join( // message to first table With(dt2), // the other data table //Select(1,2,3), // optional column selection //SelectWith(1,2,3), // optional column selection By Row Number, // default join type; alternatives are Cartesian Join or
//By Matching Columns(col1==col2,col) // options for each table: Drop Multiples(false,true), // Include NonMatches(boolean,boolean), Output Table Name("tmp1") // the resulting table );
Joining only two tables at a time can become quite tedious, and can make your joined table size ("tmp1" in this example) grow quickly. Because the Join command adds the tables together by copying columns from the "dt2" table to the "dt1" table I recommend aggregating two tables together that contain the original forecasts, then aggregating two more original tables, deleting unnecessary and duplicate columns of data, and then repeating the procedure of joining and deleting on the aggregate tables until you arrive at one final aggregate table of data and forecasts.
// reformat a table that has been created by joining two other tables reformat_joined_dt = function({dt, stopCol, trailCol}, cc = dt << Get Column Names; try( for(i=NItems(cc)-trailCol, i>=stopCol, i--, cc[i] << Set Name("tmp"); dt << Delete Columns("tmp"); ), print(exception_msg); throw(); ); );
This function defines three variables: dt, stopCol, and trailCol. "dt" is used to assign the datatable, stopCol is used to define at which column the function should stop deleting columns, and trailCol indicates how many columns at the end of the table are considered trailing columns (which you want to not delete).
First we use the 'Get Column Names' function to load the internal function variable "cc" with all of the columns in the table, "dt". Then we use the try/throw error handling routine to encapsulate a simple loop to delete the columns that we need to delete. We set up a 'for' loop that decrements from the end of the table. (since I know exactly how many columns I want to keep at the end of the table, but for the data I am working with I can't always anticipate how many columns are in the middle of my table) When the "stopCol" column is reached, the 'for' loop ends and we exit this function.
Now, the key action is to iterate through the array of columns stored in the variable "cc", set the column name to the value of "tmp" (or whatever generic temporary name you want to call it), and then delete column "tmp". We do it this way because the 'Delete Columns' function in JMP is not very flexible, and I have found that it won't accept a reference to a column name, but only the column name itself. This contradicts standard C/C++ programming behavior, but if you're using JSL as a programming language to get the pretty charting capabilities of JMP then you don't have the luxury of a fully functional C/C++ compiler anyway.
Doing this in JMP allows you to use the same kind of powerful and easy-to-use graphics that JMP brings to statistical analysis for your aggregated data that you are seeing at the individual table level for each client, customer type, etc. Statisticians in business are often interested in forecasting separately when forecasting for planning and operational information purposes, and many organizations use a series of Microsoft Excel spreadsheets to accomplish this task which reduces the approachability of the data. JMP provides a much nicer graphical environment to view actual and forecast data through, and using this method of aggregating data and forecasts will simplify the manual work needed to perform future forecast analysis.
Comments
Post new comment