A couple of months ago, I talked to Dave and came to realize that while I have the components, my process sucked (my words, not Dave's). I use my own software, so I better organzied the software and established a process. My results improved.

Since then, I have found some even better components. Unfortunately, I didn't stop and establish how to incorporate this new knowledge into the process. Dave has convinced me that the process is extremely important.

In reading through this very interesting thread, I have come to a course of action. I am going to journal my process and step through each race and then post mortem the race to see what worked and what failed. This idea was sparked by what Jack had to say. I'm mid-pack in the contest... with a little better luck this weekend (4 seconds, 1 third, 1 fourth) I would be higher, but still nowhere near Jack's level.

One thing that I tend to do right is to learn. i look forward to a lot more of that.

Respectfully, I am not currently ready to provide those.

Maybe one of my best discoveries has been that you learn a lot more from a horse's good races than you do from the poor races. And competitive races are even better.

I have homegrown software. A lot of my best ideas have come from reading forums and either using posted ideas directly or with a few modifications. I've "stolen" a lot of ideas and I've been surprised by how many pan out to be reasonably good considering that so much chat is pretty mindless on some boards.

I'd have to say that the most elusive factor for the longest time for me was class and class/ability. It's amazing how many really good horses go off at 5/1 and better.

I just had another thought. Organize your calculations between what needs to be re-calculated for scratches and what doesn't.

Let's say you have 10 sections to your handicapping program. And, you use Strength in 6 of those sections. At the top of your program, you can store the Strength value. As you go in and out and in each of the 6 sections where Strength is displayed, you can access it as an already computed value, which is faster than recomputing it every time. And, obviously you are only computing it one time, which means you are only computing it one way... which is clearly way better than the way a beginner might do it, computing in each of the 6 sections, possibly resulting in 6 different ways of calculating the value. Obviously there needs to be a function to calculate Strength.

Yes, you can have more than one value. My last example there holds the values in an array, but you could pass in multiple parameters. That might get a bit tricky if you're not always passing all of the parameters in and out.

Now that you understand that, you could pass in two values. One is the lookup and the other is the change value (or no value). You could then have a do case structure to lookup the value.

do case
case cY == "TURN TIME"
xReturn := aMyStaticValues[hManifest_Constant_For_TURN_TIME]
case cY == "%MEDIAN"
xReturn := aMyStaticValues[hManifest_Constant_For_%MEDIAN]
end case

Yes

function MySortaGlobal( xValue )
static xKeep

if xValue == NIL
else
xKeep := xValue
endif

return xKeep — RanchWest

When a value is passed, it is stored in xKeep and xKeep is returned. When no value is passed, the function returns what is stored in xKeep.

If a value is passed in, that SETS the stored value. If no value is passed in, that GETS (fetches) the stored value. In my example, I denoted no passed value as being NIL, but the exact coding would depend on the language.

If your language supports static variables, then those are persistent, but not globally. So, if a function is holding that static value, then the value can be accessed as in the function I showed above. It is available globally, but is not a global variable. As you likely know, global variables are a no no.

Yes, but I'll give you an example. I know you calculate a strength number where you look at the speed figures for all of the lines of all of the horses in a race. If you store that number, then when you need it again you don't have to do that calculation again. You still have about the same amount of code, but the execution time is less.
t

function MySortaGlobal( xValue )
static xKeep

if xValue == NIL
else
xKeep := xValue
endif

return xKeep

It might be written a little differently in different languages. If you don't pass in a value, then the stored value is returned. If you do pass a value, then that value is stored. Obviously, this could be made more complex, storing multiple values etc.

A variable or an instance variable. The emphasis is on not doing calculations over and over, especially calculations that are complex enough to take up time. The variable can be static within a function and accessible through a call to the function. It's the workaround to avoid global variables.

My point about OOP is that it provides a way of holding values and accessing them without recalculation. Of course, that can be done with static variables inside a function. And there are various ways of pushing, popping or accessing those stored values. The key is to not recalculate every time you need the value and I admit to being bad about doing that. But, I have been good about sharing the code that is the basic framework for many of my calculations.

The truth about 100% OOP is that it relies on perfect design and even then can become nearly impossible to maintain, especially if the basic requirements change. That doesn't mean that objects are not useful.

,

Many things in life are humbling. Like Saratoga, lol (unless you're Jack). Or, look on my FB page at the display at the leather show. I do good leatherwork, but some of that stuff is ridiculously good... and humbling.

I don't know if you've done any object-oriented programming, but one thing that is nice is being able to store data in an object and access it. Makes it easier to make a calculation one time and be done with it, just access the calculated value.

One thing that strikes me is that 30 years ago speed was a huge factor. I actually did some screens in assembly language because otherwise you could actually see the screen paint and that gave me grief. Today, computers are so fast that it is better to write clean code than to worry about things like variable name length and such. But, it is still sometimes important to do things one time and not keep going back and doing it over and over.

I put comments in when I feel they are really needed, but to be honest that is often because my function names, variable names and array elements are not expressed in a self-documenting fashion.... I guess you could say mostly from laziness or rushing. I get on a roll with a new concept and I focus too much on completion and not enough on keeping things tidy. It usually leads to regret, especially when it comes to array elements.

But I do feel that complex computations do sometimes need comments to explain the objective. Or, for example, I am dealing with yards... it is nice to comment the furlongs, though those, too, could be expressed as manifest constants.

A quick tip...

Try to keep coding on the positive.

Saying .NOT. or ! or however you language says not is usually not the clearest way to write code.

Instead of

If .NOT. eof()
// do something
endif

write

if eof()
else
// do something
endif

I think you'll come to appreciate the clarity.