|
JCapper Message Board JCapper 101
|
| Home |
Register
Log In |
| By | Jeffs Track Profile | |
| SILVER01HDW 8/19/2015 12:24:10 AM | Jeff - Is it possible now, or possible to work on for the future, making a track profile that shows running positions and beaten lengths by track, surface and distance and the first, second and final points of call? Kind of similar to Brohamer's track model? Thanks, KP
| |
| jeff 8/20/2015 6:52:05 PM | It's possible this might be something I'd consider adding in a future program update. But for the time being (while I build out new program features that I've already started work on) this is something that has to be put on hold. FYI, I think I last read Tom Brohammer's Modern Pace Handicapping sometime in 2012. I had gone through it in 2008 - and if memory serves - I subjected both the Decision Model approach and the Track Profile approach presented by Brohammer to hard database testing. (About a year's worth of current race data going from memory.) An roi analysis of CPace rank=1 horses that either "fit" or "didn't fit" my interpretation of "track profile" suggested by the two approaches revealed (at least at the time) that of the two approaches: The Decision Model approach generated more bang for the buck roi-wise than the Track Profile approach. Based on that I did the design work and coded out a Decision Model approach which I then implemented into JCapper in the form of the Track Profile Export and its companion report generator. Off and on over the years (especially after rereading Modern Pace Handicapping) I have made several attempts to implement the type of decision model approach suggested by Brohammer into my own live play. My attempts at this have been, well, I'll just say they have been less than stellar. In my opinion there are several reasons for this. First, my copy of Modern Pace Handicapping bears a copyright date on the title page of 2000. The percentage of casual money in the pools back then was much greater than it is in today's game. (As I type this it's August 20, 2015.) Also, avg field size was bigger back then. Combine the two and the game was easier to beat back then. I know this from the untold thousands of hours of database testing and r&d I have done while looking for and analyzing public betting trends. So it follows that a player using a decision model approach back in the mid to late 1990's (like Brohammer and especially if he were one of the few who even knew about it) would have had a much easier time making a successful go of it than I did some 8-12 years after it had been published in a widely read handicapping book. All of that said I do make decisions about track biases - both big picture and recent/short term. And I do implement those decisions into my own live play on a daily basis. And before anybody asks - Yes I absolutely have been able to do so both consistently and successfully. I'm sure most of you have at least looked at the Track Weight Report in the Data Window. I'm also sure that most if not all of you who have done that have not only been confused as to what it is you are looking at on the report itself - but remain almost as confused even after reading the explanations about the track weight report that I have posted on this message board. The most common question I hear about the track weight report goes something like this: How can the surface be labeled as 5.0 speed tiring when CPace rank=1 horses have a positive roi and CompoundLate rank=1 horses have a negative roi? This post is already longer than I expected going in. I'm going to stop here (for now) and come back and add to it as free time allows. -jp .
| |
| jeff 8/22/2015 1:17:33 PM | Picking up where I left off... The algorithm in the track weight report that calculates the value between 1 and 5 (or the "label") used to describe the speed favoring or speed tiring tendencies for the track surface in a data sample basically does the following:
(After rereading that I'm guessing I still lost most of you.) If that's the case it's ok. The important thing to take away from a track weight report is that behavior of track surface in a sample (or the degree to which the surface has been shaping race outcomes) can be quantified in a way that is statistically meaningful. True, behavior of track surfaces can vary widely from one track to another. True, behavior of the surface can also vary widely at the same track code from one distance to another. True, behavior of the surface can also vary widely at the same track for the same distance when different run up distances and/or different temp rail placements are used. True, behavior of the surface can also vary widely at the same track from one time period to another (be it a day, a few days, a week or two, a month, a meet or even a year.) Despite that you can still pull up the Data Window and execute sql queries with the data broken out by Track Weight Report and see at a glance the degree to which a given track surface has been shaping race outcomes. --EDIT - the following block of text was added on 08-22-2015: Based on the idea that the numeric track weight displayed on a track weight report represents a statistically meaningful observation about the degree to which a surface has been shaping race outcomes: It is possible to create algorithms designed to score how strongly (or how poorly) any given horse "fits" (or fails to "fit") the type of track profile suggested by the "label" values between 1 and 5 used to describe track weight on the track weight report. In the upcoming Platinum program update there's a new factor in the WagerHistory Module called Track Profile Fit. This factor is also available in UPR Tools - meaning those of you who want to can work it into your UserFactors and UPR. Below is a link to a text file containing data samples for CPace rank=1 and EarlyConsensus rank=1 horses with the data broken out by Track Profile Fit: http://www.JCapper.com/MessageBoard/Reports/Impact_Study_08222015.txt Note that all CPace rank=1 and EarlyConsensus rank=1 horses are not the same. The stronger the track profile fit the stronger the win rate (although not always the case for roi - which suggests some interesting possibilities.) --end edit Here's a link to a thread where I posted some example sql queries that can be used to drive a track weight report: http://www.jcapper.com/MessageBoard/TopicReader.asp?topic=1680&forum=JCapper%20101 Note that I used the term situational queries in the above thread. I have to stop here - and will come back and add to this thread as free time allows. -jp . ~Edited by: jeff on: 8/22/2015 at: 1:17:33 PM~
| |
| jeff 8/21/2015 4:47:27 PM | Picking up where I left off... Q. What do I mean by the term situational query? A. A situational query is a sql expression tailored for the situation at hand. Here's a link to a thread titled Statistical Programs: http://www.jcapper.com/messageboard/TopicReader.asp?topic=1799&forum=General Click the above link and scroll down to the post I made on 3/20/2015 at 11:47:55 AM. In that post and those that immediately follow I posted some examples of situational queries along with some thoughts (pre race) where I employed situational queries to reach a pass decision on a losing horse I would have otherwise bet. Because it was posted in the private area of the board you'll need to be logged in before you can read it - but here's a link to a thread where the topic was the 2015 KY Derby: http://www.jcapper.com/messageboard/TopicReader.asp?topic=1838&forum=Private Hint: The above thread contains lots of situational queries. Where am I going with this? Situational Queries involve a LOT MORE WORK than the Track Profile and Decision Model approaches suggested by Brohammer in Modern Pace Handicapping. My opinion (based on hundreds of R&D hrs spent in the Data Window this year, and backed up by some really good recent results at the windows) is that Situational Queries (in the right hands) appear to offer much more potential than the Track Profile and Decision Model approaches suggested by Brohammer in Modern Pace Handicapping. I also suspect that the a LOT MORE WORK and the in the right hands aspects of Situational Queries have both played a part in shaping my own recent results at the windows. I've been quietly working on building some canned Situational Queries reports into JCapper. Here's a preview: http://www.jcapper.com/MessageBoard/Reports/SQxReportPEN07312015R6Horse8.html Currently, as I type this, there's a new button in the WagerHistory Module in the next Platinum program update you can click to generate the above report. The report is driven by situational queries for rail position at the track-intsurface-dist, early consensus rank at the track-intsurface-dist, late consensus rank at the track-intsurface-dist, rider at the track, trainer at the track, sire at the intsurface-dist and damssire at the intsurface-dist. The report displays the same impact value, win pct, and roi you would see if you had run a situational query for the factor in each row using the SQL Data Window. The report also shows something new: a power weight score generated by a new algorithm I wrote. (The stronger the win rate and roi for a given factor the higher that factor's power weight score.) In future program updates I plan on integrating situational queries reports into other areas of JCapper. Embedding a similar report for each horse in its JCapper PPs would be one example. I've also been quietly working on an interface called Prob Expressions that enables the user to create and store custom sql expressions. The idea here is to enable you to create and store custom sql expressions to drive not only UserFactors and UPR - but custom sql expressions that can also drive situational queries reports of your own design. -jp .
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |