|| Horses not showing up in Individual Plays in Data Window when running UDM
Friday, 3 UDM's I have at GPX came up with a winner on Friday. When I run the UDM's through individual plays, the horse is only coming in 2 of the UDM plays. I deleted the original JCP and XRD file, re-downloaded it and still nothing. I'm hoping I did nothing to my database.
I'm in playlist mode. I have set up a quarterly folder structure. There are no 2015 data files in the 2016 Q1 folder.
When I started a new database for 2016 Q1, I did as you told me to do MODE 4 for database build and have used MODE 5 to append.
|Q. Were there scratches or other (surface-distance, etc,) changes in the race for the play that's not showing up in the Data Window?|
I ask because that's the most common cause when this happens to me.
Almost all of my UDMs are based on factors that change when horses scratch out, a race comes off the turf, or has a change in distance, etc.
Let me know and we can go from there...
|in this particular race, there were no scratches and it was a dirt race.|
|I'm going to need the UDM Definition in order to run this down for you.|
Can you do one of the following?
UDM Definitions are stored in the c:\2004\JCapper.mdb file. Attach the file to an email (be sure to include the name of the UDM in your email) and fire it off to me.
Run the UDM through the Data Window - and then cut and paste the Data Window output (the part that shows the UDM Definition) into the body of an email and sent it to me.
Or - if you'd rather not share the full UDM Definition - shoot me an email that contains just the factor names and filter codes in the UDM Definition.
Send your email to:
jeff @ jcapper . com
(remove the blank spaces first)
From there I'll do my best to run it down for you.
|Haven't received an email. (FYI, my offer to hunt this down for you still stands.)|
Scratches and surface/distance changes are the most common reasons for what you are describing.
I can think of an alternate scenario where this can happen - and posted at length about it on the old/original JCapper Message Board.
The alternate scenario involves a change to FormRating.
Q. Does your UDM use FormRating?
If so, you might want to read my post (the 4th one down from the top) in this thread from Aug 2014:
FYI, my post in the above linked to thread links back to a post I made back in 2008.
"I use FormRating in most of my UDMs (and likely always will.)--end quote
That said, I need to make it clear that FormRating is unlike the other ratings in the program in that it contains a random component that - every once in a while - is going to be different on race day when the Calc Races button is clicked vs. what gets persisted when the Build Database button is clicked.
It's a behavior that has always bothered me - and at the same time - it's something I have never been able to solve.
Over the years I've had to learn to live with.
I posted about the behavior of FormRating at length on the old/original JCapper Message Board (if I recall correctly) as far back as 2005.
That said, the old/original JCapper Message Board is no longer accesible.
Using THIS message board's search link - I came up with a thread from 2008.
In the second post down from the top I described the random part of FormRating along with the scenario that sometimes causes it to change from the point in time when the html report is run to when the Data Window is later run:
"FormRating - This number represents a horse's current form relative to the rest of the field. Horses with improved performances in recent races and workouts are awarded points while horses with declining performances in recent races and workouts receive point deductions. Benchmark testing of the FormRating has revealed the following: horses ranked highly in FormRating substantially outperformed horses ranked poorly in FormRating, both in terms of win rate and money returned. --end quote
Note: The original FormRating in JCapper is based in part on an element that simulates random improvement or decline. Much has been posted about this on the JCapper Message Board. Because of the way random numbers are referenced in Visual Basic, other programs running outside of JCapper have the ability to overwrite the area in memory where random numbers are stored. In a small percentage of cases, this casues the FormRating to be a moving target and tough to nail down when comparing the FormRating shown on the HTML Report and later in the Data Window after a Build Database has been run. I have tried to the best of my ability to address this issue but as of this writing a true solution has evaded me. During all of my tests, a JRating using a FormRating containing this random element always outperforms a JRating based on a FormRating without this random element. For that reason alone I have left JCapper's original JRating and FormRating intact. (Accessible via the Profile Table Interface)
AFR - or Advanced Form Rating - This number represents a horse's current form relative to the rest of the field. Horses with improved performances in recent races and workouts are awarded points while horses with declining performances in recent races and workouts receive point deductions. Becnhmark testing of the FormRating has revealed the following: horses ranked highly in AFR substantially outperformed horses ranked poorly in AFR, both in terms of win rate and money returned.
Note: AFR (or Advanced FormRating) is an improvement over JCapper's original FormRating. AFR uses a slightly different factor set than FormRating. AFR is a "hard" rating that doesn't use a random element. I've included it in JCapper's factor set and made it one of the "grab-able" factors so that those of you who wish to use it in UDMs and in the factor mix of your own User Defined Power Ratings can do so. In benchmark tests, AFR does a better job of predicting the outcome and has a higher flat bet win roi than the program's original FormRating does.
(Accessible via the Profile Table Interface)"
The above quoted text provides background info into what's happening behind the scenes.
I'll try to provide a little more depth below:
One of the things that gives FormRating the ability to add roi to a UDM is the part of its makeup that is based on a random number.
My intent on adding a random component to FormRating was to simulate the sometimes random swings (good race one time vs. bad race next time) seen in the performances/running lines of individual horses.
Will he run a good race today? Or will he run a clunker?
No matter how strongly everything looks like it lines up there's always a pct chance that performance today differs greatly from what we expect.
About 90% plus of FormRating is hard coded and never varies.
The remainder is based on random numbers representing different aspects of improvement or decline. These random components are generated on the fly. The algorithm I created writes these random numbers to a specific area in ram memory that's supposed to be reserved for VB.
Most of the time everything works as designed and horses flagged on the html report by UDMs using FormRating are the same as those seen later in the Data Window. (My testing reveals that when this is the case the area in VB where the random components of FormRating are being stored remains untouched by other apps running on the machine.)
But every once in a while the area in memory where the random components of FormRating are being stored get overwritten by another app running on the machine - or become corrupted by some other cause.
When this happens the random number elements going to FormRating change - and FormRating changes right along with them - and the resulting change in FormRating can cause the scenario I think you are describing.
It's a "bug" I was never fully able to solve.
My first "solution" - if you can call it that - was to create a new form rating factor called AFR - one that does not contain a random element.
Because AFR does not contain a random element, if you use AFR in a UDM instead of FormRating - horses flagged by the UDM on an html report should always be the same as those seen in the Data Window... barring scratches or other changes within the same race.
My next attempt at a "solution" - again if you can call it that - was to add the UPR and JPR Gap Rev buttons on the User System Definitions Screen.
Hint: The settings persisted on my own User Sys Defs Screen are shown at the top of the Help Doc: Here.
Note that I am using my own UPR GroupName to drive UPR and that I have the UPR Gap Rev box checked. I recommend you do the same. Checking the box causes the random components of FormRating to be handled in a slightly different way. This does not eliminate the possibility of the area where they are stored in ram memory to be overwritten during a build db routine - but it does cut down on the incidence rate.
If you are using a UPR GroupName to drive UPR check the UPR Gap Rev Box. If you aren't - consider checking the JPR Gap Rev Box.
Important: After checking either box, you'll want to rebuild databases from scratch and look at your numbers in the Data Window - and note any changes in UDM performance that result from checking the box(es.)
Despite the fact that the random components of FormRating sometimes get overwritten in memory during a database build - I find that my own long term results from live play are better when I include FormRating in my UDMs vs. not using FormRating in my UDMs."
|Been away for a bit, I just fired you an email, Jeff|
|Got it. (Email received.)|
Partial Screenshot here:
Note: The above is a partial screenshot. (I've clipped it so as to not to make public the full UDM Definition.)
Here's what I see...
The UDM Definition (among other things) has the following:
Class Descriptor: C-CO
My .JCP file has the race in question (GPX 01-08-2016 R8) as Class Descriptor: AO
Based on that I would never expect to see the UDM flag a play in the Data Window. (And it didn't.)
The screenshot you sent DOES show the UDM flagging a horse on the HTML Report.
Partial screenshot here:
Two possible scenarios come to mind:
Is there any chance at the point in time on the race day in question (Jan 8, 2016) when the Calc Races button was clicked that the Class Descriptor part of the UDM Definition hadn't been added yet?
If so, and if the Class Descriptor part of the UDM Definition was added afterwards:
That would be one possible scenario I can envision that would cause what you are reporting.
Is the .JCP file you had at the point in time when you ran the Calc Races that generated the HTML Report in the screenshot you sent me different than my .JCP file?
My .JCP file has the race in question (GPX 01-08-2016 R8) as Class Descriptor AO.
I downloaded my .JCP file the morning of the raceday in question... Jan 8, 2016. (Not before.)
It's rare (and I can check with Ron Tiller at HDW to see if this happened or not) but...
If Gulfstream initially reported the race in question to Equibase as CO and later corrected it to AO...
That would be the other possibility I can envision that would cause what you are reporting.