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~
|