Automating Speed Figures

[TravisVOX]

Is there software out there, or a decent technique whether it be long hand, automated etc that will assist me with my figures.

I want to somehow create my figures automatically when a race card comes up. Should I be looking to program this myself? In other words, I don't want to have to calculate each horses figures earned before I handicap the card...I'd like somehow everything to run through some sort of software and it creates it for me.

Is anyone using something along the same lines?

[sjk]

Travis,

You can certainly do this with Access but as other have pointed out, you will have to invest some time in learning how to do it.

Beware. Once you have done this you will probably want to continue down the road of having Access do the handicapping for you and that can require considerable time investment.

[Brian Flewwelling]

Speeds are calculated from the results of races, that is at time of running. They are dependent on the Daily Variant for that race, as well as the time, Track Pars, etc

PP lines report the one line of that race for the horse. So you need have a variant for each race in the PP's

If you are using DRF speeds/Variants they are right there... what's to calc?

Am i missing something?

Brian

[sjk]

Brian,

On another thread Travis was working on his own variants.

[TravisVOX]

...I don't think what I'm after is done through Access. Well, it is, but it isn't.

Basically, I'm making my own customized PP's. I've created the database etc., but I want to display them on screen like Formulator 4.0 does.

I do believe this is a setup they have that call upon an Access Report to be displayed within the software. Confusing stuff indeed.

Does anyone have an idea if this is their approach?

[sjk]

Even though Access may not be what you prefer to use, believe me that it can easily do whatever is necessary.

I can print a report with all of the information on each horse's past races with speed figures, pace figures, etc. I have not bothered to print it for many years since I now let the computer do all of the handicapping.

[Brian Flewwelling]

Originally posted by TravisVOX
...I don't think what I'm after is done through Access. Well, it is, but it isn't.

Basically, I'm making my own customized PP's. I've created the database etc., but I want to display them on screen like Formulator 4.0 does.

I do believe this is a setup they have that call upon an Access Report to be displayed within the software. Confusing stuff indeed.

Does anyone have an idea if this is their approach?

Perhaps you could share more of what you are doing... then we have a chance to make suggestions.

I am guessing: -you have a db of previous race results?? ... from those results you have determined Variants ...

now you import some Entry List, and want to create a "program" using your db of pps... is this even close?

btw if you figure out how to display an Access Report from outside Access, i would be real interested!!

fleww

[TravisVOX]

I have some VB.net experience. I have it on my system...

What i'm interested in doing for starters, to at least get something going that I can expand upon, is to take data files and import them in. I'll do some calculations to those files, such as fps of past race, look up speed figures in my database etc. and display them on the screen in a PP-like format. Much like Formulator does. I want to then print up this data.

There are a few ways I can think of to do it, one is make the data into an HTML page and display it within the program I am writing. But I don't think that's the best route. I then felt that DRF Formulator called upon its database, created a report that are their PP's and displays it in the software...

This I could do if I knew how. I'm just wondering if anyone out there would know, or thinks, that this is a good route. Ultimately, I want to create this supplement PP's that contains all my information along with the standard Bris or DRF.

I hope I've made this somewhat clear....!! Haha, tough to write down thoughts as they race from my mind.

[sjk]

Travis,

I guess you don't like the Access suggestion, but I am at a loss as to which part of this would be difficult to accomplish through Access.

I guess it must be getting the information into Access, although it is easy to import text or spreadsheet formats. The calculation and report display would be extremely easy. What sort of database is you data in now?

[TravisVOX]

sjk...

No I think you're right. I need to do the access reports and have this software display them. The software eventually will have lots of other stuff associated with it that won't go through access. What i'm seeing here is if this is how DRF Formulator presents its PP's. I love the way it can be viewed on screen and trainers can be clicked...only with mine, other stuff will be clicked for different analysis etc.

I hope I'm not confusing people more...it's tough to explain. But when my software loads up, I load a data file and a database is created on que so-to-speak. I want to take that data and create the on-screen display of a PP within the software I am making.

[Valuist]

The best numbers are made thru projections, not pars. I have yet to hear of software that could make accurate projections.

[sjk]

If you program it yourself you can make the variants any way you like. I use 80% projections/20% pars in mine.

[Valuist]

Maybe it is possible. I'm not a programmer.

If the day comes when you have to be a programmer to do well at this game, I'm quitting it.

[TravisVOX]

Well Formulator makes use of a software along the lines of Rogue Wave Software...it's a software that allow the binding of a database to grid components etc. I'm on the right track...could be a long night...

[sjk]

Travis,

Never had any reason to look at Formulator, so I can't offer any help there. Good luck with your program.

[TravisVOX]

Formulator just has the look and feel I am after. That is, displaying the PP's on the screen in the same manner they do. I might have to create flat out HTML files for my PP's...we'll see.

[osophy_junkie]

