I have to agree with RJOH, it is very important to keep the effort of input (from a very large database) very low. The ability to import ascii, or tab delimited data into a program keeps effort to a minimum.
The ability to modify a program's algorithms is also a must in any numerical prediction program. As any serious lottery player will expound on at length, we like to modify. If we didn't, we wouldn't be looking to others for their strategies.
Perhaps, for the more ambitious amongst us, you could provide a window listing the current algorithm being used at any time during calculation. Then allow us to modify this algorithm on the fly. Wheeling strategies come to mind immediately. Everyone has their own favorite wheeling strategies. Just to keep the program neat and tidy, though, I recommend a default return button in case a modification goes haywire and begins to cramp the program beyond workability. The default button would return the original code previously programmed by the company.
On another note, one might also consider the ability to save algorithms for future use. Even, as well, the ability to send them to the parent company if they provide better sample data than the original. Consider paying the amature "developer" for these modifications, and evolve the program at an accelerated pace. 10,000 amature minds working to solve a single problem can often provide a better solution than 100 professionals in research and development.
Personally, I use a spreadsheet (actually a series of them) with 60,000 active cells. For me the ability to modify and import is the height of functionality.
Other important issues are corrupt data detection and and correction. Having learned my lessons about corrupt data from the golden days of dBase 3+ and Lotus, I regularly seek to compare data in fields/strings with existing data.
Just a reminder, you asked for input.
While some of this may seem obvious, I find these obvious things are the most often overlooked "features" in most rograms out there. Not just lottery programs, but most programs on the market.
Last, but not least, look at your program. Look how it functions of course, but most important look how the user functions with your program - not the other way around. If the user is confused, the program is less used. Find a way to make each frame understood to your user, even if it means placing a help block available at the touch of the right mouse button. Or, better yet, explain at the top of each window how the function helps the user. Available functions should be obvious, even to the uninitiated.
Neutroniumwave