Early Spot Play Betting

[km]

One of our members, Zimal2, asked me about the problem of dealing with test & query results without knowing the daily changes. In other words, he wants to make his bets in the morning before scratches and surfaces changes are known.

Scratches can influence results dramatically and promote a horse into a play that would not have been realized in the morning. Same goes for surface changes such as turf to wet dirt situation. A spot play dependent on specific parameters, such as K = 2, can be relegated to K=1 with a scratch, but its too late to change the bet, not to mention the horse will never be realized in a future test of K=2 causing conflicting results with our personal bet records.

Our test results with the robot or export are imbedded with winners that we may never have known about prior to scratches or surface changes.

There are ways to improvise tests and queries and deal with this problem. I'm going to research it for the upcoming newsletter and would appreciate your feedback here.

One method is to concentrate on factors that are immune from scratches and changes.

Example: TRN >= 400; Wk 85+

The trainer and workout ratings are not affected by scratches or change in surface. If a positive return can be found under most conditions, betting these early will yield the expected return and number of plays found in the test.

For the newsletter, i'll run tests that find the factors least affected by race changes.

[fred4now]

That is exactly why I keep my db like I do. It is setup before scratches or changes and then results added. Harder to explain than do. Anyway whatever I query it is exactly like it would be before changes so this way I can know if it will hold up the way I bet.

If anyone wants to know specifically how to do this just say so.

[dehere]

i'd love to know how to do that fred4now - thanks for the offer

[AwolAtHTR]

hi Fred

add me to your list for WANT TO KNOW

[fred4now]

I update by the month so this month I downloaded all the racefiles for October, but not the results or charts. run the export on these and bring them into a table I will call 2005noresults. Then delete the all_hx4.txt file and download all the results and charts for October. Run the exporter again and import into another table I call 2005results. Make an append query with all the fields from 2005noresults exept nfin, xwin, xpla, xsho, xexa, xtri, xsuperf, naodd, raodd and only the fields nfin, xwin, xpla, xsho, xexa, xtri, xsuperf, naodd, raodd from 2005results. (the first time you run this it should be a make table query and then change to an append query for future use). I name the new table 2005 and set trk, date, race, and pgm as primary fields.

Then query away on the 2005 table. I have macros run most of this and delete the 2005results and 2005noresults tables afterwards.

[AwolAtHTR]

thanks Fred,

your description could be used for an Access class on how and when
to use an APPEND query with the major issue about how to get started
by using the MAKE TABLE query. Also, with this being a monthly
issue, the macro driven task makes this a neat and complete solution.

oh, consider one variation: Download to a MONTHLY folder

then, when (not IF) there is a new, upgraded, HTR2 program,
the process could be repeated with the each month of data.

this will affect my solution when I take this off my back burner issues.

thanks again for your time to tell the processing story.

duane

[fred4now]

That is exactly how I keep my files, by month for each folder and then burn to CD by year.

[hurrikane]

Fred4now aka biker dude turned me onto this some time ago.

I do it a little different. I don't do an append I join the two tables instead.

I have a couple of reasons for this. One is I dont' use the huge flat table setup that the access sample uses. I have mine broken out into a relational db. A little more work but much better for me.

Second reason is that when (not if) there is an update to the export I only have to update the before races table and not the results as they are defined and cannot change.

[fred4now]

Glad you reminded me HK.
In the append query make sure you join the 2005noresults and 2005results by date, trk, race, pgm or you will have a lot of records;)

[fred4now]

That is a good point about updates to the exporter, it always creates lots of work.

I actually have a separate db for each year and then a master testing db. I can bring in something like HTR=1 for all races since 2000 in seconds and then query by overall, year, month or day.

[hurrikane]

that is a good idea Rick,

I was actually thinking of a way to break out fields by the data they use to avoid double dipping.

for instance. I believe the htr number uses fr1 as part of it's calc. If you use fr1 = 1 and htr = 1 then you are actually giving fr1 twice the importance and that can make for erroneous results.

Big problem is diggin though the news letters and seeing if I can figure out what calcs are used in the various ratings.

Of course ken could make my life easier and tell me...but the Massa one likes to make us think..keep our brains fresh. :D

[fred4now]

That is really an interesting thought. I hope Ken chimes in on this one.

[Victor]

Money is money so to answer Bob's second question, I'd say if you're making money, what more is there to say? If not, then there really is no "good answer" because it's just not practical to enter all the late scratches/changes/surface switches/you name it.

That's part of the "leap" we take as gamblers (define this word any way you want!). I fully appreciate what Fred4now says about building a database which trys to take this into account, but does it really? It's still an approximation (enter that word again, gambling.)

I have a real easy solution for this: ignore it and count the money. :)

[Bob]

Money is money so to answer Bob's second question, I'd say if you're making money, what more is there to say? If not, then there really is no "good answer" because it's just not practical to enter all the late scratches/changes/surface switches/you name it.

That's part of the "leap" we take as gamblers (define this word any way you want!). I fully appreciate what Fred4now says about building a database which trys to take this into account, but does it really? It's still an approximation (enter that word again, gambling.)

I have a real easy solution for this: ignore it and count the money. :)

Victor-

Like your way of thinking...SHOW ME THE MONEY!

Many years ago, I used to use a software program called "Morning Liner Plus V". I could "force" the winner to the top in 45% of the races in my database. Did it predict future winners? I bet you know the answer to this one. I have been very guilty of "backfitting" and analysis paralysis in the past.

Thanks for your words of wisdom.

Best,
Bob :)

[tomcat]

Victor.....surely not! How about Game Players?

[hurrikane]

so let me understand this Victor.

You know what you are doing is flawed - it's ok to keep doing it as long as it is working for now. :eek:

imo, this has nothing to do with backfitting. It has to do with building a database that is representative of real world risk in your situation.

If you play live and do scratches when you play then this thread is meaningless to you. But, if you place your bets early in the day then my advise would be to build your db with pre-results and post result rankings as that is the way you are playing.

IMO it help to use a differential ranking instead of just 1,2,3, etc. The number ranks don't give you the difference like say a kdiff does. theres a big differnece between a 9/5 mlo rank 1 and a 3-1 mlo rank 1. scratches do not have as much of an impact this way.

good luck to you