|
JCapper Message Board JCapper 101
|
| Home |
Register
Log In |
| By | Track switch UDM | |
| tanix 7/25/2011 9:41:30 PM | If I'm not in SQL mode and I want to create a UDM that looks specifically for horses starting at one specific track (say Churchill) whose last start was at another specific track (say Fair Grounds) how would I go about that? I've been looking through the filters and can't seem to find a way. Identifying the current track is easy enough through the track restriction field, but what about the previous start? Thanks!
| |
| jeff 7/28/2011 12:51:01 AM | Strike that. Use Track Last Out (Require) -and- Track Last Out (Avoid) See post by JustRalph below... Screenshot: http://www.jcapper.com/messageboard/avatars/NiceCatchRalph.jpg -jp . ~Edited by: jeff on: 7/28/2011 at: 12:51:01 AM~
| |
| tanix 7/26/2011 12:40:04 PM | I was afraid that you were going to say that. It's becoming obvious that I'm going to have to make the switch at some point, but honestly I'm resisting it pretty hard. My hesitance is based upon my perception that I'll be putting a good many factors "out of reach" by doing so since I'll have to select a subset of the total factors to include in the database. You've probably addressed this before, but what's the reason for the limitation? It seems counter-intuitive that a switch to SQL mode would force a decrease in the number of factors considered. It also seems counter-intuitive that such a switch would necessitate addressing factors as "user factor #25" instead of something more descriptive. I may not have the whole picture or I may just not understand the whole picture, but I definitely want to know more. There are obviously a lot of terribly complex SQL databases out in the world, so why the limitations?
| |
| jeff 7/26/2011 4:58:07 PM | What I’m about to post might be controversial (and hard for many to accept) but after thousands of hours of R&D I’m convinced it’s absolutely true. More factors does not equate to more money won (or even money won in the first place.) There are three requirements for getting to break even and beyond: 1. Forming a valid opinion (one with the ability to carry a positive expectancy.) 2. BACKING that opinion (in a way designed to maximize returns.) 3. Repeating the above steps thousands of times over a significant time horizon. I recently read a psychological study that relates success or failure of stock market traders to fear and risk aversion. Fear is a very powerful human emotion. The study concluded that most losing traders share two common traits. First, they tend to hold onto losing positions too long (compounding their losses) out of fear of loss. Second, they tend to sell winning positions too soon (thus minimizing profits) out of fear of not realizing a profit on the trade. The winning traders in the study weren’t afraid to dump losing positions right away. They also weren’t afraid to "let it ride" when they held a winning position. The most common mistake I see most horse-players make is one of mindset. Instead of playing to win they play not to lose (just like the losing traders in the study.) If you spend significant time creating UDMs and running them through the Data Window you can probably relate to this. Run a UDM through the Data Window and chances are total money won and roi are higher for the win column than the place and show columns. This is true for the overwhelming majority of UDMs you are likely to create (the exception being UDMs based on very low odds horses.) If you take the time to listen as most horse bettors call out bets at the windows you’ll hear words like WIN-PLACE, PLACE, WIN-PLACE-SHOW, SHOW, and BOX (a lot.) You might even hear these same words for multiple horses in the same race. However, what you will hear far less often are bets called out in a way clearly intended to back a singular opinion (such as the horse must win the race in order for me to get paid) (and in a way designed to maximize returns.) How does any of this relate to sql mode? Sql mode in JCapper is based on using something called a recordset to query the starterhistory table. Microsoft architecture places an upper limit of 255 for both the number of data fields that can be in an Access table and data fields that can be referenced in any one recordset. My goal was never to circumvent that. When I developed Sql mode I was shooting for faster Data Window queries and the ability to use OR conditionals and math functions in UDMs. I wanted to develop the ability to do that so I could use the technology in my own live play. True, Sql UDMs in JCapper are limited to evaluations of 255 data fields per horse. Yes, that means that some factors aren’t available in sql mode. From the viewpoint of the player operating in PlayList (text) file mode (where several hundred data items can be evaluated in a single UDM) I can see where the fear might arise that 255 data items might not be enough. My viewpoint after using sql mode exclusively (and quite successfully) over the past two years is that such fears are unfounded. Consider the following: If you take the time, you can probably write down the names of maybe a thousand different handicapping factors. However, if you think about it, you will eventually realize the same thing that I did. Every handicapping factor that you can name fits neatly into nine (or so) general handicapping categories: Pace, class, form, ability from speed figs, human connections, breeding, track biases, trips, and value ratios. Many of these are correlated. For example, horses with class have the ability to run faster splits and final times than horses with lesser class. In that way, class is speed and speed is class. Believe me when I say this: Even though it comes with fewer permutations than PlayList file mode, the structure of JCapper in Sql mode is not going to be the thing holding the player back. A starterhistory table with 255 data fields per recordset provides more than enough ways for players to form valid opinions and back them. -jp .
| |
| tanix 7/26/2011 6:04:51 PM | I don't necessarily disagree with any of your assertions there from a handicapping perspective. I'm more curious from a technical perspective. There are a few basic things that I think are undeniable, though: 1. Named fields are preferable to generic fields like Field45. 2. Being able to decide which fields are usable on the fly is more flexible that being required to define which 45 fields are needed up front. 3. In a field-limited environment, utilizing fields to store non-calculable data is preferable to taking up room with calculable data. (There are a good many of the fields utilized for rankings, gaps, and odds/probability pairs that should all be easily calculable. Now, I'm sure this is a trade-off when it comes to performance, and I certainly understand that.) I'm not trying to give you a hard time, and I definitely understand that the application has been around for a few years and has undoubtedly experienced growing pains as all such applications do. I guess I'm just surprised that so much data is still stored in a non-relational manner (and based upon the small amount of research I've done on this front, JCapper is not alone in this.) I think that back in the beginning I just assumed that JCapper's data would be housed in a set of related tables for ease of use and efficiency. Under the current setup it looks to me like you are storing a ton of duplicate data. Anyway, that's all beside the point. I'm sure that changing the data storage strategy would entail a MAJOR rewrite, and I'm assuming that isn't going to happen anytime soon. I'll play around with SQL mode sometime soon and see what I can do with it.
| |
| jeff 7/26/2011 9:46:36 PM | I understand where you are coming from (and even agree with you on certain points.) Most handicapping programs (and mine is no exception) got where they are today as a result of the program author taking a certain evolutionary path. I can only speak about the path that I took (not paths taken by others.) My own path has been centered around doing R&D into what works and why - and then capturing the essence of my R&D in the form of custom factors - and then making that available (within reason) to be "grabbed" by users in UDMs, UserFactors, and UPR... The end goal having always been to provide the user with a reasonable chance at success during live play. Horse race betting is an incredibly tough game to begin with. There are a lot of widely held beliefs out there - I hate to say it, but in my own R&D I've discovered that sooo much of what's widely accepted out there by players as truth has turned out to be nothing more than (at best) wishful thinking and (at worst) complete and utter BS. Just because some author included it in a book or sold it as a system or published it in a magazine or added it to a software program doesn't mean it has any value whatsoever roi-wise in today's game. My intent never was to take everything that exists in a comma delimited data file and make it available for use in UDMs. I am however still working on getting past performance and charts data written in table format during .jcp and .xrd file build routines. (Kind of a software development kit for those with a certain level of programming expertise who want to pursue their own data projects outside of JCapper.) Beyond that, a major rewrite isn't likely at this point in time. Hindsight is 20/20... sigh. -jp . ~Edited by: jeff on: 7/26/2011 at: 9:46:36 PM~
| |
| tanix 7/26/2011 9:30:40 PM | Yup... believe me, I know EXACTLY how you feel. I'm just hoping that the change we've discussed where there will be a query-able database containing all of the info for horses running today makes it into the plan sometime soon :-)
| |
| jeff 7/26/2011 9:50:03 PM | I am however still working on getting past performance and charts data written in table format during .jcp and .xrd file build routines. (Kind of a software development kit for those with a certain level of programming expertise who want to pursue their own data projects outside of JCapper.) Just posting the above separately here in case you missed seeing that I added it as an edit to my above post. -jp .
| |
| jeff 7/27/2011 11:53:00 AM | --quote: "Named fields are preferable to generic fields like Field45"--end quote 150 of the starterhistory table's data field names are named fields. The factor list being written to these fields was chosen based on order of importance determined by R&D - with factors showing the most promise roi-wise when added to models making the cut - with factors showing lesser promise roi-wise being left out. The reason for designating the remaining 105 data fields with generic names like rankf01, valf01, gapf01, etc. wasn't to confuse. It was to hand the user complete control over which of the remaining factors gets written to these data fields. (The UI in the Sql Factor Setup Wizard does that.) Goals and objectives when the design was created: 1. Usefulness during Live Play. (I wanted to make OR conditionals and math functions available in sql udms.) 2. Increased speed of Data Window queries. 3. Introduce user customizable elements: --a. The Sql Html Report (user customizable.) --b. The 35 factors written to the 105 data fields with generic names (user customizable.) 4. Programming hours kept to a reasonable level. Not necessarily disagreeing with you... Just pointing out why the final design was chosen. -jp .
| |
| tanix 7/27/2011 4:35:52 PM | Yeah, I'm not disagreeing with you either. Design is always a trade-off, no matter what approach you take. Looking forward to the future enhancements!
| |
| JustRalph 7/27/2011 10:41:37 PM | Track Last Out (Require) am I stupid ? Did I miss something? Doesn't the above factor do this?
| |
| jeff 7/28/2011 12:38:38 AM | You are absolutely right... Nice Catch Ralph! Screenshot: http://www.jcapper.com/messageboard/avatars/NiceCatchRalph.jpg -jp .
| |
| tanix 7/28/2011 3:10:27 PM | Epic! (and funny!) Thanks Ralph and Jeff!
| |
| JustRalph 7/28/2011 6:44:24 PM | The blind squirrel strikes again!!!
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |