Frequently Asked Questions

• Is there a limit on the number of data points that OpenForecast can handle?
• Though I'm using the "best fit" curve, it gives me strange/unexpected forecast values. Why? Am I doing something wrong?
• Is there a version of OpenForecast for Microsoft's .NET?

Is there a limit on the number of data points that OpenForecast can handle?

There is no hard limit to the number of DataPoints within a DataSet. Basically a DataSet stores its DataPoints in an ArrayList, so that's where any limitations will come about. These will generally be related to how much memory you have available to the JVM.

Additionally, since a DataSet is a collection of DataPoints and a DataPoint is an interface, then the amount of memory used by your DataPoint implementation will also have an impact on the number of DataPoints that OpenForecast - actually your JVM - can handle. If you know you will be handling large numbers of DataPoints in your application, then be sure to make the implementation of a DataPoint as "lean" and memory-efficient as possible.

Typically in the sample and test applications, we've dealt with up to 50 or so DataPoints in a DataSet which, admittedly, is small. However, users of OpenForecast have successfully used it with 20,000 data points!

Though I'm using the "best fit" curve, it gives me strange/unexpected forecast values. Why? Am I doing something wrong?

To answer this, the first thing to look at is your input data.

If your input data - the observations - vary quite considerably then, it is reasonable that the model you get back from the Forecaster class as the "best" is in fact a polynomial regression model. If you plot the regression curve alongside your input data, you'll probably find that it does indeed fit the data pretty well. Higher order polynomial regression models can fit most data - even random data - pretty well.

So, what can you do to get a better forecast?

1. Use more input data. Collect more observations, if possible. Roughly speaking, the more data you use - provided it begins to show some sort of pattern - the better the forecast is likely to be.
2. Related to this, you may also want to take a closer look at your data. If there are some initial data points that have very low values, are these "start up" values of some system, whereas the later observations are more like "steady state" values? If so, can you omit the start-up values from the initial data set? Doing so should give more reasonable and stable results. But again, still consider using more input data - but more of the "steady state" values.
3. If neither of these first two options are viable, then try forcing the use of a different model. If you really do have so few observations and cannot obtain more, and you also have some idea of what range the forecast values should be in - and whether you'd expect to see the values increase, decrease, oscillate, etc. over time - then you should really do some further analysis to select a good forecasting model.
   In other words, the numbers alone do not provide enough information to select a "good" model - based on what you would expect to see. You should try out various other models - plotting their future projections on a chart is often very helpful in this respect. Then select the one you feel best provides future forecasts for your data, based on your additional knowledge of the data.

Is there a version of OpenForecast for Microsoft's .NET?

Yes, kind of. For OpenForecast 0.4, some minor changes were made to the OpenForecast source code to ease the automatic conversion to Microsoft's J#. If you're specifically interested in this, then be sure to get download version 0.4 (or later).

For more details on how to incorporate OpenForecast into a .NET project, see the MSDN article, Microsoft Reporting Services in Action: Extending Microsoft SQL Server 2000 Reporting Services with Custom Code, by Teodor Lachev. This article includes an excellent demonstration of how to using OpenForecast in your .NET application.

Oh, please do not contact the author of OpenForecast for details. I haven't done this myself!