PDA

View Full Version : General Programming


HRH
09-14-2001, 12:37 PM
I'm interested in programming my own method. The only programming I have done was in the mid-90's and that was using Basic and writing formulas from Tom Brohamer's 'Modern Pace Handicapping'. I've also written more complex programs in Basic for the financial markets. However I always used my own inputs. My goal is to be able to download past performance data for an upcoming race and have 'my program' do the numerical analysis that I want done. A couple of questions that I have regarding this is:
1. What programming language to use(the easier the better)
2. Accesing data provider files. Easy, difficult?
I could write my own basic thing again and input manually but that's not the way I'd like it done.
Thanks.

PaceGuy
09-14-2001, 03:33 PM
Use what you know...

If you can make your way around using basic, you're halfway there already. The first set of programs that I wrote to analyze horses were written in Microsoft Quick Basic. (That should tell you how long I've been into this. My current stuff is written in VB6.0)

You won't need to do manual inputs at all. Data files from BRIS and others are nothing more than comma delimited sequential text files. You can write a module that reads the file itself and assigns the fields you want from the data provider file into your own variables. This is very easy to do. File formats are available for free on the BRIS website. For example, in the BRIS DRF Single File format, there are 1435 fields per horse.


Here's a quick code sample that shows how to read all of the data fields for a single horse.

dim myField(1435)

open myFile for input as #1

do while not eof(1)

for j=1 to 1435
input myField(j)
next j

loop

close #1


If you were to display myField(45) you would see the name of the horse. Download a free sample file from BRIS and play around with this a little.

Of course, you will need some further code in order to break program logic at the end of each race and to do number crunching for your own formulas, but reading the data file itself (and thus avoiding manual input) is not hard at all.

HRH
09-14-2001, 08:54 PM
PaceGuy. That sounds not very difficult. The VB you are referring to I take it is Visual Basic. The reason I asked was that I'd like to make my own speed and perhaps pace figures. I'm not too convinced that the Beyer figs are the best.
Regards,
HRH

PaceGuy
09-14-2001, 10:57 PM
That's right, the VB that I refer to is Visual Basic 6.0. But, and I want to stress this, if you already have a version of basic that you are pretty familiar with, it should work just fine for this purpose.

You describe wanting to create your own figures. This should be no problem. Every piece of information that you see in the form, with the exception of the Beyer, is contained in the BRIS DRF Single Format datafile. These cost $1.00 per card. If you can see it in this file, you can access it programmatically- meaning that you can use it to create your own figures. I would recommend going to the BRIS site (brisnet.com) and looking at the file format for this and other types of files. Chances are that you can find a file containing the information that you need to construct your own figures.


The overall smoothness and success of a project like this is very much dependent upon breaking it up into little pieces. I would sit down and plan out the basic program architecture first before doing any real coding. Use a different procedure for each general task and you should be fine.

In my original set of programs, written in QuickBasic, I had several different procedures. One procedure opened the BRIS datafile and read the BRIS information into my own variables, another procedure crunched the data that had been read in and produced my own numbers, another procedure displayed a worksheet for each race on my screen, another printed out a worksheet for each race on paper, and yet another procedure imported and merged the BRIS results file and then wrote fields into my own data file for later study.

When I upgraded to Visual Basic 6.0, I kept the same procedure based architecture. The whole process will be the same, and the code will probably be very similiar, no matter what version of basic you use.

The point I'm trying to make is that what you are describing IS very doable if you have a little programming skill and if you are willing to invest the time.

thoroughbred
09-15-2001, 01:25 PM
Originally posted by HRH
I'm interested in programming my own method. The only programming I have done was in the mid-90's and that was using Basic and writing formulas from Tom Brohamer's 'Modern Pace Handicapping'. I've also written more complex programs in Basic for the financial markets. However I always used my own inputs. My goal is to be able to download past performance data for an upcoming race and have 'my program' do the numerical analysis that I want done. A couple of questions that I have regarding this is:
1. What programming language to use(the easier the better)
2. Accesing data provider files. Easy, difficult?
I could write my own basic thing again and input manually but that's not the way I'd like it done.
Thanks.

The original version of CompuTrak was written in BASIC and required inputing DRF data by hand.

The latest version still uses BASIC, (a proven, very useful language by the way), but now uses the BRIS DRF file as the input, which makes all data entry automatic.

I found the programming to effect this connection to the BRIS DRF very straight forward after I "got the hang of it."

You will find that once you get the input from the BRIS file to take hold, it is very easy from that point on.

In conclusion. If you have a program in BASIC, or if you can program in BASIC, making a connection to a file like BRIS' DRF file will automatically feed your input requirements.

hurrikane
09-17-2001, 01:48 PM
Try
www.planetsourcecode.com

you can find all kinds of code snippets to do most anything you want. If you are using basic search in VB..they are very similar in functionality...I use this place all the time to prevent from reinventing the wheel.