Tuesday, November 1, 2011

RuleBased Forecasting, RBF, Part 1


I have been asked several times, "How can RBF help me in my business?" A simplistic view of RBF is that RBF is an amalgamation of statistics, rules and data curve matching. By adjusting certain parameters of the curve matching using well-defined and proven-over-time methods and procedures, each iteration of the rules (rules always run over and over) should yield closer and closer match to the real data so that the forecast data are far more correct. Basically, the rules help the forecaster in giving the forecaster a highly accurate initial forecast. The forecaster, of course, can always change some of the parameters of the rules so that he/she can see the difference in what would happen. What a great training tool for forecasters!!

OK, that sales pitch being said, what about some examples? Hopefully, next year at Rules Fest, we will be able to show the rules working on real data (hopefully some massive data sets) and show how changing one small parameter can have drastic (good or bad) effects on the outcome. In the meantime, just drop me a line about what you and/or your company is doing in the field of forecasting. Are you using Linear Regression, Multiple Linear Regression, Box Jenkins, Neural Networks, Econometric Forecasting or what? Sometimes a smaller (or even some rather large) companies don not use ANY software to help with this complex problem. This is what we call, "Flying by the seat of your pants." solution. That SOP solution can get a company burned badly. However, relying on poor data or insufficient data can get you into hot water as well.

For example, if you are using monthly data, you need (OK, should have) at least 5 years (60 months) of really clean data from various internal and/or external sources to give the RBF a chance of accuracy. Other systems that use cycles of yearly data or non-standard cycles, are tougher but a decent RBF should be able to handle that in the curve matching routines and, again, if the system has sufficient data then the forecasting tool will have a much better chance of fitting the forecast to the provided data.

Hopefully, I'll have some more on this next week.



woolfel said...

In the few short years that I've been doing Java development, I can honestly say I've never seen "clean" data. The bigger the company and the bigger the dataset, the dirtier it is. Then again, I've only been working as a software engineer since 1997, so maybe one day I'll see clean data.

James Owen said...


Let's see, counting on my fingers (and some toes) that comes out to about 13 years. I did electronics and EE stuff until 1989 when I "saw the light" and switched to software - lots more fun but I seem to have forgotten my partial-DE and Fourier transforms. :-)

Not only that, but after 20 or 30 years of pure software, it does get boring doing the same think week after week, even if it is doing rulebased design and Java and C++. VERY few businesses use anything more complicated than what you would find on a simple (really simple) calculator. (No... Don't flip over to the scientific calculator for all that really neat stuff over there.)

However, my RBF work is bringing it all back home now. I've had to dig out my stats books, my forecasting books and my math books to wrap up all of that with an RBF. Now software is getting to be fun again. Far more of a challenge but I can't seem to get the ordinary programmer excited about it. Maybe it's just the way I present it.

Keep up the good work. When you find a "clean database" let me know. GIGO still holds for database as well as methods and sub-routines.