I’m interested so I’ll start the discussion on a practical system that can perform the task above. Replying to my own post very sad :?
Lets think of the three main design blocks as:
- PREDICTION ALGORITHUM SOFTWARE
- SPIN DATABASE
- TEST SOFTWARE
PREDICTION ALGORITHUM SOFTWARE
This block is the algorithum coded into a high level language (e.g. Visual Basic). This bit looks straightforward. The lookup method appears to work in Excel with good predictive capability once the spin data is captured - see the Visual Prediction topic post on 7th Sep 06 as a starting proof of concept. Can be extended to include the offset and error balancing and handling code.
Currently the algorithum looks I believe something like this:
- Pick a spin - load the ball/wheel trajectory into memory
- Start observing that spin data for ball/0# crossings
- Enter at the ideal Entry point (we can vary this parameter - that the model benefit)
- Clock the wheel speed
- Wait X secs (nominally 4.2, modified by the wheel speed for balancing)
- Calculate the number difference or angle (a simple lookup against the loaded spin trajectory)
- Multiply by 3 (for E2)
- Save predicted number and offset back to memory
- Loop back to 1 until we have done all the required spins
- Save the resultant test file for
The suggested implimentation would be Windows (I would use Visual Basic high level language).
SPIN DATABASE
This is the database of spins used to test the algorithum above. It would contain many differnet types of spin e.g. level, 0.5 deg tilt, 1 deg tilt, Huxley, Paulson, etc (basically whatever we wanted and had time to do and looked useful for system testing). Ideally it would contain many spins of each type - again limited by time to capture data only.
This bit would take some time. It took me about 10 minutes to map the video spin in my anaysis, hopefully this could be reduced to under 5 minutes per spin with practice. Remember we are only entering data so a seperate Windows file could be issued to all for data capture.
I would recommend that the database is basically just a set of flat files. Each file holding a particular set of spin data. This would then be easy to collect data for various sources.
As a long term vision it would be possible to actually model the ball/wheel and environmental parameterrs in software also and create a database of spins. I think that is a stage for later however.
TEST SOFTWARE
This is the overall controlling software component, the same Windows application as the algotithum just a differnt set of routines. Its the block that performs the following:
Pre Play : Select Parameters and model
- Loads a specific algorithm version to test (yes we can store old and concept algorithusm and rerun later!
- Lets us vary any particular parameters in the algorithums e.g. what if we use 4.4s not 4.2s (to enable searches for improvements)
- Lets us select the various bet spread patterns for optimisation analysis
- Select the data to use for the test run
Play : Runs te tests and Report
4. Loads spin data into memory
5. Runs the algorithum routine
6. Pulls the prediction and offset data together
7. Plots the resulkt tables/graphs
8. Potentially does some statisatical analysis (for later)
Implimenation
I would offer to write the Windows software for the spin data capture and the main application if there is sufficient interest and we can get enough data captured to make the project worth while.
In terms of spin data source I would recommend we satrt with the spin DVD Forester has reviewed and buy some more specific data from the supplier.
Feedback
So how does that sound ? Any thoughts anyone?