JCapper Message Board
How To - UDM Questions
|| How To - UDM Questions
I can not seem to be able to figure these out and haven't found anything on the boards. I have a few questions on how to do and SQL UDM to identify the following:
1. Horses that have met before
2. Horses that have moved to a better rider (say .05 better win%)
3. Horse has won a graded race before
4. Horses that were scratched in last race
5. When a horse has an age advantage
|If items 1-4 are important to you - you'll need to do most of the work outside of JCapper.|
"1. Horses that have met before"
Not part of JCapper at all. I'm not saying won't find occasional cases where value can be had. However, I did look at this back in 2001-2002 when I did the initial R&D for what to include in JCapper and what to leave out.
ed Horse B last time (or 3 starts back, etc.) and the order of finish between the two is reversed in today's race...
More often than not, indicators (JCapper factors) based on how the horses in today's race stack up against each other such as Power Ratings and/or individual factors based on speed-pace-form-class, and secondary areas such as connections, breeding, track profile, etc. point the way.
In other words - whether or not A beat B last time - or whether they've faced each other at all... That pales in comparison vs. how they stack up against each other in today's race in terms of JCapper factors.
"2. Horses that have moved to a better rider (say .05 better win%)"
This does matter so far as shaping win percentage.
However, rider changes (unless you are dealing with a fairly new rider who is still 'under the public's radar') is an area very much reflected in the odds.
FYI, if you are operating the program in PlayList File Mode, there are preset filter codes (JSWITCH and BSWITCH) for rider change and trainer change. Link, to an older thread:
That said, nothing exists in sql mode for this.
One idea I have experimented with is creating an expanded sql factor setup interface that enables the user to make the program write RiderLastOut and/or TrainerLastOut to any of the other "name" fields in the StarterHistory table.
For example, if the user decided he or she wasn't ever going to use the DAMSSIRE field he or she could use the expanded interface to persist a setting to make the program write RiderLastOut or TrainerLastOut to that field instead of the Dam's Sire.
This is something (there are a LOT of somethings) I've been quietly working on.
I'm still a long way from having it finished to the point to where it's 'bullet-proof' enough that I can publish it...
But if and when I do get the interface tested and finished - you'd then have the ability to write sql UDMs that can handle any and all permutations of RIDER-RIDERLASTOUT-TRAINER-TRAINERLASTOUT, etc.
From there, whether or not RIDER today represents improvement or decline vs. RIDERLASTOUT is something you'd have to research out yourself. (But the R&D for that is easy enough to do in the JCapper Data Window.)
"3. Horse has won a graded race before"
Not part of JCapper at all... mainly because it never occurred to me to create an indicator that can be written to a database - either a simple True/False - or alternately a numeric counter to hold the number of G1 wins. Of course once it's written to a database - from there it's not that hard to test how much something like that is actually reflected in the odds.
Can't make any promises here. Like I said earlier there are A LOT of something's currently on my plate.
"4. Horses that were scratched in last race"
If this is something you want to track you are going to have to do it on your own outside of JCapper.
FWIW, JCapper Scratch BOT writes Vet Scratches to the TripNotes table. When I did the programming to make this happen my thinking was this info was going to have value - or at least a lot more value than it actually turned out to have.
Many (possibly most) vet scratches are not vet scratches at all. On the East coast, a "Vet Scratch" often happens when a trainer enters in multiple races at multiple tracks and waits to see who else is running before scratching. (FYI, getting a vet to "rubber stamp" the scratch can be the trainer's way of scratching the horse in such a way so as to not piss off the racing office.)
I have analyzed the Vet Scratches sitting in my TripNotes table in hopes of equating them with trainer intent - believing (ahead of time) there ought to be a boost in roi.
I certainly haven't seen anything in the data that would make me want to reprogram Scratch BOT to write ALL scratches to the TripNotes table. Nor have I seen anything that would make me want to reprogram the Profile Marker and UDM Wizard so that scratches in the TripNotes table can be accessible in sql UDMs.
That said, if this area does interest you - and it is certainly possible that a player following single trainers might well come to a completely different conclusion than I did... I was looking at it in terms of scratches in general not scratches by individual trainers -- I say have at it. You can certainly export the contents of your TripNotes Table out to a .csv file using the JCX File Exports Module... and from there pull VetScratches from the CSV file into Excel or another 3rd party app.
"5. When a horse has an age advantage"
This one you actually CAN do in sql mode (completely) from inside of JCapper.
The strategy for getting it done involves creating a UserFactor that behaves as a direct translation of AGEOFHORSE - and from there using the Gap field for the F-Slot Number in your SQL Factor Setup that your UserFactor is assigned to.
Here's a link to a screenshot of the UPR Tools Interface where I've hand keyed the entries:
These are the steps...
In the UPR Tools Interface:
1. Delete all previous entries for the UserFactor you decide to use. For example, if you are going to use UserFactor1 for this, delete all existing UserFactor1 entries first.
2. Click the NEW button.
3. Key the name of your UserFactor into the GroupName field. Note that in the above linked to screenshot I am creating UserFactor1 and have keyed USERFACTOR1 into the GroupName field.
4. Key the name of the factor you will be replicating into the Factor field. Note that in the above linked to screenshot I am replicating AgeOfHorse and have keyed AGEOFHORSE into the Factor field.
5. Key a numeric 3 into the Behavior field and hit the tab key to move the cursor out of the Behavior field. As soon as the cursor leaves the Behavior field, the interface will auto change the value sitting in the Behavior field from "3" (without the quotes) to "3 translate" (again without the quotes.)
6. Select ALL* from the surface-dist drop down. Or, alternately, you can select a specific surface-dist category if that is your intent. (The important thing is to not leave the surface field blank.)
7. Check the Active box.
8. Click the SAVE button.
At this point, provided USERFACTOR1 is part of your sql factor setup, the next time you click the Calc Races button (or the Build Database button) AgeOfHorse, rankForAgeOfHorse, and GapFOrAgeOfHorse are going to be written to the appropriate numbered F-slot fields that your UserFactor is assigned to.
From there, to evaluate "When a horse has an age advantage" in the Data Window you would look at Gap for the numbered F-slot that your UserFactor is assigned to. And of course in a sql UDM you would use the GAP F-slot number field that your UserFactor is assigned to. (Behavior in the data for this field in sql mode is identical to that of the Age of Horse Gap field in playlist file mode.)
For example, if your UserFactor is assigned to slot F01 and the scale of weights and time of year at a track you are playing are such that you think a 3 year old has an advantage in terms of maturity combined with assigned weight - the following three lines of sql might be useful in a layering UDM:
AND TRACK = 'XYZ'
AND AGEOFHORSE = 3
AND GAPF01 < 0
The first line ensures your UDM is flagging horses at track code XYZ only. The second line ensures your UDM is flagging 3 year olds only. The third line ensures that the 3 year olds flagged by the UDM are racing against one or more starters older than 3.
Alternately, if time of year and scale of weights for a track you are playing is such that you think 3 year olds are up against it because of too much weight assigned given level of maturity - the same 3 lines of sql might be useful in a negative layering UDM.
Hint: If USERFACTOR1 (or the UserFactor that you use for this) is not part of your sql factor setup, here is a link to the 4 part web tutorial for modifying the sql factor setup: