|
JCapper Message Board General Discussion
|
| Home |
Register
Log In |
| By | Hey JustRalph | |
| jeff 9/12/2009 5:29:34 PM | Actually... Hey Guys! would be a more appropriate thread title...  Thought you guys might like to know I've decided to bite the bullet and hire a jr programmer to do a few needed site improvements. One of the first things on my wish list is a message board search box. BTW, right now it looks like I'm going to be publishing a MAJOR JCapper program update very soon. ETA Wed of next week. -jp .
| |
| JustRalph 9/13/2009 7:18:44 PM | Thanks.......I am sure I am not the only one looking forward to a search function. I appreciate it.
| |
| JimG 9/13/2009 9:45:09 PM | You are right Ralph. You are not the only one. Today I wanted to do 2 searches. One on PaceFit and the other a general search of Jeff P.'s posts. I am looking forward to the board being updated. Jim
| |
| capperlou 9/13/2009 10:32:09 PM | Hi Ralph: Jim too: With all the catching up I have to do on videos and stuff written by jeff on the new features of platinum and now the newest update with sql and starter history etc., it will surely help me. Thx Jeff.
| |
| JimG 9/14/2009 12:10:55 PM | Jeff, I hope your programmer fixes ths site so that we can reply to a thread using Firefox. Jim
| |
| jeff 9/14/2009 10:04:35 PM | No brainer Jim. Consider it on the list. -jp .
| |
| jeff 9/17/2009 3:15:23 AM | The latest program version is ALMOST ready to go... but there's still a few things that need my attention. Just so you know, here's what I'm ever so close to being able to publish: 1. SQL Enabled UDM Wizard. 2. SQL Enabled Profile Marker. 3. Data Window now runs SQL UDMs. 4. A fully customizeable HTML Report. 5. The new Concensus numbers. Hint: They're very good. 6. The new Race Summary. 7. Something called Free-Form. It's a data entry sheet where you enter numbers, comments, and betting decisions about specific horses or races... what you enter shows up on the HTML Report. There's more - But those are the bullet points. Guys, please bear with me. It's a big program update and I'm still working on parts of it. I'm going to publish as soon as humanly possible. -jp .
| |
| JimG 9/17/2009 9:29:31 AM | Jeff, #4 and #7 are the main reasons I recently upgraded. Those are exciting changes for me. I hope number #4 is sortable and with #7 I will be able to bring up info from another program I am using. Looks like a very comprehensive upgrade and I appreciate your attention to detail and am sure it will be released when it is ready. Now, hurry up!! LOL Thanks for the update. Jim ~Edited by: JimG on: 9/17/2009 at: 9:29:31 AM~
| |
| jeff 9/17/2009 6:01:06 PM | Let's talk about what I mean when I say "Fully Customizeable" HTML Report. First, what I'm about to post only applies to the HTML Report when the program is run in SQL Mode. When you run JCapper in Playlist File mode you get the same one size fits all HTML Report that you have now. More about differences between SQL Mode and Playlist File Mode later when I post a full description of new featuires in the downloads thread... That'll happen as soon as I publish... About the SQL Mode HTML Report... I've created an interface where you the user define: What do you want to see on your HTML Report? Pick the factors you want to see on the report from a factors list and hit a Save button. Where you want to see it? I'll be providing an online design doc that contains the layout of the SQL Mode HTML Report. The report is laid out grid style with Columns and Rows. At the intersection of each Col and Row is a data cell or SLOT. Each of the SLOTS are numbered. Assign a SLOT Number to each factor that you've selected for report display and hit a Save button. How do you want it displayed? You can edit and save slot number attributes such as Column Header, Font, Color, Bolding, Background-Color, right/left cell alignment, whether or not to display data for an individual SLOT or simply blank it out, whether or not to display numeric value, number of decimal places, whether or not to display rank, and whether to simply display the data in the slot/cell as a name instead of a number. The interface also provides the ability to define the following: 1. Report Level Attributes and Sorting You can store a SQL Expression that defines report level attributes and sorting. For example, suppose you want the races on the report sorted by post time instead of the program default which is Track and Race. Let's further say that you only want the report to show graded stakes turf routes with field sizes of 9 or more horses where RV is at least 110... Not that everybody would... I'm just pointing out how flexible the interface is. 2. Race Level Attributes and Sorting The user can store an AND/ORDER BY clause that defines race level attributes and sorting. For example, let's say you want each race to be sorted by UPRMLProb instead of the program's default which is rail position. Let's further say that you only want horses that rank in the top half of the field for... oh, pick a factor... JPR to show up on your report. Not that you wouldn't want to see ALL horses on the report... Again, I'm just pointing out that the interface lets you see the HTML Report your way... What if you're worried about not knowing a thing about SQL? Don't be. I'll help. -jp .
| |
| Hdcper 9/17/2009 6:38:02 PM | I have a question, but tend to think I already know the answer. Will our old udms appear on the Sql HTML report if we want them to or will we need to use both reports? Bill
| |
| JimG 9/17/2009 7:08:33 PM | Hey Bill, Hope the answer to your question is yes. I have a more basic question. What the heck does sql mean? Jim
| |
| jeff 9/17/2009 8:54:20 PM | Bill, In the soon to be released program version - the user has the ability to go into the User Sys Defs screen, check a box that toggles JCapper into SQL Mode, and hit Save. The user also has the ability to check a similar box and kick JCapper back into Playlist File Mode. It's like having two separate programs. Ultimately, you decide which mode you like best. In the soon to be released program version - the Data Window and Profile Marker now take a peek inside each UDM Definition and determine whether or not the UDM being executed is SQL Expression based (new) or Profile Table based (what you are used to.) JCapper In SQL Mode UDMs based on SQL Expressions are executed by the program whenver JCapper is in SQL Mode. Playlist File based UDMs are ignored whenever the program is in SQL Mode. JCapper In Playlist File Mode UDMs based on Profile Table factor constraints are executed by the program whenver JCapper is in Playlist File Mode. SQL Expression based UDMs are ignored whenever the program is in Playlist File Mode. Jim, or anyone else... if you're looking for a good link that provides a thorough overview of JCapper in SQL Mode... check out this thread started by Lou in the private area of the board: http://www.jcapper.com/MessageBoard/TopicReader.asp?topic=563&forum=Private Advantages to JCapper in SQL Mode: Data Window queries for most UDMs come back in seconds - even when executed over very large data samples. Working with SQL Expression based UDMs in the UDM Wizard is cleaner. You actually see the entire UDM Definition at a glance at all times. Factor constraints aren't buried behind drop downs that you seldom open. Also, the need for all those preset filter codes is virtually eliminated. SQL Expression based UDMs also allow for OR conditionals. HTML Report is fully customizeable. Advantages to JCapper in Playlist File Mode: Familiarity. You don't have to learn or do anything new. By now, most of you probably have some pretty decent UDMs. Or some workable concepts at the very least. Running JCapper in Playlist File Mode going forward means you won't need to spend time creating SQL Expressions to give you a match for your current UDM set. I think most of you are REALLY going to like what I'm working on. But I haven't exactly published it yet have I? OK... break's over. Back to the salt mines. -jp .
| |
| Charlie James 9/17/2009 9:50:13 PM | Jeff, If I may be so bold as to ask, Does this mean an old time 'capper like myself might be able to limit horses appearing on my html report to specific surface-distance-rider-trainer combos? Or dare I ask surface-distance-trainer-sire combos?
| |
| jeff 9/18/2009 2:11:42 AM | Jim, Basic answer. SQL stands for Structured Query Language. http://en.wikipedia.org/wiki/SQL Chuck, You'll absolutely be able to do that. -jp .
| |
| ryesteve 9/18/2009 7:41:57 AM | Question about running in SQL mode: from what I've seen posted, Data Window queries and Profile Marker queries will both be executing against a single table that is limited as to the number of fields it can contain. What happens if someone's catalog of UDMs uses more factors than will fit in these tables?
| |
| jeff 9/18/2009 3:09:12 PM | When I first started looking at the design I was skeptical about the prospect of being limited to whatever factors were native to the table plus 35 user selected factors. Consider. Many of my own tight model UDMs have 150 or more separate factor constraints. In the area of early speed… in addition to Run Style, one of my UDMs might have factor constraints for rank, numeric value, and gap for: CPace, PMI, BestE1, AvgE1, V1, Turn Time, PctE, ClosingRatio, QSpeedPoints, CompoundPaceFit, CompoundE1, CompoundE2, CompoundTT, CompoundPctE, CompoundPctM, CompoundAP, and DecelFactor. So if I wanted to replicate the early speed part of that UDM in a SQL Expression… and replicate it exactly… I’d need to use 17 of my 35 available factor slots just for ealy speed. But the more I worked with the interface and used it to create SQL Expression based UDMs the more my skepticism evaporated. The more I worked with the interface the more I began to realize why certain UDMs produce profitable play… and why other UDMs don’t. I’ve become convinced that the selection process isn’t what’s important. It’s what you DO with your selections afterwards that determines profitability. Profitability has very little to do with the ability to slice and dice early speed 50 plus different ways using 17 different factors in a UDM Definition. For me it has everything to do with identifying value… as in applying combinations of the E~ and MLOR-x numbers in the Live Play Module to my selections after I’ve made them. I’ve spent enough time working with the new interface to become convinced of that… convinced enough that I made the following statement in a thread at the PA site: http://www.paceadvantage.com/forum/showpost.php?p=746231&postcount=15 Getting back to early speed… Yes. There are lots of early speed factors in the program. Keep in mind that while many of them are very good… and the result of compound number algorithms… there is at least some co-linearity going on among the various early speed factors. CPace is correlated to PMI… which is correlated to CompoundE1, etc. Compound number algorithms that evaluate early speed are very good at providing a composite look at many different aspects of early speed… but understand that nearly all aspects of early speed stem from just a few things: position at various points of call, beaten lengths at various points of call, and time (or projected time) at various points of call. I’ve found that having just 4 or 5 good early speed factors in and among my 35 slots… CPace, BestE2, CompoundPaceFit, and the new EarlyConsensus… That’s more than enough to allow me to create some powerful SQL Expression UDMs based on early speed. It’s the ability to bet when the public makes mistakes on horses selected by my UDMs (and sit on my hands when they don’t) that creates opportunity for profit. Ok. All that said… What if you believe that 35 user selected factors isn’t enough? I’ve given that a lot of thought. On the one hand you could just stick to running JCapper in PlayList File Mode. Going forward there are at least a few strategies I can envision for making more than 35 factors available. There are a handful of unused fields in the table. It’s possible I could add a memo field to contain factor values, ranks, and gaps (maybe even an xml schema) for factors that aren’t part of your 35… and have the program parse them out. For example: SQL: INSTR('AVGE1RANK=01', MemoRankField) That would be a valid SQL Expression and it would return any horse in the table where AVGE1 rank=1 was recorded in the MemoRankField. How fast that would run at this point is anybody’s guess. I won’t know until I try it. I’ve also toyed with the idea of adding a second starter history table… and adding a second recordset for that table in the Data Window and Profile Marker. How much of an extra load would create inside the program? Again, I won’t know until I try it. I can tell you guys at this point that if 35 user selected factors plus what’s native to the table appears to be too limiting I WILL look at strategies for bumping the number up to more than 35. By the way, as long as we are on the subject of 35… One of the reasons I haven’t published yet is that I’ve been adding more factors to the history table.... I want Alchemy, JPR, JPRMLProb, UPR, UPRMLProb, UPRZscoreProb, QRating, PRating, and as many others as possible to be native in the table so that you guys wouldn’t need to waste any of your 35 slots on factors that I feel should be there right from the beginning. But getting back to the central point of this post… I can tell you in all honesty that in my case 35 carefully selected factors is not in any way shape or form hindering my ability to create some very powerful UDMs using the new SQL architecture. -jp . ~Edited by: jeff on: 9/18/2009 at: 3:09:12 PM~
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |