By the way, I offered up my little experiment just as food for thought, not a serious attempt at any sort of system. Just to show that wagering is important.

I did a little experiment. On today's 3rd through 9th races at BEL, I funded $20 per race with 25% flat bet (on 3 horses) and the rest dutched on the same 3 horses... the top 3 Bris Prime horses based on ELO matchup. I used my odds line (similar to Tom's Ultimate Odds Line) as the basis for dutching. So, with no handicapping, I got 6 of the 7 winners. The total outlay, $20 x 7 was $140. The return was $140.50.

My only point here is that how you wager is important. I'm sure if I played around with this it would be possible to have better results. But I got a tiny profit with NO handicapping while betting THREE horses per race.

Thanks, Dave. I modified my program to allow a flat %.

Also, I think this is a dirt only method. Definitely not for turf... they all have low %M. May not work on All-Weather, though I just watched a winner pay $14.60 at GP, R11. But there were 3 playable horses.

I'm still refining.

A\.t least 6 horses are required, preferably 7 or more.

The horses need to have been away with good position early while not exerting high %Median. So, there needs to be some Quirin points. I'd say the top three Quirin horses should total a minimum of 15.

If there's an odds-on horse, be wary.

As for what your friend told you, I don't think that's necessarily contradictory to my approach. I would think that horses not running to par are frequently not exerting early energy (low %M).

So, I would think that both approaches are worth tracking.

I know that it is not unusual for me to find 10+/1, even 20+/1 horses with my chaos approach. But, admittedly, more precise testing on a defined approach needs to be done. But, at these odds, there appears to be some wiggle room.

(If you want to know how it works, I'd be happy to show you.) — Dave Schwartz

/
What language are you using, Dave?

I've looked at a bit of the book and I would like to share something that came to mind.

Programming projects are based on requirements. The better defined the requirements, the better the programmer can expect to meet those requirements. Then comes the caveat for the handicapping programmer. We are always looking for ways to improve not only our programming, but our core requirements. Maybe we should shift more toward Sartin methodology or speed or class or beatable favorites or form cycles or whatever our personal buzz word is today. Maybe we have found a better approach to Artificial Intelligence or research. It is very easy for our program to not even resemble our original program.. not just because we have a new menu system or a new way of managing windows, but because our requirements have drastically changed beyond anything we ever envisioned.

So, i think in this type of programming, we should anticipate that periodically a significant clean up will be required... regardless of how well you've cleaned up along the way. And that makes the cleanup along the way that much more important.

No, I have not read that book. I will take a look later today.

There are ways to produce self-documenting code. For instance, if you have an array of differing values, you can self-document the elements.

If your language permits defining constants, you can do this:

#define hQUIRIN 1
#define hSPEED_RACE_1 2

local aValues := {}

// SIZE the array in your language here

aValues[hQUIRIN] := MY_FILE->QUIRIN
aValues[hSPEED_RACE_1 := MY_FILE->SPEED_1

If your language does not support defining constants (most do), use a variable with the variable type denoted in the variable name. In this case, I use "n" as the prefix for a "number" and "a" for "array".

local aValues := {}
local nE_Quirin := 1
local nE_Speed_Race_1 := 2

// SIZE the array in your language here

aValues[nE_Quirin] := MY_FILE->QUIRIN
aValues[nE_Speed_Race_1] := MY_FILE->SPEED_1

Do not reference the array like the following because it will be very difficult to read later:

aValues[1] := MY_FILE->QUIRIN
aValues[2] := MY_FILE->SPEED_1

You could end up with this unreadable code:

nMyCoolNumber := aValues[2] / aValues[1]

Instead, write it like this:

nMyCoolNumber := aValues[hSPEED_RACE_1] / aValues[hQUIRIN]

One solid hit like that per day will keep you going. Nice score! — William Zayonce

Just like golf.

No bueno, 3rd, 4th and 5th.

R9: 10 8 9 7

Made up for the earlier trash. 10-7, 10 at 24-1. Exacta paid 117.00

R8: 7-10-3-9

They lulled me into the front end mindset and the 2 comes from off the pace, a horse that figured, paid $41.40.

R6; my 4th choice won, should've been stronger in my opinion on that one. No horses are closing any ground.

R7: 4-5-6-1A

I'll give it another try. R6: 2-1-5-3

Sheesh, I can't pick my nose today.

Lots of possibles in R5. I'll say 4-5-6-8. 8 seems low priced at 3/5.

R4: The Clement firster got it paying $17 to win.