JCapper
WagerHistory Module Help Doc
Author:
Jeff Platt
Last
Modified: Aug 20, 2017
General Overview
The purpose
of the JCapper WagerHistory Module is to give the player state of the art tools
to:
1.
Create and maintain a meaningful set of WagerHistory records.
2.
Undertake an ongoing careful analysis of those records to recognize strengths
and weaknesses.
3.
Improve the bottom line going forward by taking corrective action to:
a.
Scale back play in areas of recognized weakness.
b.
Ramp up play in areas of recognized strength.
Screenshots
of Reports
The screenshots linked to below show the WagerHistory Module’s default report
for some of my own (real not made up) wagering activity during 2012.
In the next
few paragraphs I will discuss each of the screenshots, and hopefully,
illustrate how and why proper record keeping can improve the player's bottom
line going forward.
http://www.JCapper.com/Messageboard/Avatars/WagerHistReportGen10.jpg
http://www.JCapper.com/Messageboard/Avatars/WagerHistReportGen11.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen13a.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen13.jpg
Short
Description - All Wagers Are Not Created Equal
The first point I want to make is that all wagers are
not created equal.
In the JCapper WagerHistory Module a concept is introduced called a SHORT DESCRIPTION.
Simply put, a Short Description equates to THE REASON THE PLAYER HAS FOR MAKING
THE BET IN THE FIRST PLACE.
The reason for making a bet varies from bet to bet and from player to player.
In the JCapper WagerHistory Module, Short Description Codes are user defined.
Short Description Codes must be created ahead of time in the Setup Screen. But
once a Short Description Code has been created you can reuse it again and again
each time you make a bet for the reason associated with that short description
code.
The idea is to create unique Short
Description Codes for each of the actual reasons you have for making a bet.
The first screenshot above shows wagering activity for bets
that were tagged with a Short Description Code of HUNCH. As you might well
guess, and this is backed up by the data on the report, hunch bets are best
avoided by the serious player. Enough said.
The second screenshot above shows wagering activity for bets
that were tagged with a Short Description Code of EXASVR. As you might well
guess, EXASVR is a short description I use to describe an exacta saver bet. The
negative results found in the report should come as no surprise to anyone. In
fact they mimic long term results seen in the Data Window whenever I run my A
and B UDMs through the JCapper Data Window and evaluate what happens if I play
horses selected by A and B UDMs underneath other contenders in the exacta pool.
Despite being fully aware of this phenomenon (for some dumb reason) I couldn’t
help myself – and made (and recorded) these losing bets anyway.
The third screenshot above shows wagering activity for bets
that were tagged with a Short Description Code of HIST while compiling the
first half of the HIST wager history data sample. Note that all wagers appearing on the report totals shown in this
screenshot were made BEFORE implementing the retooling effort discussed later
on in this help doc.
The fourth screenshot above shows wagering activity for bets
that were tagged with a Short Description Code of HIST while compiling the
second part of the HIST wager history data sample. Note that all wagers appearing on the report totals shown in this
screenshot were made AFTER implementing the retooling effort discussed later on
in this help doc.
Note the
differences in ROI on each of the reports. Also note that the last EXASVR bet
was made was on 2/26/2012 and the last HUNCH bet was made was on 3/19/2012.
This speaks
to the essence of the WagerHistory Module. All wagers are not created equal.
Analyzing wagers using data points has value. Make no mistake. The reason you have for making a bet is a very
important data point.
Careful
analysis of data points enables the player to recognize strengths and
weaknesses. Through the simple act of recognizing and avoiding known areas of
weakness, as well as recognizing and ramping up play in known areas of
strength, the player gains the ability to improve wagering performance going
forward.
Again, the purpose of the JCapper WagerHistory Module is to give the player
state of the art tools to:
1.
Create and maintain a meaningful set of WagerHistory records.
2.
Undertake an ongoing careful analysis of those records to recognize strengths
and weaknesses.
3.
Improve the bottom line going forward by taking corrective action to:
a.
Scale back play in areas of recognized weakness.
b.
Ramp up play in areas of recognized strength.
Requirements/Getting
the Module Up and Running
IMPORTANT
- SQL Mode Required
The JCapper
WagerHistory Module is designed to integrate (seamlessly) into JCapper under
SQL Mode. Although parts of it do work when JCapper is operated in PlayList
File Mode, this module is designed to be used when operating JCapper in SQL
Mode.
IMPORTANT
– Knowledge of SQL Required
Operating
the WagerHistory Module effectively requires at least some knowledge of sql. A good benchmark is that if you can run the JCapper
Data Window in sql mode then you can run the JCapper
WagerHistory Report Generator with just a short learning curve.
Compatibility
The JCapper
WagerHistory Module is compatible with all current versions of both JCapper
Silver and JCapper Platinum.
Dummy Wager
The
internal sql expressions that I am using in the
module to enable the paging buttons to page through records in the WagerHistory
table require that the WagerHistory table in the c:\JCapper\Exe\JCapper2.mdb
file have at least one existing record - otherwise a BOF (Beginning Of File)
error message will be generated when the WagerHistory module is first launched.
As of this
writing, the WagerHistory table included with the latest JCapper program
download package contains a $2.00 dummy wager tagged with a short description
code of HUNCH. The purpose of the dummy wager is to prevent the interface from
throwing a BOF (Beginning Of File) error message the
first time you fire up the new module.
However, it
is possible to unknowingly overwrite the dummy wager when you do a program
install. Specifically, if you check the WagerHistory table box on the JCapper2
Imports Screen while importing JCapper2 table data from your old file into your
new file – and if your old WagerHistory Table contains
0 records – you will cause the WagerHistory table dummy wager to be overwritten
(deleted.)
Hint: If
you get a BOF error message the first time you fire up the WagerHistory Module
– try not to panic. There’s a 99 percent chance that the error message means
there are 0 records in the WagerHistory table and that you just need to create
record number 1 in the WagerHistory table manually.
Instructions for Auto-generating a
“dummy” WagerHistory table record:
Upon
startup, the Data Entry Sheet tests the WagerHistory table and counts the
number of table records. If at least 1 table record is found the module loads
(and runs) normally.
If 0 table
records are found, instead of a BOF message, and instead of the user having to
manually enter a "dummy wager" as the 1st table record - here's what
happens:
1. The user
is notified that 0 table records exist and is then prompted: "Do you wish
to Create a 'dummy wager' as the 1st table record
Y/N?"
2. Upon
answering Y at the prompt, the interface auto generates table record number 1
with a made up track code, race number, and horse name - and the module loads
normally from there.
Hint: After using the WagerHistory
Module to record at least one real wager, consider deleting the “dummy” wager.
Although it
is probably easier to auto generate a “dummy wager” to initialize the module,
alternately, the first table record can be created manually.
Instructions for manually creating a
"dummy" WagerHistory table record:
Congrats.
You now have a dummy wager as record number 1 sitting in the WagerHistory
table.
From here,
exit the Data Entry Sheet and run a SQL Mode Calc Races routine.
The next
time you launch the Data Entry Sheet you should find that the BOF error is a thing
of the past and that you can now operate the WagerHistory Module exactly as
described in this Help Doc.
Hint: After using the WagerHistory
Module to record at least one real wager, consider deleting the “dummy” wager.
JCapper WagerHistory User Interface
To launch
the WagerHistory Module, click the WgrHist button on the face of the JCapper Main Module. When
the WagerHistory Module is first launched, the very first screen that comes up
is the WagerHistory User Interface.
WagerHistory
User Interface screenshot:
http://www.JCapper.com/Messageboard/Avatars/WagerHistUserInterface.jpg
The
WagerHistory User Interface has a simple design. You the user are presented
with buttons, that when clicked, will enable you to navigate to the individual
screens that collectively make up the WagerHistory Module. (To get into any
area of the WagerHistory Module, simply click the launch button for that area.)
JCapper
WagerHistory Setup Screen
The purpose
of the JCapper WagerHistory Setup Screen is to enable you to create Short
Description Codes.
Short Description Field
In JCapper,
a Short Description is a user defined string of up to 18 text characters used to
describe the reason the player has (or had) for making an individual bet. The
player has the ability to set up unique short description codes ahead of time -
one short description code for each reason for making a bet. Then during record
keeping, when actual tickets are written to the table, the player can tag each
bet made with the appropriate short description code.
Tagging
individual tickets with a Short Description Code enables you to generate wager
history reports that will evaluate your
own performance in terms of why each bet was made.
Bets made
for like reasons can be reported on separately. Once sufficient wager history
has been amassed, strong reasons for making a bet are readily identified (as
are weak reasons.) From there, corrective action can be taken as needed.
JCapper
WagerHistory Setup Screen screenshot:
http://www.JCapper.com/Messageboard/Avatars/WagerHistSetup.jpg
The above
screenshot shows the Setup Screen after creating a Short Description Code. Note
that I used the characters VSFAV in
the Short Description field and the characters Taking a Stand vs Overbet Favorite in the
Long Description field. As you might well have been able to guess, VSFAV is a Short Description Code that
can be used to tag wagers made where the primary reason for making the bet is a
belief that the post time favorite is:
1.
Vulnerable.
2. Overbet.
Your goal
when setting up your own Short Description Codes: Create one short description
code for each reason you have for making a bet.
Long Description Field
The Long
Description field is used to hold a longer text description describing the
reason you have for making a bet. A long description can be any combination of
keyboard characters you want – up to 72 characters in length.
Creating a New Short Description
Code
Here are
the steps to create a new Short Description Code:
Hint: The shorter your Short
Description Codes the better. Most of mine are just 4-6 characters in length.
(This makes for reports that are easy to read because they are not cluttered
up.)
Editing an Existing Short
Description Code
Here are
the steps to edit an existing Short Description Code:
Deleting an Existing Short
Description Code
To delete
an existing Short Description Code:
Note: The
first few times that you are in the WagerHistory Module you will need to bring
up the Setup Screen to create Short Description Codes – one Short Description
Code for each reason you have for making a bet. After creating a handful of
Short Description Codes you will yourself in the Setup Screen less frequently.
After a while, you will seldom find yourself in the Setup Screen – as the only
time you need to go into to the Setup Screen is when you’ve identified a new
reason for making a bet and you need to create a new Short Description for that
reason.
JCapper
WagerHistory Data Entry Sheet
The Data
Entry Sheet is designed to enable you to record detailed info about each wager
that you make. Info recorded can include info about individual playing
sessions, size of bankroll, info driving your bet sizing, the reason why you
made the bet in the first place, various attributes about the bet not found
elsewhere in JCapper, and an electronic copy the
ticket for each of your wagers.
Screenshot
- JCapper WagerHistory Data Entry Sheet:
http://www.jcapper.com/messageboard/avatars/WagerHistDataEntry01.jpg
The Data
Entry Sheet interface is broken up into three sections: The Bankroll Summary
Section, the UDM/Races Section, and the Wager Detail Section. Each section is
presented individually below.
IMPORTANT
- SQL Mode Required
The JCapper
WagerHistory Interface is designed to integrate (seamlessly) into JCapper under
SQL Mode. Although parts of it do work when JCapper is operated in PlayList
File Mode, this module is designed to be used when operating JCapper in SQL
Mode.
JCapper2.ldb Lock File
When the
WagerHistory Module Data Entry Sheet is launched it places a lock condition on
the c:\JCapper\Exe\JCapper2.mdb file so that it can read and write to the
WagerHistory table. After launching the Data Entry Sheet, if you navigate to
the c:\JCapper\Exe folder and look at the names of files on that folder, you
will see the following lock file: c:\JCapper\Exe\JCapper2.ldb. As soon as the
Data Entry Sheet is terminated the lock condition is removed, and the
c:\JCapper\Exe\JCapper2.ldb lock file is automatically deleted by Windows.
I mention
this because while the lock condition remains in effect – you will not be able
to run a Calc Races routine. If you try to run a Calc Races routine and receive
a message box telling you: The
c:\JCapper\Exe\JCapper.mdb file is currently locked by another application
– the very first thing you should suspect is that the JCapper2.mdb file has
been locked by the Data Entry Sheet – and that this can be corrected simply by
X-ing out of (closing down) the Data Entry Sheet.
Alternately,
the lock condition can be removed (the lock file deleted and the JCapper2.mdb
file freed up) by clicking the Disconnect Button. FYI, the Disconnect and
Reconnect buttons are discussed in the UDM Races section later on in this help
doc.
Bankroll
Summary Section
This
section is designed to facilitate tracking of ADW account balance (or simply
cash on hand if you are not using an ADW) and to facilitate bet sizing relative
to both strength of play and size of current bank. A short description about
each of the bankroll summary data fields and buttons is listed below.
SessionID Field
Use this
data field to assign a unique ID character string (or name) for each playing
session. By referring to the SessionID field as part
of SQL expressions that you create for WagerHistory reporting, you will be able
to generate reports that display all wagers for specific playing session(s.)
Note that the interface is designed in such a way that you would record a value
in this field (once) at the start of each playing session only. (There is no
reason to change the value of this field during a playing session.) You would,
however, enter a new value in this field at the start of each new playing
session.
Account
Balance Start Point
Use this
data field to record the ADW account balance (or simply cash on hand if you are
not using an ADW) at the start of each playing session. The interface will use
the info in this data field as part of its bankroll/bet sizing calculation
going forward. Note that the interface is designed in such a way that you would
record a value in this field (once) at the start of each playing session only.
(There is no reason to change the value of this field during a playing
session.) You would, however, enter a new value in this field at the start of
each new playing session.
Current
Account Balance
Use this
data field to record the ADW account balance (or simply cash on hand if you are
not using an ADW) just prior to making each wager. The interface will use the
info in this data field as part of its bankroll/bet sizing calculation going
forward. Note that the interface is designed in such a way that you would
record a new value in this field for each new wager persisted to the
WagerHistory table. Keying a new value into this data field just prior to
recording a new wager allows you to size each (new) wager relative to (new)
current bankroll size. Optionally, this data field can be updated periodically
(whenever you decide it best to recognize new current bankroll size.)
Starting
Session Bankroll
Use this
data field to record the amount of the starting bankroll for each playing
session. Note that the interface is designed in such a way that you would
record a value in this field (once) at the start of each playing session only.
(There is no reason to change the value of this field during a playing
session.) You would, however, enter a new value in this field at the start of
each new playing session.
Current
Session Bet Pct
Use this
field to record the percentage of bankroll for each wager persisted to the
WagerHistory table. Note that the interface is designed to provide several
methods for getting data into this field. You can key a value into this field
manually. Clicking one of the bankroll sizing buttons located immediately
beneath this data field will cause it to be auto populated. Additionally,
clicking the Kelly button located on the upper right side of the interface will
cause this data field to be auto populated.
Current
Session Bankroll
The
interface is designed in such a way that you would not (normally) enter data
into this field. Instead, it is auto populated as part of the bankroll/bet
sizing calculation using available info obtained from other data fields.
Calculated
Bet Size
The
interface is designed in such a way that you would not (normally) enter data
into this field. Instead, it is auto populated as part of the bankroll/bet
sizing calculation using available info obtained from other data fields.
Bet
Sizing Buttons
Several
buttons are provided for Pct of Bankroll Bet Sizing. Each button is labeled
with a numeric percentage of bankroll. Clicking a button causes the interface
to perform its bankroll/bet sizing calculation (using the percentage of
bankroll appearing on the face of the button) and populate appropriate data
fields on the interface with the results of the calculation.
Bolded
Bet Sizing Button
Note that
one of the bet sizing buttons is bolded. The percentage of bankroll value
displayed on this button is the same as the value persisted by the user on the
User Sys Defs Screen. (This means you can control the percentage of bankroll
appearing on this button and used by the interface in its bankroll/bet sizing
calculation by editing the bankroll settings found on the User Sys Defs Screen.)
Clicking this button causes the interface to perform its bankroll/bet sizing
calculation (using the percentage of bankroll appearing on the face of the
button) and populate appropriate data fields on the interface with the results
of the calculation.
Calculate
Button
Click this
button to make the interface perform its bankroll/bet sizing calculation after
manually keying a percentage of bankroll value into the Current Session Bet Pct
data field. (You would not otherwise have reason to click this button.)
The
UDM/Races Section
This
section of the interface enables you to quickly spot races that have UDM
selections. The visual elements in this section of the interface are presented
below.
UDM
Races Listbox
The UDM
Races Listbox, when populated, displays a list of races that have UDM
selections. The rules for making UDM selections appear in the UDM Races Listbox
are the same as those governing whether or not horses selected by UDMs appear
on both standard JCapper Text Report and inside the SQL Mode UDM Reports
Module. To make horses selected by a UDM appear in these three areas of the
JCapper program, on the Modify Screen of the UDM Wizard: 1. Uncheck the Hide From Text Report Checkbox. 2. Use Mark Characters associated
with positive expectation UDMs (avoid Mark Characters associated with Negative
Expectation UDMs.) If the selections of a UDM appear on a JCapper Text Report,
they will also appear in the SQL Mode UDM Reports Module and in the
WagerHistory Data Entry Screen UDM Races Listbox.
Note that
individual rows displayed in the UDM Races Listbox are clickable. To initiate a
WagerHistory table entry for a horse displayed in the UDM Races Listbox: double
click that row.
Populate
Button
Click the
Populate Button to populate the UDM Races Listbox with a list of UDM plays for
card files loaded into the program.
Prerequisite
for populating the UDM Races Listbox:
Before you
can populate the UDM Races Listbox you must first run a Calc Races in SQL Mode.
Failure to do this will result in inability to populate the Listbox.
Find
Button
Clicking
the Find button will cause the interface to pull up wager detail for the row
currently selected in the UDM Races Listbox. To populate the Wager Detail
Section of the interface for a horse displayed in the UDM Races Listbox: Single
click the row for that horse and click the Find button. (Optionally, you can
double click the row for that horse without clicking the Find button.)
UDMs
Button
Clicking
the UDMs button causes the UDM Profile Window in the Wager Detail section of
the interface to switch display types. If the UDM Profile is currently
displayed when the UDMs button is clicked a text report showing wager detail
will be displayed. If the text report showing wager detail is displayed when
the UDMs button is clicked the display mode is switched and the UDM Profile is
displayed. Note that the UDMs button in the UDM/Races Section of the interface
and the Detail button in the Wager Detail Section of the interface both perform
the same function.
The Deselect
Button
Clicking
the Deselect button causes any selected item (or currently highlighted row) in
the UDM Races Listbox to become deselected (or un-highlighted.) You would
normally click this button just prior to clicking the New
button in the Wager Detail Section of the interface when you want to create a
new table entry for a horse other than the one currently selected/highlighted
in the UDM Races Listbox.
Disconnect
Button
Clicking
the Disconnect Button causes the WagerHistory Data Entry Sheet interface to
close its database connection with the c:\JCapper\Exe\JCapper2.mdb file. You
would normally click this button to remove the lock file placed on the
c:\JCapper\Exe\JCapper2.mdb file by the WagerHistory Data Entry Sheet – For
example: You would click the Disconnect button to unlock/free up the
JCapper2.mdb file so that you can run a SQL Calc Races using the JCapper Main
Module. Alternately, the lock file can be removed (the JCapper2.mdb file freed
up) by X-ing out of (closing down) the WagerHistory Data
Entry Sheet.
Reconnect
Button
Clicking
the Reconnect Button causes the WagerHistory Data Entry Sheet interface to
reconnect to the c:\JCapper\Exe\JCapper2.mdb database file. You would normally
click the Reconnect button under the following circumstances: 1. You previously clicked the Disconnect button to unlock the
c:\JCapper\Exe\JCapper2.mdb database file. 2. You are finished running a non
WagerHistory routine such as a Data Window query or SQL Calc Races involving
the c:\JCapper\Exe\JCapper2.mdb database file.
3. You are ready to once again use the WagerHistory Data Entry Sheet.
Alternately, you can reestablish a database connection by closing down and
relaunching the WagerHistory Data Entry Sheet interface.
The
Wager Detail Section
This
section of the interface is designed to enable you to record various details
about each wager that you make. Not all of the data fields in this section of
the interface are required data fields. (Many are optional.) However, it goes
without saying that the more detail recorded about your wagers, the greater the
depth your wager history analysis can take on.
Data
Fields Section
A short
description of each of the wager detail data fields is listed below.
Strike
Price
Use this
(optional) field to record the strike price (min required odds) you need in
order to bet a horse profitably. Initially, your strike price might be
subjective – something as simple as entering the odds line number (or some
multiple of the odds line number) displayed on the html report for the horse
you are about to bet.
Odds 1
MTP
Use this
(optional) data field to record the odds close to post time (or decision odds)
just before making play or pass decisions about horse(s) you are about to bet.
Estimated
Edge
This
(optional) data field has been provided to enable you to record an estimated
edge for each bet that you make. The value recorded in the estimated edge field
might (initially in your first sample) be your own best attempt at estimated
edge.
Better yet,
the value recorded in this field might also be something that you calculate
mechanically. For example, it could be a value resulting from an algorithm of
your own creation where you are attempting to tag each recorded bet with a
numeric value that (at first and loosely) represents strength of play – but is
also something that improves with time as future analysis and review of its
strengths and weaknesses is undertaken.
Estimated Edge Auto Calc function
An
Estimated Edge Auto Calc function is built into the interface.
To use
the auto calc function:
First populate data fields for strike price, decision odds, physicality, track
weight, and UDM counters. Then double click the estimated edge field and answer
Y when prompted. The interface contains an algorithm that will evaluate all
available information about the current horse (including field size) before
auto populating the estimated edge field. The advantage to using the auto calc
function is that estimated edge is calculated in the same manner every single
time.
Once you
have compiled strike price, decision odds, and estimated edge data about the
horses you bet, you will be able to use the WagerHistory Report Generator to
run reports showing your actual wager history broken out by different facets
related to play or pass decision making. This will (hopefully) enable you to
improve your play or pass decision making going forward.
Consistency within a Sample
One
advantage of using the estimated edge auto calc function is that values
recorded in the estimated edge field are calculated in an identical manner
every single time.
Why is this
important?
Wager
history data itself can be rendered useless when recorded data points are
arrived at in a haphazard manner. (This is true for any type of data.)
If you do
decide to roll your own when arriving
at values recorded in the estimated edge field: Whatever methodology you use,
insist that calculated values going into the estimated edge field be generated
in a nearly identical manner for all wagers recorded within an individual
sample.
Kelly
Button
Much has
been written about using the Kelly Criterion as a method to determine bet
sizing. The theory behind it goes something like this:
Optimal Bet
Size = (Estimated Edge) divided by (Odds)
Suppose
Estimated Edge (ROI to $1.00) is 1.12. Put anther way: percentage advantage is
12 percent. Further, suppose that the odds at decision time are 3-1. Using
Kelly, optimal bet size is calculated as follows:
Optimal Bet
Size = (Estimated Edge) / (Odds)
Optimal Bet
Size = (.12) / (3)
Optimal Bet
Size = .04
Or
Optimal Bet
Size = 4 percent of bankroll.
Experience
has taught me the following:
Using Kelly
to determine wager size works really well if and only if the player is able to
estimate the edge accurately. Using Kelly to determine bet size will have
disastrous consequences for the player in the event the player errs when
estimating his or her edge.
Nonetheless,
for players who believe they have gained the ability to estimate their edge
with reasonable accuracy (through record keeping and analysis of their own
wager history) I have included the Kelly button as part of the Data Entry Sheet
interface.
Clicking
the Kelly button causes the interface to read the values from the Estimated
Edge and Odds 1 at MTP fields, make a Kelly bet sizing calculation by plugging
estimated edge and decision odds into the above formula – with the resulting
bet size output to the the Calculated Bet Size and
Bankroll Pct data fields located on the left hand side of the interface.
IMPORTANT:
If you are the least bit unsure about your ability to accurately estimate your
edge, avoid using the Kelly button for bet sizing. Instead of the Kelly button,
consider using one of the Pct of Bankroll buttons on the left side of the interface.
Bet sizing
is an extremely important part of growing a bankroll. Before making any
decisions about the bet sizing part of your game, consider doing some extensive
Data Window R&D first – with the objective in mind of becoming somewhat
educated about what bet sizing might be appropriate for each of your UDMs.
Believe me when I say this. This is an extremely important area (one that most
players give very little thought to.)
Experiment
a little. Use the Enhanced Settings Module to persist various bet size
percentages. Then immediately run each of your active UDMs through the Data
Window using the new bankroll setting and make a careful analysis of the
Bankroll Summary Section displayed towards the bottom of your Data Window
results. Save the Data Window results (in a text file) for future reference and
then repeat using different bankroll settings.
Each of
your UDMs will likely have a different strength of play. It is therefore likely
that each of your UDMs will require slightly different bet sizing. If you are
the least bit unsure about how to size your bets, accept the fact that until
you get considerable experience under your belt you are going to err when it
comes to accurately sizing your bets. Go with the following philosophy: If you
must err, then err on the side of caution. Make smaller bets rather than larger
– at least until you have sufficient wager history (and experience) behind you.
Physicality
This
(optional) numeric data field has been provided to enable the player to record
a score for horse physicality. This field is optional as compiling data based
on your interpretation of horse physicality may (or may not) be something you
are interested in. If horse physicality is not your thing, feel free to use
this field to record a number that represents something else.
Estimated
Track Weight
This
(optional) numeric data field has been provided to enable the player to record
a score for Estimated Track Weight. This field is optional as compiling data
based on your interpretation of estimated track weight may (or may not) be
something you are interested in. If track weight is not your thing, feel free
to use this field to record a number representing something else.
UDM
Count Data Fields
A well
thought out set of UDMs can paint a very accurate picture about the strengths
and weaknesses of horses flagged by them. The interface enables the player to
persist a hard count of each UDM type to the WagerHistory table. Once enough
data has been recorded, the interface enables the player to gain valuable
insight about the way his or her UDMs interact with one another for the horses
bet by the player.
The
interface was designed around the following UDM types:
A UDMs –
These are your best business UDMs – the ones you (should) put most of your focus
on.
B UDMs –
These are good UDMs (that under the right conditions) can point out playable
horses. But they are not as good as your A UDMs.
Negative
Expectation UDMs – These are UDMs designed to point out weaknesses in horses
flagged by them.
UDM Count –
A
Use this
(optional) data field to record the number of A UDMs flagging an individual
horse.
UDM Count –
B
Use this
(optional) data field to record the number of B UDMs flagging an individual
horse.
UDM Count –
Neg
Use this
(optional) data field to record the number of Negative Expectation UDMs
flagging an individual horse.
UDM
Count Auto Populate Feature:
When a new
record is created for a horse, the interface assembles and displays the UDM
profile for that horse. To relieve the player of the (tedious) need to manually
determine (and key in) the count of UDMs by UDM type for each horse, the
interface contains an algorithm that robotically counts the number of UDMs (by
UDM type) found in a horse’s UDM profile. When the UDM profile is first pulled
up by the interface, the player is prompted by the interface (Y or N) whether
or not to auto populate the UDM count data fields. Answering Yes
when prompted will cause the interface to auto populate the UDM count data
fields.
UDM
Naming Schema:
The
following UDM Naming Schema will enable the Auto Populate Function to identify
UDMs according to UDM type:
A
UDMs – First 4
characters: 0_A-
B UDMs –
First 4 characters: 0_B-
Neg UDMs – First 2 characters: X_
Neg UDMs – First 2 characters: Z_
Neg UDMs – First 3 characters: XX_
Neg UDMs – First 3 characters: ZZ_
If the auto
populate function does not appear to be working for you: Double check your UDM
names against the above naming schema. Use the Modify UDM Screen in the UDM
Wizard to edit your UDM names accordingly.
Date
Field
This
(required) field is provided to record the date.
When the
Data Entry Sheet is first launched, the last entry in the WagerHistory table is
auto displayed. When you click the NEW button to begin data entry for a new
wager, the date field will (initially) be populated with the date of the last
entry in the table.
Clicking
the date field will launch a calendar control. With the calendar control
launched, select the race date for the new wager you are about to entry and hit
the Apply button. The calendar control will paste the selected date into the
Date field. From there, move to the next field.
Track
Field
This
(required) field is provided to record the 3 character track code for each
wager.
Manual data
entry of track code:
Key the 3
character track code for the new wager you are about to enter into the Track
field. Note that in JCapper, track codes are 3 characters in length. Also note
that the track code is the same as the first 3 characters of the file name of
the past performance data file for each track. After manually keying a track
code into the Track field, navigate to the Race Drop Down using the Tab key. As
soon as you navigate to the Race field, the Race Drop Down will auto populate
with a list of races for the track and date you are working with.
Race
Drop Down
This
(required) field is provided to record the race number for each wager.
Manual data
entry of race number:
Select a
race number and navigate to the Horse Name Drop Down using the Tab key. As soon
as you navigate to the Horse Name Drop Down (provided that you have provided
the interface with valid info for date, track, and race number) the Horse Name
Drop Down will auto populate with a list of horses for the current race.
Horse
Name Drop Down
This
(required) field is provided to record the horse
name for each wager. Note that the very last horse listed in the drop down is
not a horse name at all. When entering wagers that are multi horse based rather
than single horse based: select MULTI HORSE WAGER from the drop down. When
entering wagers that are primarily based on a single horse: select the
appropriate horse name from the drop down.
UDM
Profile Window
After
selecting a single horse from the Horse Name drop down, the interface will pull
up the horse’s UDM Profile using info from tables found in the c:\
JCapper\Exe\JCapper2.mdb file. The interface will also display the horse’s UDM
Profile in the UDM Profile Window. Note that the UDM Profile is the same as
that displayed on the SQL Mode HTML Report and the SQL UDM Plays Reports
Module.
Note: As
mentioned above in the section covering the UDM Count data field, once the UDM
Profile is first created, you will be asked Y/N to see if you want the
interface to auto populate the UDM Count data fields.
Short
Description Drop Down
This
(required) drop down field is provided to record the Short Description (or
reason) for making the bet.
Within the
context of the JCapper WagerHistory Module, a Short Description is a user
defined code (created in the Setup Screen) that relates to the reason for
making a bet.
IMPORTANT
NOTE: Before using the Data Entry Sheet to record your wagers, you should first
use the Setup Screen to create one Short Description for each reason you can
think of for making a bet. Then, when using the Data Entry Sheet to create
table entries describing your wagering activity, select the one Short
Description from the drop down that best describes the reason why you made the
current bet that you are recording.
UDM Name
Drop Down
This
(optional) drop down data field is provided to record the name of the primary
UDM flagging the horse.
UDM Name
Auto Selection Routine
When
multiple UDMs are flagging the current horse, an algorithm will auto select the
UDM that (initially) appears in the UDM Drop Name Down. The programming behind
the algorithm is simple: First, only active UDMs are eligible for auto
selection. Next, only UDMs having the Hide From Text
Report box unchecked in the UDM Wizard Modify UDM Screen are eligible for auto
selection. Lastly, Negative Expectation UDMs are not eligible for auto
selection.
Note that
these rules are the same as those used by the Profile Marker to determine
whether or not UDMs appear on the Text Report. The auto selection rules can be
restated as follows: UDMs that are eligible for auto selection are simply those
that appear on the Text Report.
Once the
list of eligible UDMs has been determined, the list is sorted, and the eligible
UDM on the list named in such a way that it would be displayed first (on top)
in the SQL Mode Text Report (or alternately in the SQL Mode UDM Plays Report)
is the UDM auto selected by the interface to appear in the UDM Name Drop Down.
To override
the auto selected UDM: select a different UDM from the UDM Name Drop Down.
Paging Buttons
Beneath the
UDM Profile Window are several paging buttons designed to enable you to page
through the entries you have made to the WagerHistory table (your wager
history.)
FIRST Button
Clicking
this button causes the interface to pull up and display detail for the very
first record in the WagerHistory table.
BACK Button
Clicking
this button causes the interface to go back one record in the table, pull up
that record, and display detail for it. Note that if the BACK button is clicked
when the very first record in the table is displayed a message is generated
alerting you to this fact. (You are already looking at detail for the first
record in the table.)
NEXT Button
Clicking
this button causes the interface move forward one record in the table, pull up
that record, and display detail for it. Note that if the NEXT button is clicked
when the very last record in the table is displayed a message is generated
alerting you to this fact. (You are already looking at detail for the last
record in the table.)
LAST Button
Clicking
this button causes the interface to pull up and display detail for the very
last record in the WagerHistory table.
EDIT Button
Clicking
this button enables you to edit detail for the current record (the record
currently displayed by the interface.) The interface will alert you to this
fact by displaying the following message: Edit
Record Sequence Engaged. Note that the interface also displays the phrase Edit Record Sequence Engaged on the
title bar going across the very top of the Data Entry Screen. This provides you
a visual cue that the Edit Record Sequence has in fact been engaged. While the
Edit Record Sequence is engaged the SAVE button is enabled.
To edit
detail for the current record:
Alternately,
you can abandon the Edit Record Sequence and avoid saving changes by paging to
a different record without clicking the Save button. For example, changes to
the current record can be abandoned (not persisted to the table) by clicking
the Back button instead of the Save button.
Creating a New Record for UDM horses
displayed in the UDM Races Listbox
To create a
new record for a UDM horse displayed in the UDM Races Listbox, do not (repeat
not) click the New button.
Instead of
clicking the New button:
After
running a SQL Mode Calc Races, click the
Populate Button to populate the UDM Races Listbox with a list of UDM plays
for card files loaded into the program.
Double click the horse name in the
UDM Races Listbox that you want to create a new record for.
This will
cause the interface to begin creating a new record for that specific horse. The
interface will alert you to this fact by displaying the following message: Create New Record Sequence Engaged. The
interface will also provide you a visual cue that the Create New Record
Sequence has been engaged by displaying the phrase Create New Record Sequence Engaged on the title bar going across
the very top of the Data Entry Screen.
Immediately
upon clicking OK in response to the Create
New Record Sequence Engaged message, the interface will present you with
the following prompt: Auto Populate UDM
Counters to UDM Profile Y/N?
Clicking Y
at this prompt will cause the interface to pull up the UDM profile for the
selected horse and auto populate the UDM Count Data Fields using the UDM naming
schema for A, B, and Negative UDMs as described in the UDM Count Data Fields
section presented above in this help doc.
Clicking N
at this prompt will cause the interface to not auto populate the UDM Count Data
Fields for the selected horse.
From here,
use the interface to key info for the remaining data fields and save your work
by clicking the SAVE button.
Alternately,
you can abandon the Create New Record Sequence and avoid creating a new record
by paging to a different record without clicking the Save button. For example,
creating a new record can be abandoned (not persisted to the table) by clicking
the Back button instead of the Save button.
Creating a New Record for horses NOT
displayed in the UDM Races Listbox
NEW Button
Clicking
the New button will enable you to create a new record for a horse (or horses)
not displayed in the UDM Races Listbox.
After the
New button is clicked, the interface will tell you that you are creating a new
record by displaying the following message: Create
New Record Sequence Engaged. The interface will also provide you a visual
cue that the Create New Record Sequence has been engaged by displaying the
phrase Create New Record Sequence Engaged
on the title bar going across the very top of the Data Entry Screen.
Manual Procedure
for Creating a New Record:
Clicking
Y at this prompt will cause the interface to pull up the UDM profile (if any
exists) for the horse name provided and
auto populate the UDM Count Data Fields using the UDM naming schema for A, B,
and Negative UDMs as described in the UDM Count Data Fields section presented above
in this help doc.
Clicking
N at this prompt will cause the interface to not auto populate the UDM Count
Data Fields for the horse name provided.
Note: When the Multi Horse Wager
option has been selected from the horse name drop down, there is no UDM profile
to be pulled up
.
Best Practices
Consistency
The wager
history that you create using this module will have value to you for purposes
of future analysis only if the data points captured for each wager are created
in a consistent manner.
Take for
example the Short Description field. The screenshots at the very top of this
help doc serve to illustrate differences in player expectation going forward
based on the reason for making the bet.
In the case
of the HIST data sample, EVERY single wager recorded was assigned its short
description code for a very specific reason.
First, the
horse itself had to be selected by one or more of my A UDMs. Further, every single one of those A UDM horses that I
wagered on went to post under a nearly identical predefined set of standards.
Because
assignment of the HIST short description code was made in a nearly identical
manner for every single recorded wager, and made to a predefined set of
standards, the wager history data itself turned out to be useful as well as interesting. This became apparent to me
once I had amassed enough data and began analyzing it. I very strongly believe
that the usefulness of the wager history data itself would have been weakened
considerably had assignment of the short description code been made in a more haphazard
manner.
The same
can be said for all of the other data points found on the interface.
Consistency matters.
Ticket Calculator
The purpose
of the Ticket Calculator is to enable you to create an electronic copy (or
ticket) of every wager that you make.
Creating a Ticket.
Screenshot - Ticket Calculator
On the Data Entry Sheet, fill out everything about the horse you want to record
a wager for (Short Description, Date, Track, Race, Horse, etc.) and click the
Ticket Calculator button.
If the
create new record sequence is not already engaged when you click the Ticket
Calculator button, the interface will ask you (Y or N) whether or not you want
to Clone the current record. Answer Y at the prompt to create a new ticket for
the horse. Answer N at the prompt if you simply wish to edit the ticket detail
for the current record. After answering Y or N at the prompt, the interface
will launch the Ticket Calculator.
The steps
for using the Ticket Calculator to create a ticket are as follows:
1. Click
one or more of the Wager Amount Buttons to key in base wager amount. The above
linked to screenshot shows a $40 win wager. For that screenshot I hit the 4
button followed by the 0 button to make the interface arrive at a wager amount
of $40.
2. Click
the Wager Type Button that corresponds to the type of wager (pool) for the bet
you are making. The above linked to screenshot shows a $40 win wager. For that
screenshot after hitting the 4 button and the 0 button to make the interface
arrive at the $40 wager amount: I hit the WIN button to tell the interface I
was making a win bet. Note that clicking any of the wager type buttons causes
the appropriate horse number drop down(s) to appear for that wager type (which
leads into the next step below.)
3. Click
the individual horse number(s) on the horse number drop down(s) to indicate
individual horse numbers for your ticket. The above linked to screenshot shows
a $40 win wager on the number 7 horse. For that screenshot, after indicating
wager type in step 2 above, the interface displayed the Leg A
horse drop down and I selected the 7 horse by clicking horse number 7 on the
drop down.
Note that
had I been making an exacta bet (and had I clicked the EXA button) the
interface would have displayed both the Leg A and Leg B horse number drop
downs. Had I been making a trifecta bet (and had I clicked the TRI button) the
interface would have displayed the Leg A, Leg B, and Leg C drop downs. Had I
been making a superfecta bet (and had I clicked the
SUPER button) the interface would have displayed the horse number drop downs
for Leg A, Leg B, Leg C, and Leg D.
4. Verify
ticket detail. Hint: Ticket detail is always displayed in the Ticket Detail
Window.
5. Click
the Write Ticket to Data Entry Sheet Button to persist ticket detail back to
the Data Entry Sheet.
Step 2. Work up Amt Collected.
Screenshot - Amt Collected Tool
Click the Amt Collected field on the Data Entry Sheet and you will be prompted
to launch the Amt Collected Tool. The Amt Collected Tool has two sides to it:
A. The left side which relates to the base amt on YOUR TICKET.
B. The right side which relates to the mutuel payoff reported by the track/chartcaller that is used as a basis for calculating the AMT
COLLECTED.
When the Amt Collected Tool initializes it will pickup the base wager amt that
was persisted (from step 1 above) to the Data Entry Sheet and use it to auto
populate the left side of the interface.
Your job as a user is is to work up the amt collected
and persist it back to the Data Entry Sheet. The steps are:
a. Key in the numbers on the right side of the interface... mutuel payoff and
base amount and hit the Calc Amt
Coll button. This will calculate the amount you
collected on the ticket.
b. Double check your amount collected and persist it back to the Data Entry
Sheet by hitting the Persist To Data Entry Sheet
Button.
Once you get the hang of it, it's actually fast and easy.
WagerHistory Report
Generator
Operating
the WagerHistory Report Generator’s SQL Expression Tool requires at least some
knowledge of sql. A good benchmark is that if you can
run the JCapper Data Window in sql mode then you can
run the JCapper WagerHistory Report Generator with just a short learning curve.
The
WagerHistory Report Generator is a query interface that enables the player to
create and store user defined sql expressions that
can be run against the WagerHistory table. The WagerHistory Report Generator
also comes with a pre-built canned sql report
designed for those of you with little or no interest in writing sql expressions of your own. The WagerHistory Report
Generator contains much of the functionality found in the sql
mode JCapper Data Window. You can use it to create, store, and execute sql expressions. You can use it to execute the pre-built
canned sql report. And just as you can in the JCapper
Data Window, you can break your query results out by almost all of the JCapper
factors you are used to seeing in the Data Window simply by selecting a
breakout factor from the factors drop down prior to executing a query.
The Pre-Built Canned SQL Report
Screenshots
- WagerHistory Report Generator:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen01.jpg
The above
linked to screenshot shows the top section of the Pre-Built Canned SQL Report for my own wager
history. A look at the sql expression driving the
report should tell you the following:
Running the Pre-Built Canned SQL Report
Here are
the steps for running the Pre-Built Canned
SQL Report:
To
select a start date:
Click the start date field to launch the calendar control, select the desired
date on the calendar control, and persist the selected date back to the report
generator by clicking the APPLY button on the calendar control.
To
Select a Short Description Code:
Open up the Short Description Codes drop down and click the desired Short
Description. Note that selecting a Short Description Code is optional and that
if you elect not to select a Short Description Code, the query results returned
by the executed report will not be filtered by Short Description.
Had
I wanted to limit the report to specific track codes, I could have done so by
keying individual track codes into the Track field with the track codes
separated by dash or minus characters like this: AQU-BEL-SAR-WOX.
Had
I wanted to limit the report to a specific race, I could have selected the
appropriate start and end date, keyed a single track code into the Track field,
and keyed the race number into the Race field prior to executing the report.
Had
I wanted to limit the report to multiple horse wagers only, I could have done
so by selecting 4 Multi Horse Wager from the EntryType
drop down prior to executing the report.
Note that the Track, Race, and EntryType fields are optional and that if you elect not to
use them, reports executed by the Report Generator will not be filtered by
these fields.
About the WagerHistory Module Report
Generator: I made the effort to create an
interface that gives you access to as many JCapper breakout factors as
possible. This should be apparent at a glance. When you open up the factors
drop down on the Report Generator, you should instantly recognize the list of
factors as being almost identical to what is available in the SQL Mode JCapper
Data Window. As I write this, more than 90 percent of the factors available to
you in the SQL Mode Data Window are now available to you in the WagerHistory
Module Report Generator. Also know that this part of the interface is still
under construction.
To
Reselect the Pre-Built Canned SQL
Report by Name:
Open up the report names drop down (located at the bottom of the Report
Generator screen just to the right of the SQL button) and select the default
report by name: Summary By Wager Type.
Note: If you attempt to use the Run
Reports button to execute a report other than the Pre-Built Canned SQL Report,
the interface will give you a warning message telling you to select the
Pre-Built Canned SQL Report by name from the reports drop down. Only the
Pre-Built Canned SQL Report can be executed using the Run Report button.
To create, edit, or execute user
defined SQL expressions: Use the SQL button (discussed in the section covering
User Defined SQL Reports below) to bring up the SQL Expression Tool.
Reading the Pre-Built Canned SQL Report
The
Pre-Built Canned SQL Report contains
the following sections:
Note: Behavior for controlling start
range and interval for breakout data displayed by the WagerHistory Report
Generator is exactly the same as that found in the JCapper Data Window. After
selecting a factor from the factors drop down, select desired start range and
interval from their respective drop downs prior to executing the report.
Interpreting
WagerHistory Reports and Retooling to Improve the Bottom Line Going Forward
Up to this
point, my entire focus in this help doc has been spent illustrating how to
operate the JCapper WagerHistory Module.
Now we come
to the heart of the matter: Interpreting
WagerHistory reports and retooling to improve the bottom line going forward!
The HIST Playing Session - Compiling
Wager History Data
On January
11, 2012 I began one of the more mundane playing sessions I have undertaken
since I first started betting horses. The first part of this playing session
would continue until I woke up on a Monday morning some two months later in mid
March and decided to call the first part of the session off. During this part
of the playing session, I made several hundred wagers on horses selected by a
designated group of my A UDMs. The wagers made during this playing session all
had one thing in common. I recorded every single one of them in the then new
JCapper Wager History Module.
During this
part of the playing session, I put very little thought and effort into play or
pass decision making. If current odds at the time the field was headed to the
gate was at or above the odds or value ratio cutoffs stored in the
BettingInstructions field for at least one of the A UDMs selecting the horse –
I bet the horse. If current odds as post time drew near meant that none of the
conditions listed in the BettingInstructions field for the A UDMs selecting the
horse would be met – I passed the horse. That was pretty much the extent of my
play or pass decision making during this part of the session. Unlike most other
playing sessions, I wasn’t the least bit selective when it came to track weight
or the physical appearance of the horse.
If an HDW
data file was available - and if the rebate house where I have an account
carried the track signal – then the track code was loaded into JCapper that
day. Scratches were imported, The Calc Races button
was clicked. The SQL UDM Plays Report Module was launched – and qualifying bets
were made and recorded on horses selected by the designated A UDMs.
So that
these wagers could be identified separately from others I was making during the
same time period, I tagged each one with a unique Short Description Code: HIST.
As you might well guess, HIST stands for history.
The objective for this playing
session was to create a wager history data sample significant enough in size
that I could use it in this help doc to illustrate a successful retooling
strategy.
Along the
way I learned and in some areas relearned
the following:
Screenshot Gallery
Each of the
linked to screenshots below shows the Pre-Built Canned SQL Report displaying WagerHistory table records tagged with
the HIST Short Description Code: http://www.jcapper.com/messageboard/avatars/WagerHistReportGen01.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen02.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen03.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen04.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen05.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen06.jpg
Additional Background Info About the
HIST WagerHistory Sample
The time
period covered in this first set of screenshots begins on January 11, 2012 and
ends on March 11, 2012. There’s nothing magical about the cutoff date. March
11, 2012 was a Sunday and became the cutoff date because when I woke up the
following Monday morning (March 12, 2012)
I felt like I had amassed a large enough wager history sample that maybe
it was now time to try using the data to undergo a successful retooling effort.
Up until
that morning, every day for the past two months, I had been making bets on
horses selected by a handful of A UDMs without putting a whole lot of thought
into play or pass decision making. The primary goal was to make bets on horses
selected by my A UDMs and record the results for later analysis in the
WagerHistory Module.
All of the
bets in the query results presented in this section were tagged with a Short
Description code created specifically for this part of the help doc. I used the
characters HIST (which as you might
guess stands for History.) The idea behind making these bets was that by making
them I would be creating a wager history sample that could later be used to
illustrate a solid retooling process.
At the
beginning I was a little concerned about the cost involved in undertaking such
an effort. I thought about limiting HIST wagers made to a $2.00 maximum just in
case. I knew going in that wagers made would be limited to horses selected by A
UDMs. I did have a history to go back to. I knew from Data Window R&D that
the UDMs I’d be using were running just above break even (pre rebate) when
horses selected by them found themselves racing on surfaces that I deemed to be
speed favoring (pre-race.)
However, I
did not want to limit the HIST wager history data sample to just speed favoring
surfaces. I am fully cognizant of the fact that while profiling track surfaces
might be a key part of my game - not every player out there is willing to (or
even wants to) do the same. While establishing the HIST data sample presented
in this section of the help doc, I downloaded and ran a Calc Races for every
race card file available from HDW for all of the tracks carried by the rebate
house where I play. Rather than worry about the speed favoring or speed tiring
tendencies of the various track surfaces, if a horse was selected by an A UDM,
and if the odds or value ratio cutoffs for the horse were at or exceeded min
odds or value ratio cutoffs recorded ahead of time in the BettingInstructions
field for at least one of the A UDMs selecting the horse - I made and recorded
the bet.
For reasons
stated above, no consideration was given to track weight. All wagers recorded
as part of the HIST sample were simply awarded a Track Weight field value equal
to 2.
The same
thing applies here to evaluations related to the physical appearance of the
horse. While establishing the HIST data sample presented in this section of the
help doc, every wager recorded was awarded a PhysScore
value equal to 3.
Getting
back to the initial trepidation I felt about making wagers with little or no
thought to play or pass decision making:
Rather than
make $2.00 bets while establishing a HIST sample, because wagers made would be
being driven by A UDMs that I had a fair degree of confidence in, I decided to
play to a $2500 bank while using a bet sizing strategy where an effort would be
made to size bets made on each race at or close to 1.75 percent of last known
bank size.
I decided
to do this because:
Before
diving into my interpretations of the HIST sample, here is the screenshot
gallery again:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen01.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen02.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen03.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen04.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen05.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen06.jpg
Interpreting the Data
In the
section below I am going to post each of the screenshots from the above
screenshot gallery, along with my comments about each screenshot.
Screenshot #1 – The Entire HIST
Sample
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen01.jpg:
This first
screenshot shows the top of the Pre-Built Canned
SQL Report for the entire HIST sample. Note that there were 363 win bets and a
little over 150 exotic bets recorded during the time frame when I was compiling
the HIST sample. I’ll also point out that even though I keyed a start date of
January 01, 2012 prior to generating the reports in these screenshots, the data
making up the reports begins on Jan 11, 2012 and ends on March 11, 2012. (I
state that now in the event I have reason to post screenshots of the detail
section of my reports either in this help doc or on the JCapper Message Board
at some later time.) Also note that pre rebate roi for the HIST sample came in
at just over 0.94 for each $1.00 bet. There’s
nothing special going on there. But it does establish a benchmark that can be
compared against results after a retooling effort.
Screenshot #2 – The HIST Sample
Broken Out By UDM Count Neg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen02.jpg
This second
screenshot shows the factor breakout data section with query results from the
HIST sample broken out by the hard count of negative UDMs flagging each horse
that was bet. Note that the values emphasized in this screenshot are those
stored in the UDMCountNeg
field of the WagerHistory table. These values are one and the same as those
created by the interface while auto populating the UDM count fields whenever a Create New Record Sequence is engaged
(discussed above in the Data Entry Sheet section of this help doc.)
There are
several key points I want you to come away with after looking at this
screenshot:
My opinion after looking at this
screenshot: As part of any retooling strategy, it might be wise to consider
scaling back dollars wagered on horses selected by negative expectation UDMs
going forward.
Rider
Names: There’s no
rocket science going on here. I spent some time doing Data Window R&D
(breaking out the second half of 2010 BY RIDER actually) with an eye towards
compiling a list of riders that the data said were underperforming the norm.
There are about 180 rider names on my list. A little time spent using the JCapper Name Selection Tool made short
work of this project. Truth be told I really should go
back and bring the list current but I haven’t touched it since it was first
created. If you ever noticed the grey
font negative expectation UDM named x_belowParRiders2010 on any of the HTML
Reports I posted on the JCapper Message Board and wondered what that UDM was
all about – now you know.
Distance Challenged Horses: This is another minor category of
negative expectation UDM that I use. Here I am identifying the older horse,
using HorseType, that is a confirmed router switching to a sprint distance
today. I have a second negative expectation UDM that flags such horses
returning off of a lengthy layoff - the idea being that such routers are seldom
win candidates in their return sprint race. I have a third UDM that deals with
sprinters stretching out. Again older horses confirmed as belonging in their
distance category – trying to push the envelope by stretching out. Hey, no one
is more painfully aware that every now and then horses flagged by this type of
negative expectation UDM can and do step up to surprise when stretching out or
cutting back – often paying a big mutuel in the process. However, the data in
the HIST sample suggests that some scaling back in betting appears to be in
order when it comes to distance challenged horses
Vet
Scratches: The Data
Entry Sheet Interface in the WagerHistory Module recognizes Vet Scratches and
treats them the same as if the horse were flagged by a negative expectation
UDM. My Scratch BOT settings in the Enhanced Settings Module are set to make
Scratch BOT parse all tracks in the XML rather than only those tracks I might
currently have loaded into JCapper. That means whenever I click the XML button,
Scratch BOT is picking up every Vet Scratch available in the XML and writing it
to my TripNotes table – where it can be picked up
when UDM profiles are generated on race day. I realize not everyone out there
is doing this. Given that the values
shown on this screenshot do reflect Vet Scratches data picked up by the
interface during live play, if you are not operating Scratch BOT in such a way
that you are picking up as many Vet Scratches as possible: You might want to
rethink your way of doing things.
Screenshot #3 – The HIST Sample
Broken Out By CompoundAP Rank
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen03.jpg
This third
screenshot shows the HIST sample broken out by CompoundAP Rank. Note the win
rate and roi in the data sample for horses ranked fifth or worse in CompoundAP.
In my opinion, some degree of scaling back appears to be in order when it comes
to betting horses lacking in early or late pace ability – or some combination
of the two.
Note: The factor breakout section of
the report screenshot displays CompoundAP as SQL-F18 Rank. Behavior for SQL
F-Factors in the WagerHistory Report Generator is exactly the same as that
found in the JCapper Data Window. Clicking the Display Factors button in the
upper right area of the Report Generator Screen causes the interface to display
the user’s SQL Factor Setup. Re-clicking the button causes the interface to
redisplay whatever data was previously displayed in the module’s viewing area.
In this case, CompoundAP is the JCapper factor assigned to F-Slot number 18 in
my SQL Factor Setup. After operating in SQL Mode for a time, you will likely
commit your SQL Factor Setup to memory and seldom find yourself clicking the
Display Factors button.
Screenshot #4 – The HIST Sample
Broken Out By UDM Count (B-Neg)
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen04.jpg
The fourth
screenshot shows the HIST data sample broken out by UDM Count (B-Neg.) What is UDM Count B-Neg? It is
simply the number of Negative Expectation UDMs flagging the horse wagered on
subtracted from the number of B UDMs flagging the same horse. Note the weakness
indicated by the data when the number of B UDMs flagging horses wagered on
fails to outnumber the count for Negative Expectation UDMs.
Note: Results will vary here from
one player to another based on the number and factor makeup of both Negative
Expectation and B UDMs. (Your own mileage may vary.) However, based on the data
in the HIST sample for my own UDMs, a good retooling strategy would appear to
involve scaling back betting on horses where the number of Negative Expectation
UDMs flagging the horse outnumbers the count for B UDMs flagging the same
horse.
Screenshot #5 – The HIST Sample
Broken Out By CPace Numeric Value
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen05.jpg
The fifth
screenshot shows the HIST sample broken out by CPace Numeric Value.
Note: CPace is the factor sitting in
slot number F-20 in my SQL Factor Setup.
Note the
area of weakness in the sample results for horses with low CPace numbers.
Rather than apply something akin to a blanket cutoff, I rolled up my sleeves
and spent some time at the Data Window doing R&D. My thought process went
something like this: If I take shortcuts in the retooling process - if I just
glance at the data and say to myself: “From here on out any horse I bet on
needs to have a CPace value of at least 160” - Operating in that manner has me
ignoring the following fact:
Quality of horses in competition
varies greatly from one track to another and from one class level to another.
Think about
it for a second. Older allowance males at Gulfstream have every right to earn
higher E1 and E2 pace figs (and therefore earn higher CPace numbers) than 5k
claimers at tracks running lesser quality stock such as Beulah and Mountaineer.
Past
experience has taught me that ignoring facts like the above has a way of aiding
the player in generating selections that fail to perform well going forward.
In my
R&D I ended up establishing min CPace values based on AgeOfHorse,
Sex, ClassDescriptor, and Track Code. I was liberal
(hopefully not overly tight) in establishing cutoffs – but cutoffs were
established and applied just the same.
Screenshot #6 – The HIST Sample
Broken Out By UDM Count (A-Neg)
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen06.jpg
The sixth
screenshot shows the HIST data sample broken out by UDM Count (A-Neg.) My
comments for this factor mirror those I wrote about UDM Count (B-Neg) above.
What is UDM
Count A-Neg? It is simply the number of Negative
Expectation UDMs flagging the horse wagered on subtracted from the number of A
UDMs flagging the same horse. Note the weakness indicated by the data when the
number of A UDMs flagging horses wagered on fails to outnumber the count for
Negative Expectation UDMs.
Note: Results will vary here from
one player to another based on the number and factor makeup of both Negative
Expectation and A UDMs. (Your own mileage may vary.) However, based on the data
in the HIST sample for my own UDMs, a good retooling strategy would appear to
involve scaling back betting on horses where the number of Negative Expectation
UDMs flagging the horse outnumbers the count for A UDMs flagging the same
horse.
The Retooling Process Summarized
At this
point I’ve hopefully posted enough screenshots and enough in the way of
comments to have communicated what the retooling process is all about.
Your job
throughout the retooling process is to:
Retooling After the HIST Playing
Session
When I woke
up that Monday morning in the middle of March, 2012 after having compiled wager
history data for horses selected by a handful of A UDMs spanning a two month
period at all tracks available for me to bet, I realized that I probably had
amassed enough wager history data to try a retooling effort.
I spent the
next few days running reports in the WagerHistory Module. I pasted the more
telling ones into a text file (Notepad) so that I could look at them later.
Armed with insights gleaned from data found on those reports, I began the
retooling effort in earnest.
The first
area that I focused on was trying to make some sense out of the interplay
amongst my own UDMs. What did the data say about horses selected by a single A
UDM as opposed to horses where all the A UDMs seemed to be converging? What did
the data have to say about the number of B UDMs flagging a single horse? What
about the combined number of A and B UDMs? How did Negative Expectation UDMs
fit into the picture? This was brand new territory for me. Needless to say it
took me a while – but eventually, after running and looking at lots of wager
history reports, the many interactions amongst my A, B, and Negative
Expectation UDMs began making sense to me.
One of the
most glaring areas of weakness in my game turned out to be situations where the
Negative Expectation UDMs selecting a horse outnumbered the A and/or B UDMs
selecting the same horse. This one was a real eye opener for me because it was
something I had never considered before.
Two
implementation strategies occurred to me.
The first
strategy I considered involved writing out lines of sql
to capture the factor constraints found in each of my Negative Expectation
UDMs, wrapping these inside of parenthesis characters, placing the keywords AND
NOT immediately to the left of the wrapped up expression, and pasting the
entire thing (a fully encapsulated piece of sql that
captured the essence of a negative
expectation UDM) directly into the body of the SQL UDM Definition driving each
of the active A and B UDMs I was using.
If I did
this, I stood to completely avoid betting on horses selected by any negative
expectation UDM. All of my A and B UDMs would simply fail to fire on race day
whenever conditions causing the negative expectation UDM to fire existed.
Horses selected by both A and negative expectation UDMs would be a thing of the
past – as would horses selected by both B and negative expectation UDMs.
However, I
decided against this strategy. Maintenance going forward would be a bear.
What if at
some future point I decided to rework my list of underperforming riders? Or
decided to make some other change to a negative expectation UDM? After changing
the sql for the negative expectation UDM itself, I
would then have to rework the sql for every active A
and B UDM just to effect the same change. So instead of editing the sql from one negative expectation UDM each time a change
was warranted - I was now setting myself up to be editing 15-20 UDMs each time
a change (any change) to a negative expectation UDM was warranted.
Further,
each time a new A or B UDM might be created, I would be required to scour the
UDM Definitions of existing A and B UDMs so that I could find and lift the
negative expectation part so that I could then paste it into the body of the
new UDM.
I instantly
disliked the thought of operating in this fashion. It could easily turn out to
be a maintenance nightmare. No thank you.
From an
ease of maintenance/best practices standpoint, I decided to continue
maintaining positive and negative expectation UDMs as separate entities.
The second
strategy I considered would be relatively simple to implement. What if I took
strengths and weaknesses uncovered during wager history R&D and simply
integrated that new knowledge into my play or pass decision making and bet
sizing during live play?
The only
thing implementing that kind of retooling required would be coming up with a
set of new rules to be added to what I was already doing during live play. The
idea instantly resonated with me, and it was the implementation strategy I
decided to use.
These may
sound simplistic, but here’s what I came up with:
As simple
as some of those may sound, implementing them during live play proved to be a
difference maker.
The HIST Playing Session Continued –
After Retooling
The
screenshots posted in this section show a user defined report that I created
using the Report Generator’s SQL Expression Tool. The stored sql expression used to generate these reports is as
follows:
SELECT * FROM WAGERHISTORY
WHERE (ENTRYTYPE = 2 OR ENTRYTYPE =
4)
AND SHORTDESCRIPTION = 'HIST'
AND UDMCOUNTNEG = 0
AND TRACKWEIGHT > 0
AND TRACKWEIGHT <= 2
AND [DATE] BETWEEN #03/16/2012#
AND #05/15/2012#
ORDER BY [DATE] DESC, TRACKCODE, RACENUMBER,
SHORTDESCRIPTION
The
wagering activity shown in the screenshots below is on horses selected by the
same basic set of A UDMs used to select horses in the HIST playing session
discussed above. The key difference between the wagering activity in the first
part of the HIST sample and the wagering activity presented here is that these
wagers were made after the retooling process (discussed above) was implemented.
These screenshots reflect wagering activity beginning on March 16, 2012 and
ending on May, 15, 2012 – the two month
period immediately following implementation of the retooling process.
Screenshot Gallery
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen12.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen13.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen14.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen15.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen16.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen16b.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen17.jpg
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen18.jpg
Screenshot #12 – SQL Expression
Tool:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen12.jpg
This
screenshot shows the Report Generator SQL Expression Tool. Here I’ve used the
SQL Expression Tool to create and store a sql
expression that can be used to generate of reports that reflect wager history
after the retooling process (described above) has been implemented.
Screenshot #13 – Wager History After Retooling:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen13.jpg
This
screenshot shows the top section of the newly created custom sql report. Note that wager history on this report spans
the two month period (March, 16 2012 through May 15, 2012) immediately
following implementation of the retooling effort (discussed above.)
Screenshot #14 – Wager History
Broken Out By Surface:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen14.jpg
This
screenshot shows wager history spanning the two month time period (March, 16
2012 through May 15, 2012) immediately following implementation of the
retooling effort (discussed above) broken out by Surface.
Note: Prior
to executing the report by hitting the Execute button on the SQL Expression
Tool, I had selected Surface Today as my breakout factor in the Factors
Drop Down on the Report Generator interface.
Note: These
A UDM plays appear solid on dirt surfaces but weak on the turf. Is this the
result of a short term aberration? Or might it possibly be the start of a new
longer term trend? In my opinion, best practice for analyzing wager history
involves making the analysis process something that is ongoing and constant. At
the very least, this (new) area of (potential) weakness bears watching going
forward.
Screenshot #15 – Wager History
Broken Out By Distance Shift:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen15.jpg
This
screenshot shows wager history spanning the two month time period (March, 16
2012 through May 15, 2012) immediately following implementation of the
retooling effort (discussed above) broken out by Distance Shift.
Note: Prior
to executing the report by hitting the Execute button on the SQL Expression
Tool, I had selected Distance Shift as my breakout factor in the Factors
Drop Down on the Report Generator interface.
Note: As
part of the retooling process, I decided to pass horses selected by even one
negative expectation UDM. This would include horses identified as distance
challenged when stretching out or cutting back in distance while moving from
one broad distance category to another (sprint to route or route to sprint.).
I draw your
attention to weakness shown on this report for starters at the edges: Horses
stretching out and/or cutting back 1.5 or more furlongs in distance.
Performance
for starters at the edges on this report is for horses that stayed within the
same (broad) distance category as their previous start. This represents a
slightly different category than starters eliminated through use of the
distance challenged negative expectation UDMs discussed above.
For
example, both printers cutting back from a 7f race to a 5f race and routers
stretching out from an 8f race to a 10f race are shown on this report.
At this
stage, there really isn’t enough data on the report to work with (just 8
starters at the edge in total) for me to consider further corrective action.
That said, performance at the edges as relates to distance shift still bears
watching going forward.
Note:
Horses cutting back a half furlong in distance are showing considerable
weakness on this report. Is this a short term aberration? Or might it be part
of a (larger) big picture trend?
Screenshot #15b – Wager History
(Entire HIST Playing Session) Broken Out By Distance Shift:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen15b.jpg
This
screenshot shows a larger data sample than the preceding one. Here the report
spans the entire HIST playing session (Jan, 11 2012 through May 15, 2012)
broken out by Distance Shift. I have (ever so crudely) underlined the line on
the report for horses cutting back one half furlong in distance. This line is
weaker than the others on the report but still positive. Based on what I see I
am willing to concede the possibility that weakness for this same line in the
preceding screenshot could stem from a short term aberration. The fact that
this (weaker) line occurs in the middle of the report rather than at the edges
leads me to suspect this. I’m reluctant to take corrective action at this point
– but will watch this area going forward and revisit it in the future as more
data becomes available.
Screenshot #16 – Wager History
Broken Out By Distance:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen16.jpg
This
screenshot shows wager history spanning the two month time period (March, 16
2012 through May 15, 2012) immediately following implementation of the
retooling effort (discussed above) broken out by Distance.
Note: Prior
to executing the report by hitting the Execute button on the SQL Expression
Tool, I had selected Distance as my breakout factor in the Factors Drop
Down on the Report Generator interface.
Note that
horses competing at shorter sprint distances are showing weakness on this
report. Is this a short term aberration? Or might it be part of a (larger) big
picture trend?
Screenshot #16b – Wager History
(Entire HIST Playing Session) Broken Out By Distance:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen16b.jpg
This
screenshot shows a larger data sample than the preceding one. Here the report
spans the entire HIST playing session (Jan, 11 2012 through May 15, 2012)
broken out by Distance.
I have
(ever so crudely) circled the lines on the report for horses competing at
shorter sprint distances. These lines are weaker than the others on the report
but are still positive. Based on what I see (for 120+ plays spanning these
lines) I am willing to concede the possibility that weakness for these same
lines in the preceding screenshot could stem from a short term aberration.
However, these (weaker) lines occur at one edge of report rather than in the
middle. That can often be a good indicator that weakness seen in one sample will
continue well into the next. This has me concerned. While not ready to take
corrective action just yet I WILL be watching this area very closely going
forward (more closely than the Distance Shift area discussed in the previous
screenshot pair.)
Screenshot #17 – Wager History
Broken Out By Class Descriptor:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen17.jpg
This
screenshot shows wager history spanning the two month time period (March, 16
2012 through May 15, 2012) immediately following implementation of the
retooling effort (discussed above) broken out by Class Descriptor.
The handful
of plays for CO and AO races shows weakness. However, there is insufficient
data (not enough plays) on the report to make me feel comfortable taking
corrective action at this point.
Screenshot #18 – Wager History
Broken Out By Compound PaceFit Numeric Value:
http://www.jcapper.com/messageboard/avatars/WagerHistReportGen18.jpg
This
screenshot shows wager history spanning the two month time period (March, 16
2012 through May 15, 2012) immediately following implementation of the
retooling effort (discussed above) broken out by Compound PaceFit
Numeric Value.
Looking at
the report, I see weakness at the lower edge of the data sample – where
Compound PaceFit is less than 40. There aren’t a
whole lot of plays to work with but I am troubled by what I see here. If you’ll
recall, item number two from my retooling strategy reads as follows:
2. Scale back bet size somewhat if
the horse is overmatched pace-wise (based on my own combination of
CompoundPaceFit, CPace, EarlyConsensus, CompoundLate, and LateConsensus.)
The numbers
on the report are telling me that room for improvement exists. From here, I am
willing to take a harder stance and alter rule number two from my retooling
efforts to read as follows:
2. Scale back bet size significantly
(or simply pass) if CompoundPaceFit numeric value is less than 40.
Summary
When I
think about record keeping in terms of best practices it occurs to me that
review of wager history data is not optional. It should be an integral part of
your game. Nor is record keeping and analysis of wager history data a one time
thing. Proper record keeping is something that is both constant and ongoing.
--Jeff
Platt
As I mentioned earlier, this help doc is still being written. Check
back frequently as I will be updating this doc whenever I can squeeze in free
time to add to it.