I got the time decayed idea from how the RDSS — Lawrence

Yes, Ted told me how to do the CSR, so I applied the logic to my BRIS file. I also did it with the 2f, 4f, 6f and LT pace figures. I see Dave has the time decay EP and LP... I would think those are very useful numbers. While a high LP number is not mandatory, a poor LP figure is a very suspect horse from what I have seen.

Sounds like a very interesting project! I like that idea of a time decayed race class level.

I do a time degradation on the last 4 4f pace ratings. That's good for race shape, but I don't know how that fits into chaos.

For me, Chaos is when early speed falls apart. Horses known to be closers often win and sometimes at a big price. Most really fast final times are run fast throughout, so when early speed falls apart, a history of high speed ratings is not always required to win. I believe the entire process is predictable.

Hey Rick- Just for clarification, did you mean less than 15 speed points in the race? Thanks in advance for the clarification. — Tony Kofalt

Divide the highest QSP by the total QSP for all horses. If it is less than 15%, the premise is that chaos is possible.

It's not the whole pace picture.

I do a composite rating on the last 4 races degraded using Fibonacci for the BRIS pace ratings -- 2f, 4f, 6f and Late. That with my pressure rating, QSP and %M numbers give me a pretty good picture of pace. Then I also have regular Sartin style pace factors and my own closing points.

I am a firm believer that looking at anything just one way can give a wrong impression.

I think I see the premise for your number. The whole field is supplying more pressure than the high pressure horse can withstand. I have added that to my program to see if I find merit. Thanks.

Yes, I believe I understand now. So, your example would qualify because 7 is less than 15% of 47.

I also have my own number that I call "pressure", but I haven't found a correlation to chaos for it.

Have either of you two tried/tested Quirin Speed Point percentage? When it's less than .15 weird happening occur. — Biniak

No, I am not sure I understand. 15 percent of what?

I look at the top 3 Quirin speed figures because that is what will usually drive the pace. I also look at the Giles high Quirin count.

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.