Access isn't going to give your program a stand alone "application" feel. Access is an application it's self for creating tables, modules, queries and reports. Anything you do in it will be limited to these functions while running Access. Access will always need to be open for your proram to work. For basic database work this is fine, for creating a stand alone program with special gui components it doesn't work to well.

With that said I've never used Access on a large scale, it may be possible to set up hooks for the report elements using the module section. To achieve a stand alone application would require moving to a language like VB or python, both are quite easy for a beginer and have the ability to use access databases.


Ed

[KingChas]

Originally posted by sjk
Travis,

You can certainly do this with Access but as other have pointed out, you will have to invest some time in learning how to do it.

Beware. Once you have done this you will probably want to continue down the road of having Access do the handicapping for you and that can require considerable time investment.

Sjk-please explain the-Beware considerable time investment after you learn how to use it?I'm interseted in Access also .

[Jeff P]

Originally posted by TravisVOX

I have lofty goals...

...I don't think what I'm after is done through Access. Well, it is, but it isn't.

Basically, I'm making my own customized PP's. I've created the database etc., but I want to display them on screen like Formulator 4.0 does.

I do believe this is a setup they have that call upon an Access Report to be displayed within the software. Confusing stuff indeed.

Does anyone have an idea if this is their approach?


Travis,

There are a couple of things to consider before deciding what path you should take with your project. I'd say the answer really depends on what you want to get out of your project.

If you just want to create customized past performances for your own use, and you have all of the data needed for your own past performances already sitting inside an Access table, then creating a set of Access reports is probably the way to go.

If you only have SOME of the data you need sitting inside an Access table, and need to do a little number crunching to create the REST of what you want to see on your report, and plan to add MORE number crunching as time goes on and as you work on new discoveries and concepts, then perhaps the Access report engine is not what you want to use. If this is the case, forget about using Access to create reports right now and move on to using either VB or VB.Net to create HTML reports.

I'll stand by the above statement even though I can already feel and hear the oncoming rumble of objections coming from all the Access users who are bound to be out there.

Sadly, I make the above statement based on my own experience in developing a pretty comprehensive set of Access reports for a project I was contracted out to work on for American Express known as Budget Tools. We were using the Developer's Edition of Access 2000. Deep into the project, my development team and I discovered that the Access report engine has some pretty serious and undocumented limitations when it comes to number crunching using VBA code placed inside of the event procedures of Access Reports. We found that placing VBA code inside of the reports themselves (even though Microsoft insisted that we should have been able to do this) caused some very quirky behavior in the order and number of times that certain event procedures fired as a report loads and executes.

I ended up having to architect a complete work around where all of the values needed for each report were first calculated using a VB Module which temporarily stored the values in a special Reports Table before calling and launching the Access report that our users at American Express expected to see and had to have. The users at American Express never knew it, but the Access reports they see on their desktops to this day are based not on their own Access tables which only contain partial information, but are instead based on information placed into a tempory Access table by a Visual Basic module. I kind of doubt that they really care so long as it works, and works well, which it does.

After spending literally hundreds of actual dev time hours working on this project, I can boil down what I learned about the Access Reports engine to a couple of sentences: Microsoft's Access Reports Engine is designed to be very good at pulling values from Access tables and simply displaying the information found inside the table. Access REPORTS do not respond well to large amounts of VBA code residing inside event procedures. It will tolerate a little number crunching in the report load and other event procedures, provided you don't do "too much." What is "too much?" Unfortunately, that's not anything Microsoft ever documented or is even willing to admit to. Exceed "too much" and you will find the code inside the report with "too much" executing twice when you launch the report this time and four times the next time you launch the same report. At other times, the same code may not even execute at all. This can wreak havoc with even the simplest calculations such as number of days since last race. (In my case for the Amex report it was number of days the asset had been in service.)

Bottom line, unless you already have all of your data sitting neatly in an Access table, I'd STRONGLY recommend using either VB or VB.net to create HTML reports. Both are far more reliable platforms than Access was ever intended to be. And if you take the time to learn some coding techniques, you'll absolutely be amazed at just how much farther you can go with HTML reports than you EVER could with Access.

[sjk]

KingChas,

My remark relates to my own experience. Many years ago I started off using Access to make my own numbers and print a PP type report that I could take to the races (back then you actually had to go to the races and all you could play was the local track).
This starting point sound just like what Travis is trying to do.

After that was done it seemed logical to get the computer to take over more, eventually all, of the handicapping so I headed down the Black Box route. Access is capable of doing this but it was thousands of man-hours later before things were working as hoped for. Once I got going it was hard to stop until I got to the end; hence the considerable time investment.

Travis and Jeff,

As Jeff has explained you cannot expect Access to calculate everything you need at the touch of a button. I use macros although I am sure modules would do the job as well or better.

