Quote: Originally posted by Colin F on February 18, 2004
The data you need to give would require you to construct a Conputer Model. This Model would allow you to set the number of draws to run, the number of games to play, whether the Draw Source is from a Lotto History or randomly generated, whether the games to play are from a filtered set or randomly generated and then it would need to calculate the wins. The number of Draws to run I would suggest as say 1234 and the number of runs say at least 5.
WINHunter already performs back testing based upon set parameters, so the only thing to implement according to what you said is a random number generator. This could easily be achieved using sets generated and provided via HTTP from Random.org. This type of test would ensure NON-local random generated data. This Random Number data source could be provided as another plugin .DLL, which could then be used by other softwares (Access, Excel, etc.) with ease.
I'm not sure I totally follow you on the back testing though. Do I understand that basically, you want the software to show random chance vs. the prediction engine? This would not be a major issue, but IMHO, will prove nothing about WINHunter. As stated earlier, a test like this will only prove the performance (or non-performance) of the stack you are testing. There are an infinite number of configuration options within WINHunter, which makes a test like this somewhat mute. I don't deny that it will help the user see how much better the stack would perform vs. random chance. But random chance changes with each test pass. One group of random chance might be the sorriest group of random chance ever conceived, while another group of random chance might blow away the best stack design capable within WINHunter to date.
Don't get me wrong, I am not trying to dispute what you are trying to say. In actuality, this test would only prove how well (or not so well) the person designed the stack itself. And in this case, it would be the software author (me). I myself, make no claims as to being able to design killer stacks. WINHunter was designed to enable the user to build filtering concepts not possible in other software. Perhaps WINHunter is too flexible.
Quote: Originally posted by Colin F on February 18, 2004
To construct this Model will take you a while. I've had another look at snippets of your code and one of the most noticeable things to me was the absence of SQL. I also observed that the way you were going about some things could be done much easier. My advice would be if you really want a strong input from others would be to move it to Access and give it a good Main Form where users can set parameters and view results.
SQL? SQL is only used for databases. What benefits will I gain by migrating to SQL and using a database? The draw history is provided by most lottery corp.s as ASCII text, with most of those having the draw date built into the history. All I have to do is import the data, and WINHunter has it's own semi-intelligent functions to help the user import raw historical data. This ensures that NO translation errors occured due to user input (whether it be the user, or myself). Maybe I am missing the point in a transition to Access and SQL.
Draw history is read into a drawings class object, which holds the draw data inside a collection of arrays. As far as performance goes, I have tried different methods and found the current method to be the fastest (from within VB, of course). The drawings object is passed from object to object, and thus any changes to the object itself are visible to all objects within the group. If you look at the tree display within WINHunter, the structure is displayed as it actually occurs in memory. Lower tier objects belong to their parent objects, and changes to a parent tend to affect the child objects.
As far as a Main form goes, what you see upon opening WINHunter is the main form. Most of the interactions occur with the tree itself. The MDI interface is used simply because there are so many forms the user can have open at once, that it was easier to keep them all bundled within the MDI interface. If you are talking about a main form where the user can make adjustments to just a few settings to control the workings of WINHunter, that just isn't possible. The settings within WINHunter can change based upon the underlying objects, and thus are unpredictable. A fixed main form doesn't make sense. In fact, if you look at the initial version of WINHunter (0.1.x), you will see how a fixed set of windows didnt work there either. For the most part, the windows themselves are just interfaces to the components. With exception going to some of the more intensive windows such as the filter optimizer, history scan and the history analyzer. Again, perhaps I am missing what you are suggesting about the main form. To me, a form ladden with buttons, combo boxes and option blocks limits the user to a fixed set of tools. Sure, when WINHunter opens, the user isn't presented with much information as to how to use the program. Discussions have been kicked around to add a tutor to the program. Online help pages have been developed as well as more details and "homework" added to the help file and discussion forums in order to help the user become familiar with how WINHuter can be used to the user's benefit.
Your right though, in the sense that something is missing. But you have to think of WINHunter as a development tool, and most development tools to date have cryptic interfaces (VB, C, Java, etc.), unless you know how to operate within it. WINHunter is useless without a user who knows or wants to know how to use/operate it.
BTW, what "can be done much easier"? Trust me, after having written WINHunter (3-4 times now), I am open to suggestions as to how to do things better. But what things are you refering to? Coding practices? Program flow? Variable usage? What WINHunter needs is speed optmizing changes. It doesn't need functions that cause it to crawl. Due to the already complex nature of how it works, it crawls on slower machines. The only "better" enhancements that I see possible from my standpoint, is a conversion over to C. But with VB.NET, Im figuring that a conversion in that direction won't much matter (considering the .Net framework and all).
Quote: Originally posted by Colin F on February 18, 2004
On another note lets keep personal abuse out of the arena; attack the ideas or the logic .
Colin F
I agree. I sense you are being very honest here, and you are not at all attacking the open source work I have been working on. Thankyou, I only mean to advance the effort, and I sense you mean to do the same! If I have offened you, then please accept my appology. With that, let's move on to the real issues. You bring up excellent points. Now only if you could elaborate more on them! You won't hurt my feelings if you even go as far as to quote WINHunter "code" here. WINHunter is opensource, so feel free to markup stuff openly.