System Model and Test Harness

It woukld appear useful to have a way of quickly and accurately anlaysing the prediction system and potentail modifications to gain insight and to save the long winded process of having to perform video analysis and/or real play testing each time.

The functional design overview of such a project is:

  • build a model of the prediction system in software
  • capture lots of spin data for different play conditions e.g. level, tilt, etc.
  • build test software that stresses the predictive model

The purpose of this post is to :
a) assess the interest level for such a system,
b) if there is interest to discuss the specification of such a system.

Feedback please … even if its just a vote

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:

  1. PREDICTION ALGORITHUM SOFTWARE
  2. SPIN DATABASE
  3. 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:

  1. Pick a spin - load the ball/wheel trajectory into memory
  2. Start observing that spin data for ball/0# crossings
  3. Enter at the ideal Entry point (we can vary this parameter - that the model benefit)
  4. Clock the wheel speed
  5. Wait X secs (nominally 4.2, modified by the wheel speed for balancing)
  6. Calculate the number difference or angle (a simple lookup against the loaded spin trajectory)
  7. Multiply by 3 (for E2)
  8. Save predicted number and offset back to memory
  9. Loop back to 1 until we have done all the required spins
  10. 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

  1. Loads a specific algorithm version to test (yes we can store old and concept algorithusm and rerun later!
  2. 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)
  3. Lets us select the various bet spread patterns for optimisation analysis
  4. 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?

gkd

On my first read of your post (and I haven’t yet read your Visual prediction comments) I don’t understand everything you are saying but my thoughts are…

  1. You are not yet aware of the significant recent developments Forester has made and I suggest that you ask him for permission to Join The Boys Club if you can convince him that you have no Casino management links.

  2. Your proposal fits nicely with Forester’s recent work and especially the problems experienced in finding bugs and some so far unexplained variations.

  3. We will always have difficulty in determining actual Casino wheel tilt amount unless we get access to an actual wheel in laboratory conditions. But we may be able to set our own figure for degree of tilt based on the percentage strike of one or more diamonds from accurate data recorded in Casino’s.

  4. We need to accurately record identification details for actual Casino wheels and rotors and balls because there is sometimes a different rate of ball deceleration in the last few revs before the drop off point. We have also recorded an occasional rotor that decelerates much more rapidly than normal and we need to record and identify these things so they don’t provide upset conditions to our play.

  5. I trust you are aware that almost every serious student of the game will still have personal control factors influencing firstly the accurate recording of data in the Casino but more importantly actually putting the final strategy to profitable use under Casino conditions? It is very difficult but it can be done and it has been done.

More later I’m off to PNG for 2 weeks via Cairns Casino now

Mike.

Mike

Great news, sounds like Forster is already considering a test bed approach.

I have two friends that are now bankrupt from playing and I know the game is beatable, that is my motivation. As the restricted area is there for good reason I think the best idea is to be patient and let people make their minds up in their own time.

Getting good quality realistic spin data would be essential. I understand from an earlier post by Foreter that there is a source of DVD spin data constructed under requested conditions, i.e. we could request special setups such as a wheel with extra friction. This is a good cheap starting point.

Recording data in casio is useful as you say for a wide spread of wheel designs and conditions. However, getting accurate enough data for test conditions limits the collection method used. The best would be video in casino and then off site analysis, e.g. the odd zero crossing missed on the video would not matter as we can curve fit. This may also be an intersting avenue to consider for ‘bespoke’ wheel setups, i.e. a user sends in some video of the target wheel in play, we analyse and then download or input specific paramers to the unit for play.

If we are really serious then investing in a wheel, using opto-coupler sensors (auto data capture) and modifyig variables such as tilt, wheel speed, wheel friction, etc looks like a really worthwhile investment. It allows for simulating specific problem conditions encountered. Second hand, good quality, full size wheels are available at resaonable prices, well if you think US£3k is reasonable.

Have a great holiday and good luck at the Casino !

Why not go for a more traditional computer style.

Basic.

  1. Callibrate rotor speed

  2. Predict strike diamand

  3. Either add average scatter, or more sophisticated, calibrate each diamonds average strike lenght.

  4. The computer then, pin point the rotor, reckognize a certain ball decelleration scheme, predict the the strike diamond from decelleration scheme (based on previous spins) and then adds scatter lenght while relating to the rotor speed.

Wupti, you got a prediction.

I don`t think we need to go too deep in the different causes that alters the schemes as long as we test on the same closed circuit. (Wheel + ball).

Predicting the strike diamond instead of the number, i think simplifies the model a lot.

This is how the known computers works. (I don`t know about foresters, Marks and stefanos) but the computers used in real play in Europe and the US (Copernicus mainly Scott).

Kelly & Co

There is lots of sense in what you are saying here and coupled with Forester’s terrific work I think we could make a major step forward.

I like the idea of calibrating bounce and scatter with particular diamonds especially on tilted wheels and especially separating for both ball directions.

Tnaks for the wisdom

Mike.

Calibrating the diamonds, should stand in close relation to the wheel speed. The wheel speed has a major impact on the bounce but i suppose it could be possible to add a factor to the bounce lenght to each 0.05 sec the rotor goes faster/slower.

Anyway, thats what visual players does. Just using human estimation.

Example:

Calibrate rotor: 3.3 instead of 3.6.
Add 9 pockets for the rotor position.
Add another 3 pockets for the extra bounce.
Adjust 12 pockets for observation point.

just an example, the values differs slightly depending prediction time (remaining spin time) and ball type. (Bounce lenght)

Sorry guys i did not see this post at all.
And i am not sure if i understand it well.

Do you talk about improving E2.

It is hard E2 will always have errors in prediction.
One of options is to define time but to observe only ball.
E2 is limited, because when the ball is slowing down significant part of change is more and more done by rotor.

If we observe only ball change based on wheel frame, we have wider options but we must estimate change in rotor speed because it would not be included in prediction at all.
If we before applying e2 on the ball, measure rotor, then by that data manipulate reference time we can get something. Example time is 4 sec for 3 sec rotor. Next spin rotor is 4 sec so lets say we reduce time by 0.4s.
then problem is that we never know exactly are we at 16 sec to the end or 14s.
So 0.2 sec will not generate same distance because we are at different ball speeds.
And do not forget that difference gets multiplied by 3.

Lets say we start e2 at 14 sec to end and we get 6 ball rotation for defined time.
If next time we get 7 rotations it means that we started 3 rotations earlier.
All in between 6-7 should be reasonable prediction.
But if in time frame we get 7 + errors are increasing faster, same as if we start getting under 6 rotations.

I think that I post replay to another post here. Sorry.

GKD, I am not sure for need of such software.
Every developer would find his own way to test his design.
When I write program for microcontroller I have options to test it with any data selected as input. Also option to disable some parts of program, for example to test only error of clocking correction based on different conditions. Software test is not the only test that is required, additional tests where performance of hardware is involved is important as well.
That test can also be done in different ways and probably needs to be designed differently for different computer designs.

I would agree with Kelly and his way of adjustment for different rotor speeds.
Any adjustment done buy software could only come with additional problems. Same looking wheel and ball may behave differently.
Therefore I would leave that part to player and human estimation. Simply do not play significant differences in rotor speed, or be able to observe it. Slow rotor speeds from 4s+ would not make much difference. Once rotor is under 3 sec there is to many factors that may influence final result.