To create the report I run a macro which uses many dozens (or hundreds, I haven't counted) of tables and queries to create the data table driving the report. It is not a big deal to run; it takes only 5-10 minutes for a dozen tracks. I run it in the morning after getting the entries for the tracks I plan to play.

The only way you will get Access to do anything complicated is to break it up into pieces.

[cj]

I would highly recommend learning a high level programming language. Once you do, they are much more powerful to work with than a database. Use the database to store info, but use the a self-written program to manipulate it and format the output.

JMHO...

[TravisVOX]

Thanks everyone for the well-thought responses.

I think the best route is to certainly work with HTML report-output. I have plenty of HTML experience so I can, for now, generate such an output to bring with me to the races.

I'll be working on this today and throughout the rest of the summer, hopefully I can show some people a few screenshots of where I'm going with this...excited about it...

[Jeff P]

Originally posted by sjk-

To create the report I run a macro which uses many dozens (or hundreds, I haven't counted) of tables and queries to create the data table driving the report. It is not a big deal to run; it takes only 5-10 minutes for a dozen tracks. I run it in the morning after getting the entries for the tracks I plan to play.

sjk,

There's a topic in programming called Recursion. Basically, Recursion exists as it applies to speed of program execution whenever you place code or logic to get information into or out of a database inside a loop- any kind of loop. There's a hidden trap that's easy to fall into. The trap is placing two or more blocks of code or logic to get information from a database inside of a nested loop.

Example: You are using two tables and have created two separate code blocks, Code Block A for the first table and Code Block B for the second table (and this can apply to Access Queries as well) to retrieve the needed information from the database. You unknowingly place Code Block B inside of the logic driving Code Block A.

What happens? Well, they way that Microsoft products, Excel, Access, VB, and VB.Net all use available memory to perform something called data look up causes all of them literally to choke themselves nearly to the point of stopping completely. The result, so far as what you see when your program with the recursive recordsets actually runs, is that the program runs VERY VERY SLOWLY.

I mention this because you posted that your report takes only 5-10 minutes to run a dozen tracks. I would bet from what you posted that your report is being victimized by Recursion. I would venture that if you took the time to isolate the recursive code blocks and restructure them so that they are no longer recursive you could run the same report for a dozen tracks and see that it would take no more than a few seconds from start to finish.

[sjk]

Jeff P,

Thanks for your well intentioned advice. I am sure there is no recursion in my program. Queries using multiple large tables take time. My race database has upwards of 300,000 entries and my line database has 2,600,000 entires. As my daily macro runs, any number of other large tables are created and used as part of the calculations.


There may be alternate ways to do some calculations that would shave some seconds off of the time, but I am sure that some of the queries just take time based on the number-crunching involved.

You would probably be horrified at the time my weekly variant recaculation macros take. I have to break it into two macros and compact the database in between to keep it from going over 2GB. Each of the two takes about 45 minutes.

Whe your tables are big enough it is pretty easy to design a query that will not be completed in any reasonable amount of time. There some calculations that I did years ago that I would not attempt again because with the amount of data now in the tables involved, they would take too long and I don't think the results would materially change.

[sjk]

Jeff P,

Not to belabor the point, but I thought I would give you an example of a calculation where the queries would take a considerable time to run.

Say you have a reasonably large dataset of running lines (say a million or more). You want to look at all of the horses which run once and then again within 90 days. You want to calculate and compare the speed figure of the horse in the second race with his speed figure in his first race. Then you look at how the differences are distributed. (Slightly more interesting is when you compare the speed figure in the second race with a speed figure projection which incorporates the speed figure from the first race along with other elements.)

It is a pretty straightforward deal to calculate but I bet it will take you some time to get to the answer.

[Jeff P]

sjk,

I do something similar. But instead of pulling the information needed for number crunching and reports out of a table, I read it directly from the Bris data file itself using code contained in a VB EXE. Very early on I found this to be far faster than writing the information from the Bris file to a table and then turning around and reading the same info back out of the table. There is a certain limited amount of information that I do take from the Bris files and permanently store in tables, most notably race results, and indicators of track biases for a given day. But so far as speed and pace numbers and finish positions and beaten lengths and the like are concerened; I have my software make its own unique numbers based on these; and since they already exist in the Bris files that I am buying, I thought- why not just read what I need directly out of the Bris file instead of a table?

By the way, I've spent literally thousands of hours over the better part of the last two decades working on my pet project. It is something that is ever evolving, and I am always amazed at what my software DOESN'T DO whenever a new idea or way of looking at the races comes my way. But I am happy to report, without trying to sound too pompous, that I can get all of the information needed for my reports, which as I'm sure you know can be considerable, for seven or eight cards a day, in about 30 seconds.

Good luck and continued success with your own project and keep at it.

[sjk]

Jeff P,

I don't buy information from Bris (or anyone else) so all of my data is home-made. I guess that's why the amount of time it takes is different, although the 5-10 minutes of processing time is no burden at all.

Good luck and continued success to you.

[TravisVOX]

When I program my software, I often times will take my data source and first read the file through a different software to extract just the information I need, then boost it into the massive chunk of information I already have. Helps a lot. Good topical information going back and forth here.