JCapper UPR Tools Expression Builder - MLR Multi Logistic Regression Models - Help Doc

Creating MLR (Multi Logistic Regression) models in the JCapper Expression Builder

In this help doc, I'm going to:

Provide BASIC OPERATING INSTRUCTIONS for creating an MLR (Multi Logistic Regression) Model in the JCapper Expression Builder.^{1}

Present an Overview of the IVLookup table - what it does and how it can be used to store entries that will make your MLR GroupNames track-surface-distance specific.

Provide BASIC OPERATING INSTRUCTIONS for using the IVLookup Quick Start Tool to create a set of quick start entries in the IVLookup table - that when edited - will make your GroupName track-surface-distance specific for an individual SubGroup.

Provide BASIC OPERATING INSTRUCTIONS for using the IVLookup Table Interface to edit quick start entries in the IVLookup table - to make your GroupName track-surface-distance specific for an individual SubGroup.

After reading this help doc:

You should be able to use the Expression Builder in UPR Tools to create and edit Method 4 MLR GroupNames of your own.

You should be able to use the IVLookup Quick Start Tool to create a set of quick start entries in the IVLookup table - that when edited - will make an MLR GroupName track-surface-distance specific for that SubGroup.

You should be able to use the IVLookup Table Interface to edit quick start entries in the IVLookup table - to make an MLR GroupName track-surface-distance specific for that SubGroup.

You should understand the differences in JCapper between non MLR GroupNames and MLR GroupNames.

Footnotes:

1. The Expression Builder is part of UPR Tools and is only available in JCapper Platinum.

BASIC OPERATING INSTRUCTIONS for creating an MLR (Multi Logistic Regression) Model in the JCapper Expression Builder:

BEFORE working with a GroupName in UPR Tools:

ALWAYS make a backup copy of your c:\2004\JCapper.mdb file.

--Note: This is the file that contains the table entries that collectively makeup the definitions for your UDMs, UserFactors, JPR, and UPR.

If you accidentally screw up a GroupName the easiest recovery path is restoring the last known good backup of your c:\2004\JCapper.mdb file.

So make a backup of your c:\2004\JCapper.mdb file -- NOW -- before you go any further.

Launch the Expression Builder in UPR Tools.

Key a GroupName into the GroupName field.

Select 4 MLR from the Method Drop Down.

Check the Overwrite GroupName box beneath the Propagate button.

Click the MLR Quick Start button and answer Yes at the prompt to launch the MLR Quick Start Tool.

On the MLR Quick Start Tool:

Key a Base into the MLR Base Field and click the |<| button to the right of the MaxExp field. This will cause the interface to autopopulate the MaxExp field with the correct Max Exponent for your MLR Base.

Hint: Or just go with the default 2.71828 (Euler Number) as your MLR Base with Max Exponent 709.

Never leave the MaxExp field blank. For complete discussion of Max Exponents in JCapper read the Notes and Comments section at the bottom of this Help Doc.

Click the Behavior Field to launch the Behavior Tool -- And on the Behavior Tool: Select a default behavior from the drop down and hit the Apply button.

Hint: Or just go with Behavior 43 which works for most models - and you can change it later on a per factor basis.

Check the Lookup box (just to the right of the Weight field.)

Hint: This activates use of the IVLookup table for your GroupName.

Open up the Factor Count drop down and select the number of factors in your model not counting the base.

Hint: You should know this ahead of time (based on statistical research) prior to creating the GroupName.

Click the Apply button and answer Yes at the prompt.

This will cause the interface to close the MLR Quick Start Tool - and autopopulate your GroupName with the number of factors selected in the previous step.

Note: The above screenshot shows The MLR Quick Start Tool after performing the above steps (with 4 new factors selected from the drop down) and after clicking the Apply button.

Also note that the MLR Base Field contains the default value of 2.71828 (the Euler Number) and that the MaxExp field contains the default Max Exponent value of 709 which is based the Euler Number.

--Hint: For complete discussion of Max Exponents in JCapper read the Notes and Comments section at the bottom of this Help Doc.

Note: The above screenshot shows The Expression Builder after using the MLR Quick Start Tool to perform the above steps.

Also note the following:

The MLR Base and 4 new factors (not yet named) have been auto generated and added to the GroupName.

The calculation for individual horse scoring within the model is displayed in the top center area of the Expression Builder.

The Behavior field for the MLR Base has been (automatically) set to the correct value (42.)

The Behavior field from the MLR Quick Start Tool has been applied to each of the non MLR Base factors.

The Weight field from the MLR Quick Start Tool has been applied to each of the non MLR Base factors.

