Database Handicapping Software- JCapper

JCapper Message Board

          General Discussion
                      -- Problem with FGX R11 12-16-2017

Home Register
Log In
By Problem with FGX R11 12-16-2017
jeff
12/17/2017
8:12:24 AM
There's a problem when the program tries to handle the workout data for the #8 horse in FGX R11 for Sat 12-16-2017.

MOVE the FGX1216.JCP file to a temp folder to avoid including that race card in a Build Database routine - only to have that Build Database routine fail.




Comprehensive background info:

There's a factor called WoPct created by algorithm - currently listed as factor #33 on the Supported Factors page here:
http://www.jcapper.com/factorsglossary.asp


--quote:
"WoPct - This number represents the percentile of where a horse's most recent workout ranked in relation to the other horses that worked the same distance at the same track on that same day. Example, a horse's most recent workout was at five furlongs at Saratoga on Sept 1. The time was 59 and 2/5 seconds. If a total of 100 horses also worked five furlongs at Saratoga on that same day and the time of our horse's workout was the fifth fastest at Saratoga for that day, then WoPct = 5 (or 5/100.) (Accessible via the Profile Table Interface)"
--end quote



Basically, the data points needed to calc WoPct are:

a = NumberOfHorsesWorkedThatDistThatDay (field #186 in the JCP file)

b = RankForFastestTimeWorkedThatDistThatDay (field #198 in the JCP file)


Fyi, when b = 1 the horse has the fastest overall work that dist that day - and is said to have a bullet work for that dist that day.

The original vb6 code I wrote (back in about 2003) to make the WoPct calculation is based on having WoPct first being truncated to three decimal places, and then rounding the result of that to two decimal places - operating under the assumption that the number of horses expected to work any given dist on any one calendar day will never exceed 200 runners.

Example, a horse with a bullet work vs. 199 other runners for (say) 4f on a single day would end up with a WoPct calc that looks something like this:

1/200 = 0.005 which rounds up to 0.01


Fast forward to today 12-16-2017 FGX R11 and the 4f work for #8 KILROY WAS HERE on 12-10-2017...

The Equibase data is showing that 221 horses worked 4f that morning.

Which "breaks" the original WoPct calc that I wrote back in about 2003:

1/221 truncated to 3 decimal places = 0.004 which when rounded to two decimal places = 0.00... which when coerced into WoPct causes an overflow (technically a division by zero) error when converted to a percentage.


How best to handle this:

MOVE the FGX1216.JCP file to a temp folder to avoid including that race card in a Build Database routine - only to have that Build Database routine fail.

Wait for, and then install the 12-17-2017 build 198 program update -- which should be available later today -- before including the racecard for FGX 12-16-2017 in a db build routine.

It took me about 30 minutes to track this down -- identify the root cause -- and come up with what appears to be a working solution:

Increase the number of decimal places for WoPct.

I'll need to do some further testing to make sure that increasing the number of decimal places for WoPct doesn't "break" something else (such as taking up too much space in the PL_Profile.txt file or the StarterHistory table.)

All of that said -- and barring anything unforeseen -- I expect to publish a Build 198 Main Module Only program update sometime within the next 24 hrs.

So, for the time being:

MOVE the FGX1216.JCP file to a temp folder to avoid including that race card in a Build Database routine - only to have that Build Database routine fail.

Hope I managed to explain most of that in a way that makes sense.



-jp

.





~Edited by: jeff  on:  12/16/2017  at:  1:58:01 PM~

~Edited by: jeff  on:  12/17/2017  at:  8:12:24 AM~

Reply
jeff
12/18/2017
9:10:00 AM
Quick update...

I asked Ron Tiller at HDW to check the Equibase workout data.

I was specifically interested in whether or not 221 horses working 4f at FGX on 12-10-2017 was accurate or if it was a typo.

Here's what he came back with:

Going back to 2001, here is a list of top 20 highest workout counts.

Note 221 for 4.00f FGX on 12-10-2017 is the highest ever but not crazy.

----- ------------------- ---- -----
Track Date Dist Count
----- ------------------- ---- -----
FGX 2017-12-10 00:00:00 4.00 221
BEL 2009-12-24 00:00:00 4.00 205
BEL 2011-12-24 00:00:00 4.00 202
OPX 2016-12-23 00:00:00 4.00 200
WOX 2003-03-08 00:00:00 3.00 198
SAR 2009-08-02 00:00:00 4.00 197
OPX 2014-01-04 00:00:00 4.00 193
BEL 2016-03-26 00:00:00 4.00 191
OPX 2015-02-22 00:00:00 4.00 190
BEL 2002-10-15 00:00:00 4.00 185
FGX 2006-12-24 00:00:00 4.00 182
BEL 2016-01-22 00:00:00 4.00 182
OPX 2014-01-12 00:00:00 4.00 180
BEL 2016-12-31 00:00:00 4.00 180
BEL 2010-12-24 00:00:00 4.00 179
BEL 2013-12-01 00:00:00 4.00 179
SAR 2016-08-12 00:00:00 4.00 174
OPX 2017-01-21 00:00:00 4.00 174
FGX 2008-01-21 00:00:00 4.00 172
BEL 2008-03-22 00:00:00 4.00 172
----- ------------------- ---- -----



As you can see, 221 turned out to be an accurate head count.

That means my underlying assumption for WoPct that the number of runners working an individual dist on a single calendar day never exceeding 200 isn't valid.

Based on that, I have decided to do a complete rewrite of the WoPct algorithm in JCapper.

It will likely take me another day or two to get this right -- and fully tested.

I'll come back to this thread and post an update as soon as I have a revised build 198 JCapper Main Module uploaded to the server and ready for download.

In the meantime:

MOVE the FGX1216.JCP file to a temp folder. And keep it there to avoid using it in a db build routine (and breaking that db build routine) until such time as I publish a program update designed to handle more than 200 runners working an individual dist on a single calendar day.


-jp

.



Reply
Hdcper
12/21/2017
3:00:30 PM
Since this is the first time this has happened Jeff, all I decided to do for Fgx card tomorrow is just run every race but race 8, as single individual races. Just a suggestion should anyone else want to wager on Fgx for friday 12/22/2017.

Reply
jeff
12/22/2017
9:50:13 AM
In the thread about this issue in the private area of the board, Tom C suggested editing the data file...

And I think that's a great/very workable idea.

Going forward, there are 221 horses that worked 4f at FGX on 12-10-2017 - and those horses are going to show up in future races.

Any new data file that contains one of those horses is going to generate an overflow error when you hit the Calc Races button.

But you can work around that by editing the data file:

1. Make a backup copy of the data file (just in case.)
2. Open up the data file in Notepad.
3. Hit CTRL-F3 to open a search box.
4. Key 221 into the search box.
5. Change the value of any fields you find with an exact value of 221 from 221 to 199.
6. Save the edited data file.


From there, you should be able to run a Calc Races on the edited data file.


-jp

.


Reply
jeff
12/27/2017
7:03:23 PM
New Platinum build 198 program update now available for download.

Link to the release notes for the Main Module ONLY program update - here:
http://www.jcapper.com/helpDocs/MainModuleOnlyBuild198_12262017.pdf

Link to the release notes for the FULL program update - here:
http://www.jcapper.com/helpDocs/JCapperPlatinumBuild198_12262017.pdf

FYI, if you've kept current with the Build 198 program updates, you could install the Main Module ONLY program update first... which only takes a minute or so - and will enable you to handle the next data file that contains one of the 221 horses that worked 4f over the dirt at FGX on 12-10-2017... and then install the FULL program update at some point afterwards (whenever it's convenient for you.)

If you haven't kept current with the Build 198 program updates, and you want to be able to handle the next data file that contains one of the 221 horses that worked 4f over the dirt at FGX on 12-10-2017... You may be better off installing the FULL program update (which takes a bit of effort because of the import routines.)

FYI, Silver program update to follow before year end.


-jp

.


Reply
jeff
1/12/2018
10:46:40 AM
On the opening day Friday Oaklawn card -- in R2, there's a horse who worked 4f at OPX on Dec 30th, 2017... one of 222 horses to do so.

Which of course causes the problem being discussed in this thread (if you have an older version of JCapper that is.)

Fyi, the problem has been addressed in all versions of JCapper published 12-26-2017 and later.

If you haven't installed the latest program version yet -- go to the build 198 program downloads page -- and (for now) get yourself a copy of the Main Module Only program update.

No import required, and should only take a minute or two to install.


-jp

.

Reply
Reply

Copyright © 2008 JCapper Software              back to the JCapper Message Board              www.JCapper.com