The Lookup box has been auto checked for each of the non MLR Base factors.

Although not displayed visually on the interface: Track, MinDist, MaxDist, and Surface from the MLR Quick Start Tool have also been applied to each of the non MLR Base factors.

Each of the 7 factor rows on the interface has its own Template button. (And the Template buttons for the non MLR Base factors are labeled as Template F2 through Template F7.)

The GroupName has not yet been saved to the ImplactValues table. (If you were to exit the Expression Builder without saving the GroupName you would lose any work you've done up to this point.)

Give each non MLR Base factor in the model its real Factor Name.

On the Expression Builder:

Click the Template button for the first non MLR Base factor in the model to launch the Template Builder.

Hint: This would be the Template F2 button in the above screenshot.

On the Template Builder:

Open up the Factors drop down and select the factor you want by name.

Hint: The drop down responds to keystrokes. If you want CFA - after opening up the drop down and keying the letters CF - the drop down will "jump" to CFA.

Note: The above screenshot shows The Template Builder just before selecting CFA from the Factors drop down.

Note: The above screenshot shows The Template Builder after selecting CFA from the Factors drop down.

Selecting a factor by name from the drop down causes the interface to autopopulate the Factor field with the name of the selected factor. Note that CFA now appears in the Factor field (instead of FACTORTOBENAMED.)

Edit the Behavior field as needed.

--Hint: The value of the Behavior field can sometimes depend on observations made during statistical research.

For example, if you performed statistical research on exported JCapper data and you did not transform numeric value for a factor in any way: Then you should probably use for that factor (as shown in the above screenshots.)

However, if you did transform the data for a factor (and let's say for example purposes) that you used Log of numeric value for a given factor in your statistical research: Then you should probably use for that factor instead.

Important! As I type this (05-28-2017) there is a programming quirk in JCapper I need to make you aware of.

If you are using ProbExpressions as factors in MLR models:

1. Be aware that yes you can use ProbExpressions as factors in MLR models.

2. But you need to use the Behavior for the ProbExpression from your SQL Factor Setup instead of (say) Behavior 43 (Factor Numeric Value) x (Beta Coeff) like you would for a normal factor in an MLR model.

--Example: The Expression Builder screenshot in step 8 (below) shows me using a ProbExpression named "_RAIL100_B23-4UPR" (without the quotes.) This is a ProbExpression that scores RailPosition. In my SQL Factor Setup this
ProbExpression was given Behavior 23 WinPlacePct. The observations I made about this factor using exported data during statistical research were based on RailPosition stats compiled using Behavior 23 Win-Place Pct.

The correct way to assign Behavior for this factor in an MLR model is to use the same Behavior that was used to generate the data set: in this case Behavior 23 Win-Place Pct.

And although it seems logical that you SHOULD be able to use Behavior 43 (Factor Numeric Value) x (Beta Coeff) for ProbExpressions in an MLR model: That is not the case.

The quirk is: JCapper has not been programmed to do that.

This is something I may decide to address in a future program update.

But for now - for ProbExpressions you are using in MLR models: Use the same Behavior that was used to generate the data set. (Which, FYI, is also the same Behavior you gave to the ProbExpression in your SQL Factor Setup.)

-jp

.

Edit the Weight field as needed.

--Hint: If your model is going to be track-surface-distance (or SubGroup) specific: Leave the Weight field "as is" for now. You will edit it later in the IVLookup Table Interface (as shown in a later step.)

The only time you would edit the Weight field in this step is when you don't want your model to be track-surface-distance (or SubGroup) specific
and you aren't plannig to create any entries for your model in the IVLookup table.

If that's the case you should edit the Weight field now (in this step.)

Click the APPLY button to close the Template Builder - and port your work from the Template Builder over to the Expression Builder.

Note: The above screenshot shows The Expression Builder after using the Template Builder to give the first non MLR Base factor in the model its real factor name (CFA.)

Repeat the above steps until you have given every non MLR Base factor in the model its real factor name.

Save your GroupName to the ImpactValues table by checking the Overwrite box, clicking the Propagate button, and answering Yes at the prompt.

Note: The above screenshot shows The Expression Builder after using the Template Builder to give every non MLR Base factor in the model its real factor name and after clicking the Propagate button with the Overwrite box checked to Save the GroupName.

That's It!

At this point the GroupName has been saved to the ImpactValues table. (But we aren't done yet.) We still have to create entries for the GroupName in the IVLookup table to make it Track-Surface-Distance (or SubGroup) specific.

• Notes:

Under normal circumstances for most (if not all) models - the coefficients for the factors in the model will vary according to factor significance determined by statistical research.

If you give the above screenshot a close look - you should notice that all of the weights (or beta coefficients) are the same for all of the non MLR Base factors in the model. This should tell you we still have work to do.

Also, if you'll recall from the work done in the Template Builder - we have not (yet) given the model any entries to make it track, surface, or distance specific. (This too might suggest there is still work to do.)

-jp
.

The IVLookup Table - Overview

In non MLR GroupNames - and in previous versions of JCapper - all of the table entries in UPR Tools are stored in the ImpactValues table.

But MLR models are different than non MLR models.

Starting with all versions of JCapper Platinum Build 198 published 05-01-2017 and later -- for method 4 MLR GroupNames:

The IVLookup table in the c:\2004\JCapper.mdb file is where you should store any and all entries to make method 4 MLR GroupNames track, surface, and/or distance specific.

In the above screenshots - the calculation for individual horse scoring within the model is displayed in the top center area of the Expression Builder.

If you look closely at those screenshots, for the non MLR Base factors in the model where the Lookup box is checked: The words "OR LOOKUP" (without the quotes) are displayed to the right of the factor Weight.

However, if you uncheck the Lookup box for one of the non MLR Base factors in the model: The words "OR LOOKUP" (without the quotes) are no longer displayed. And the formula just shows factor Weight.

This behavior suggests what the IVLookup table is used for.

• During a Calc Races - when processing of an MLR GroupName is performed:

The interface reads the entries for the model from the ImpactValues table. At this point the interface has GroupName, Factor, and the generic Weight (or beta coefficient) that was saved to the ImpactValues table when the Propagate button was clicked.

During horse scoring for the current factor - the interface makes an eval (True or False) based on the value of the IVLookup field - which in turn is based on whether or not the Lookup box was checked for the current factor when the Propagate button was clicked.

• During horse scoring for the model, if IVLookup is True - meaning that the Lookup box was checked for the current factor:

The interface checks the IVLookup table for a set of entries that are a match for the current GroupName-Track-Surface-Distance-Factor.

If a matching set of entries is found in the IVLookup table: The interface ignores the generic Weight from the ImpactValues table -- and instead uses the GroupName-Track-Surface-Distance-Factor specific Weight from the IVLookup table.

If a matching set of entries is NOT found in the IVLookup table: The interface uses the generic Weight from the ImpactValues table.

• During horse scoring for the model, if IVLookup is False - meaning that the Lookup box was not checked for the current factor:

The interface simply uses the generic Weight from the ImpactValues table.

This info model - of fetching factor weight from the ImpactValues table - provides a simple way for your MLR GroupNames to be Track, Surface, and Distance specific on a per factor basis within the model.

• Suppose for the sake of argument you invest some time and develop a working MLR model that uses weights that vary by factor according to significance - and you want the model to use the same factors and weights - no matter what the track-surface-distance:

Create the base framework for the factors in the model using the steps presented above - Just make sure you edit Weight for each factor while you are in the Template Builder (in step 7 above.)

Here, you are operating in the simplest possible way. All of the entries for your GroupName will be stored in the ImpactValues table. (And you will be not be using the steps presented below to create entries in the IVLookup table because your GroupName is not track-surface-distance specific.)

• Suppose for the sake of argument you invest significant R&D time and develop a working MLR model that uses weights that vary by factor according to significance - and you want the model to use the same factors - but with a different set of weights - for each of the surface-distances of a single track code:

Create the base framework for the factors in the model using the steps presented above.

Then use the IVLookup Quick Start Tool and the IVLookup Table Interface to create sets of GroupName-SubGroup-Track-Surface-Distance-Factor-Weight entries in the IVLookup table - one set of entries per SubGroup - as shown below.

Here, the base framework/factors in the model entries are stored in the ImpactValues table. And the SubGroup entries that enable your GroupName to be Track-Surface-Distance specific are stored in the IVLookup table.

• Suppose for the sake of argument you invest serious R&D time and develop a working MLR model that uses weights that vary by factor according to significance - and you want the model to use the same factors - but with a different set of weights - for each of the surface-distances at many track codes:

Create the base framework for the factors in the model using the steps presented above.

Then use the IVLookup Quick Start Tool and the IVLookup Table Interface to create sets of GroupName-SubGroup-Track-Surface-Distance-Factor-Weight entries in the IVLookup table - one set of entries per SubGroup - as shown below.

Here, the base framework/factors in the model entries are stored in the ImpactValues table. And the SubGroup entries that enable your GroupName to be Track-Surface-Distance specific are stored in the IVLookup table.

But the key difference is you will have LOTS of SubGroup entries stored in your IVLookup table.

-jp
.

The IVLookup Quick Start Tool

The IVLookup Quick Start Tool is designed to allow you to quickly auto-generate a set of quick start entries in the IVLookup table - that when edited - will make your MLR GroupName track-surface-distance specific for an individual SubGroup.

Let's start with SubGroups:

Q. What is a SubGroup?

A. In JCapper a SubGroup is a named collection of entries designed to handle a specific category - such as an individual track-surface-distance.

For example, both Belmont and Saratoga have two turf courses - an outer main turf course - and an inner turf course.

In UPR Tools, you could create one set of entries designed specifically for Belmont's inner turf course.

You could give that set of entries a name by keying "BEL-t" (without the quotes) into the SubGroup field. -- And at that point, in JCapper, that set of entries would qualify as a SubGroup.

You could narrow things down even further - and create separate sets of entries - each specifically designed to handle the different distances that are run on Belmont's inner turf course.

You could name one set of entries as "BEL1320t" (BEL as the track code with 1320 yds as the dist and lower case t for inner turf) and name another set of entries as "BEL2200t" (BEL as the track code with 2200 yds as the dist and lower case t for inner turf) -- and each would qualify as a separate SubGroup.

How you organize your SubGroups, the degree to which you use them to narrow things down, naming conventions, or whether you decide to use them at all is entirely up to you.

The SubGroup fields in the ImpactValues and IVLookup tables are meant to provide you with a way to organize the (sometmes hundreds of) entries within a single GroupName.

BASIC OPERATING INSTRUCTIONS for using the IVLookup Quick Start Tool to create a set of quick start entries in the IVLookup table - that when edited - will make your MLR GroupName track-surface-distance specific for an individual SubGroup:

With your MLR GroupName pulled up and displayed in the Expression Builder:

Click the IVLookup Quick Start button and answer Yes at the prompt to launch the IVLookup Quick Start Tool.

Note: The above screenshot shows The IVLookup Quick Start Tool after it is first launched with the _Contrast3 GroupName pulled up and displayed in the Expression Builder (background.)

On the IVLookup Quick Start Tool:

Make sure the Active box is checked.

Make sure your GroupName appears in the GroupName field.

Select the number of non MLR Base Factors in your model from the Row Count drop down.

Hint: Or alternately, click the | << | button and let the interface auto select the correct number of autoname rows for you.

The above screenshot shows The IVLookup Quick Start Tool after clicking the | << | button and answering Yes at the prompt.

Note the following:

The AutoName function has been toggled "ON" (AUTONAME is displayed in the Factor field.)

4 AutoName rows is displayed in the Row Count drop down.

4 is the number of non MLR Base Factors in the model.

Key a 3 character track code into the Track field.

Hint: But only if your intent is to make your MLR GroupName track specific.

Here, for purposes of example, I will be illustrating IVLookup table entries for 6f races on Belmont's inner turf course.
For that reason, I will be using "BEL" (without the quotes.) But you should use the track code for the SubGroup you are trying to create.

Key a SubGroup name into the SubGroup field.

Hint: Here, for purposes of example, I will be illustrating IVLookup table entries for 6f races on Belmont's inner turf course.
For that reason, I will be using "BEL1320t" (without the quotes.)
But you should use a SubGroup name that works for the SubGroup you are trying to create.

Warning! Do not select Surface and Distance from the Surf-Dist drop down on the IVLookup Quick Start Tool.

Instead: Use the separate fields for Surface, MinDist, and MaxDist.

Why: As I was writing this section of the Help Doc I noticed that while selecting a Surface-Dist from the drop down was correctly auto-populating
the separate fields for Surface, MinDist, MaxDist, and SubGroup...

It was also causing the following unintended behavior: Selecting Surface and Distance from the drop down was causing the selected surface and Dist to be pasted into the ClassDescriptor field (instead of the missing Notes field where I intended it to go.)

I'll get this fixed in a future program update.

But for now: Use the separate fields for Surface, MinDist, MaxDist, and SubGroup (instead of the Surface-Dist drop down.)

05-27-2017

-jp
.

Key a single character text surface indicator into the Surface field.

Hint: Valid options are:

D - main or outer dirt course

d - inner dirt course

D* - all dirt courses

T - main or outer turf course

t - inner turf course

T* - all turf courses

* - all courses turf, off the turf, or dirt

Here, for purposes of example, I will be illustrating IVLookup table entries for 6f races on Belmont's inner turf course.
For that reason, I will be using "t" (without the quotes.) But you should use the Surface for the SubGroup you are trying to create.

Key numeric distance in furlongs into the MinDist field.

Here, for purposes of example, I will be illustrating IVLookup table entries for 6f races on Belmont's inner turf course.
For that reason, I will be using "6" (without the quotes.) But you should use the MinDist for the SubGroup you are trying to create.

Key numeric distance in furlongs into the MaxDist field.

Here, for purposes of example, I will be illustrating IVLookup table entries for 6f races on Belmont's inner turf course.
For that reason, I will be using "6" (without the quotes.) But you should use the MaxDist for the SubGroup you are trying to create.

Make sure the Append box (just above the Propagate button) is checked.

Hint: Accidentally checking the Overwrite box will cause the IVLookup Quick Start Tool to overwrite all existing entries in the IVLookup table for the GroupName in the GroupName field.

The ONLY time you should check the Overwrite box is when you want to start over and blow away the existing entries in the IVLookup table for your GroupName. (So be careful.)

Click the Propagate button, double check your work, and answer Yes at the prompt to auto-propagate a set of quick start entries in the IVLookup table for your SubGroup.

The above screenshot shows The IVLookup Quick Start Tool after clicking the |Propagate| button.

Note the following:

The Active box is checked.

The AutoName function has been toggled "ON" (AUTONAME is displayed in the Factor field.)

4 AutoName rows is displayed in the Row Count drop down.

4 is the number of non MLR Base Factors in the model.

I have keyed "BEL1320t" (without the quotes) into the SubGroup field.

I have keyed "t" (lower case t without the quotes for inner turf) into the Surface field.

I have keyed "6" (distance in furlongs without the quotes) into the MinDist field.

I have keyed "6" (distance in furlongs without the quotes) into the MaxDist field.

All of these values are presented in the confirmation prompt.

Clicking Yes the confirmation prompt causes the interface to auto-propagate a set of quick
start entries having the displayed parameters to the IVLookup table for the SubGroup.

That's it!

At this point a set of quick start entries for the SubGroup are now sitting in the IVLookup table.

The next step would be to launch the IVLookup Table Interface - view the entries for that SubGroup - and edit factor Weight to finalize the enties for that SubGroup.

The IVLookup Table Interface

The IVLookup Table Interface is designed to enable you to view and edit entries in the IVLookup table (ideally) for an individual SubGroup.

Earlier in this Help Doc (above) in step 6d of the instructions for the MLR Quick Start Tool - I said the following:

"Open up the Factor Count drop down and select the number of factors in your model not counting the base.

Hint: You should know this ahead of time (based on statistical research) prior to creating the GroupName."

Before going any further I should probably address the "You should know this ahead of time (based on statistical research)" comment I made in the above quote:

Over the past few years I've become a big proponent of:

Using the JCX File Exports Module to export StarterHistory data out to .CSV files on my hard drive.

Transforming the data a bit.

Running .CSV files containing transformed data through the mlogit module in r.

Creating MLR models based on observations made about the data using output from r.

From there, using the Expression Builder in JCapper UPR Tools to write entries to the ImpactValues and IVLookup tables as shown in this Help Doc.

My MLR GroupNames basically end up being representations of the models I've created in r.

This process allows me to see numbers from the models I've created in r on a JCapper HTML Report and use them in UserFactors, UPR, and UDMs during live play.

And while this process requires that you possess at least some understanding of predictive modeling... the more the better actually... and that you perform a significant amount of work outside of JCapper... and while MLR models are not without their limitations...

I find this process and MLR models to be superior to the linear models I used to create in JCapper.

Screenshot: Exported JCapper StarterHistory data (BEL 6f inner turf) in r's mlogit module:

Notes:

F08 is CFA and has the greatest significance as indicated by the low Pr(>\t\).

F06 is AFR.

F31 is a ProbExpression I used to score RailPosition for today's track-intsurface-dist.

FTSCount is the number of first time starters in today's race.

The Estimate column displays the beta coefficients.

FYI, these factors are the same as those shown in the Expression Builder screenshots above.

BASIC OPERATING INSTRUCTIONS for using the IVLookup Table Interface to edit quick start entries in the IVLookup table
- to make your GroupName track-surface-distance specific for an individual SubGroup:

On the IVLookup Quick Start Tool:

Key or rekey GroupName, Track, and SubGroup into their respective fields.

Double check your work.

It's important that the GroupName, Track, and SubGroup displayed on the face of the IVLookup Quick Start Tool
are correct for the SubGroup you are about to edit in the IVLookup Table Interface.

Check the box labeled IVLookup-Current GroupName, Track, SubGroup. Then click the IVLookup Table Interface button
to launch the IVLookup Table Interface.

If you click the the IVLookup Table Interface button when the box labeled IVLookup-Current GroupName, Track, SubGroup is checked:

The IVLookup Table Interface will pull up and display entries for the GroupName, Track, and SubGroup displayed on
the IVLookup Quick Start Tool - provided those entries exist in the table.

--Hint: This is what you want.

If you click the the IVLookup Table Interface button when the box labeled IVLookup-Current GroupName, Track, SubGroup is not checked:

The IVLookup Table Interface will pull up and display unfiltered IVLookup table entries.

--Hint: This is not what you want. (Because you have to scroll through all of the entries in the table: The likelihood of accidentally editing the wrong row beomes higher.)

Screenshot: the IVLookup Quick Start Tool just before clicking the IVLookup Table Interface button:

Notes:

GroupName, Track, and SubGroup have been keyed into their respective fields.

The IVLookup-Current GroupName, Track, SubGroup box has been checked.

Clicking the IVLookup Table Interface button will launch the IVLookup Table Interface and cause it
to display entries for the GroupName, Track, and SubGroup displayed on the IVLookup Quick Start Tool.

In the ImpactValues Table Interface:

Working one factor at a time:

Update the Weight fields for the non MLR Base factors in the model with the beta coefficients from your statistical research.

Hint: After keying a coefficient into the Weight field - move focus to the next field by either clicking the next field or by pressing the Tab key on your keyboard. (Either way works.)

As soon as your mouse cursor leaves the field where you were typing: The value in the field you just left will appear to "jump" - and the interface will write that value to the table.

Screenshot: the IVLookup Table Interface after editing Weight for the first factor:

Notes:

The beta coefficient (highlighted) has been keyed into the Weight field for the first factor.

The mouse cursor is now in the next field because the user pressed the Tab key.

As soon as focus was given to the next field the interface wrote the coefficient to the table.

From here the user needs to key coefficients into the Weight fields for the remaining factors.

Repeat the above step until the Weight fields for all factors in the model contain their beta coefficients.

Screenshot: the IVLookup Table Interface after keying coefficients into the Weight field for all factors in the model:

Notes:

Beta coefficients have been keyed into the Weight field for all factors in the model.

At this point we are done with the current SubGroup and can x-out of the IVLookup Table Interface.

After that, repeat the above steps until every SubGroup is handled by the model.

Double check your work and x-out of the IVLookup Table Interface.

Repeat the above steps until the IVLookup table contains entries to handle every track-surface-distance (or SubGroup) you intend to handle in the model.

That's it!

At this point the entries in the IVLookup table for the model are complete - and your MLR GroupName is now ready for forward or validation testing.

-jp

.

Differences in JCapper between non MLR GroupNames and MLR GroupNames:

• Non MLR GroupNames:

Non MLR models are different than MLR models. But they are the same in one respect.

BEFORE working with a GroupName in UPR Tools:

ALWAYS make a backup copy of your c:\2004\JCapper.mdb file.

Like MLR GroupNames: Non MLR GroupNames can be used to create UserFactors, JPR, or UPR.

Unlike an MLR GroupName: All of the table entries for a non MLR GroupName are stored in the ImpactValues table.

After you have created the base model: The way to make a non MLR GroupName track-surface-distance (or SubGroup) specific is to add track-surface-distance (or SubGroup) specific entries to the the ImpactValues table.

ImpactValues table entries that are later added to a non MLR GroupName can be for new factors - or factors that weren't part of the GroupName's original factor mix.

Again, you can do this for almost all of the supported factors in JCapper -- even if that factor doesn't exist yet in the GroupName.

During a Calc Races: to handle ImpactValues table entries that were later added to a non MLR GroupName for new factors that weren't part of the GroupName's original factor mix.

This info model - of adding entries to the ImpactValues table for factors that weren't part of the GroupName's original factor mix - allows you to make a non MLR GroupName track-surface-distance (or SubGroup) specific.

Classic View in the Impact Values Table Wizard is the recommended tool of choice for editing/modifying Non MLR GroupNames.

• MLR GroupNames:

MLR models are different than non MLR models. But they are the same in one respect.

BEFORE working with a GroupName in UPR Tools:

ALWAYS make a backup copy of your c:\2004\JCapper.mdb file.

Like Non MLR GroupNames: MLR GroupNames can be used to create UserFactors, JPR, or UPR.

Unlike an a Non MLR GroupName: Table entries for MLR GroupNames can be stored in both the ImpactValues table and the IVLookup table.

--Typically: Entries describing the base model only are stored in the ImpactValues table.

These would be entries created in the MLR Quick Start Tool and/or Template Builder for:

GroupName

Method

Base

Max Exponent

Factor Names

Behaviors

Generic Factor Weight

Generic Surface, MinDist and MaxDist

--Then: Entries for the purpose of making the model track-surface-distance (or SubGroup) specific are added to the IVvLookup table.

These entries are created in the IVLookup Quick Start Tool and/or the IVLookup Table Interface for:

GroupName

SubGroup

Track

Surface, MinDist, and MaxDist

Factor Weight

After you have created the base model in the ImpactValues table: The way to make an MLR GroupName track-surface-distance (or SubGroup) specific is to add track-surface-distance (or SubGroup) specific entries to the the IVLookup table for the IVLookup enabled factors in the model.

--Note: means that the Lookup box for that factor was checked when the GroupName was last saved in the Expression Builder.

IVLookup table entries that are later added to an MLR GroupName cannot be for new factors that are not part of the GroupName's current factor mix.

A factor must be part of an MLR GroupName's factor mix before adding track-surface-distance (or SubGroup) entries for that factor to the IVLookup table.

The correct way to make an MLR GroupName handle a factor in a track-surface-distance (or SubGroup) specific manner is to:

Include that factor and make sure its Lookup box is checked when you first create and save the model in the Expression Builder.

Use the IVLookup Quick Start Tool to create a set of quick start entries in the IVLookup table at the SubGroup level.

Use the IVLookup Table Interface to edit factor Weight for the quick start entries created in the previous step.

Note that you can make an MLR GroupName track-surface-distance (or SubGroup) specific for almost all of the supported factors in JCapper -- but as I type this on 05-29-2017 -- the factor must exist as IVLookup enabled in the factor mix of GroupName.

Also note that, long after an MLR GroupName has been created, you can pull up that MLR GroupName in the Expression Builder -- add a new factor to the model -- and save the GroupName by clicking the Propagate button. From there you can use the IVLookup Table interface (or even Microsoft Access) to add one entry or row for the new factor to each SubGroup in the IVLookup table.

And while this strategy does work... Because some of the models I use have many many SubGroups -- doing this can be a LOT of work.

I've actually found that creating a new GroupName from scratch - complete with IVLookup table entries at the SubGroup level - to be the easier way to go.

During a Calc Races: to handle IVLookup table entries that were later added to an MLR GroupName - but only for factors that are IVLookup enabled in the GroupName's current factor mix.

Note: The part of the above sentence came about because the current programming for MLR GroupNames in JCapper is centered around the formula for individual horse scoring displayed in the top center area of the Expression Builder.

Simply put: I wanted the user to be able to clearly see all of the factors in an MLR model in the Expression Builder - and I wanted the user to be able to see how all of the factors in an MLR model are being used for single horse scoring.

I may decide to revisit this in a future program update. But as I type this on 05-29-2017 that's the way JCapper has been programmed to handle MLR models.

This info model - of adding entries to the IVLookup table for factors that are IVLookup enabled in the GroupName's current factor mix - allows you to make an MLR GroupName track-surface-distance (or SubGroup) specific.

The Expression Builder in UPR Tools is the recommended tool of choice for creating and editing MLR GroupNames.

-jp

.

Notes and Comments

• Individual Horse Scoring in MLR Models:

The formula for Individual Horse Scoring in MLR Models is displayed in the top center area of the Expression Builder.

The formula, where N is the number of factors in the model, is:

horseScore = Base ^ ((coeff1 x factorVal1) + (coeff2 x factorVal2) + (coeff3 x factorVal3)... + (coeffN x factorValN))

Because of the way Beta Coefficients are calculated in a Logistic Regression Max Likelihood Function:

You should use the Euler Number or 2.71828 as your Base whenever possible.

So that the formula for individual horse scoring for a model with N factors looks like this:

horseScore = 2.71828 ^ ((coeff1 x factorVal1) + (coeff2 x factorVal2) + (coeff3 x factorVal3)... + (coeffN x factorValN))

• GroupName Factor Scoring for Individual Horses in MLR Models:

After Individual Horse Scoring has been performed using the forumla shown above:

Individual Horse Scores for all horses in the race are summed to produce a Race Total.

Individual Horse Score for each horse in the race is then divided by the Race Total to produce a Decimal Prob Estimate for each horse.

--Note: Except for minor rounding error, the sum of the Decimal Prob Estimates for each horse in the race is equal to the Race Total.

During a Calc Races: The Decimal Prob Estimate for each horse is (or becomes) Factor Numeric Value generated by the MLR GroupName.

--Example: If the GroupName for the MLR model is "USERFACTOR4" (without the quotes) and the Decimal Prob Estimate (described above) for the #1 horse in the race is 0.1873 then USERFACTOR4 for the #1 horse is 0.1873.

From there the interface will use the Single Horse Scoring Formula and Decimal Prob Estimate procedure to generate USERFACTOR4 numeric factor value for all of the remaining horses in the race.

Then afterwards: The interface will calculate USERFACTOR4 RANK and GAP for every horse in the race before moving on to USERFACTOR5.

• Note and necessary tangent about Max Exponents in JCapper:

JCapper is written in Visual Basic 6.0. The VB6 compiler has a limitation when it comes to calculations that involve extremely large numbers. The data type capable of holding the largest possible number in VB6 is called a Double.

According to the documentation at the above link, the largest possible value for a variable declared as a Double is: 1.79769313486231570E+308 for positive values.

And while that might seem like a very large number... it is actually.

But it isn't so large a number that you won't occasionaly get an overflow error in Visual Basic because strict application of the formula for single horse scoring presented above results in a value bigger than the max allowable number that can be used in a Visual Basic.

Such an error doesn't occur very often. But you will get them occasionally. And if you think about the sheer number of starters in a StarterHistory table... hundreds of thousands...
you'll realize you are almost guaranteed to generate overflow errors because, for a handful of horses in any sizeable database build, the number
resulting from strict application of the single horse scoring formula is simply too big.

Because of that I went looking for a work-around.

I tried using a Base smaller than the Euler number. And while playing around with different sized Bases I discovered that you never want a Base smaller than 1.0 -- mostly because it generates individual horse scores that are worthless as Prob Estimates.

I tried using various Base numbers larger than 1.0 but smaller than 2.71828. And while playing around with those I discovered that while Bases infinitesimally greater than 1.0 allowed me to get through db builds spanning many years without raising an overflow error: The resulting Prob Estimates from single horse scoring left a lot to be desired.

I experimented with incrementally increasing the Base - and discovered that as it approached approximately 1.07 or 1.08 I could get through sizeable db builds -- while genererating prob estimates that were useful at the windows.

And I even created an option to use Bases of that size level on the MLR Quick Start Tool.

But, I still wasn't satisfied.

Side by side comparisons of databases built using a Base of 2.71828 (before the db build routine errored out because of an overlflow error) against the same races from db builds where the Base had been 1.07 to 1.08 clearly showed that prob estimates based on Base = Euler produced better results. (And that should come as no great surprise to anybody.)

I did some poking around on the web and came up a C++ code snippet that an author had used to create a routine that very adeptly handled extremely large numbers. I played with it for a bit and decided to scrap it because implementing a C++ routine in VB6 would be quite an undertaking. But who knows? I may decide to implement it in a future JCapper program update.

In the end I settled on the idea of using a Max Exponent.

• Max Exponent theory goes something like this:

If you know ahead of time the largest allowable number you can use in Visual Basic:

And if you know the formula you are going to use that will (sometimes) generate a number bigger than the largest allowable number in Visual Basic:

Then you can apply a True/False test to the pieces of that formula -- and know in advance when the formula itself is about to generate a number so large that it will break the barrier and raise an overflow error.

And in the rare case when that is about to happen:

All you have to do is change the numbers in the formula so that the formula contains the largest possible numbers that will not cause it to break the max number in Visual Basic barrier and generate an overflow error.

Ok. Let's try that again in something closer to English:

If this is the formula for single horse scoring:

horseScore = 2.71828 ^ ((coeff1 x factorVal1) + (coeff2 x factorVal2) + (coeff3 x factorVal3)... + (coeffN x factorValN))

All you are really doing is saying that single horse score is equal to 2.71828 raised by some number.

If so, you can restate the formula like this:

horseScore = 2.71828 ^ (SomeNumber)

And from there you can use algebra to calculate the max allowable value for (SomeNumber) before it causes the formula to generate a number so large that it breaks the max number in Visual Basic barrier and causes an error.

I won't bore you with the algebra. Instead I'll just tell you that if Euler is your base: The largest whole number you can use for (SomeNumber) in the formula -- or the Max Exponent you can use in the formula is: 709.

So in cases where the formula is about to cause an overflow error:

Internally within JCapper, instead of this:

horseScore = 2.71828 ^ ((coeff1 x factorVal1) + (coeff2 x factorVal2) + (coeff3 x factorVal3)... + (coeffN x factorValN))

The formula is coerced into this:

horseScore = 2.71828 ^ (709)

And it works beautifully.

Ok. Now you know what a Max Exponent is, why you should always use one, why there's a MaxExp field on the MLR Quick Start Tool, why you should ALWAYS let the interface auto populate that field, and why you should never leave that field blank.