Thanks for the help. The solution offered by Byron last year worked! I am
running version 2.6, so I guess they didn't get around to fixing it.
From: Dick Rasmussen [mailto:firstname.lastname@example.org]
Sent: Wednesday, August 01, 2001 6:41 PM
To: Tremmel Matthew; 'email@example.com'
Subject: Re: FW: Floating Point Exception
At 04:37 PM 8/1/01 -0400, Tremmel Matthew wrote:
>I tried sending this right to Byron, but I haven't heard anything...
Here is one possible solution (i.e. this was the cure for the floating
point problem I had). This is copied from a message Byron sent 5/22/00.
A few users have reported a pesky floating point error that
shows up mostly when they go to adjust a map, but sometimes
is so persistent that the software refuses to load some runs
at all. Worst of all, the error was completely
uncooperative about showing it's face on our machines here
in Phoenix. No matter how we tried, we couldn't duplicate
After several months of hunting and fishing, two users on
opposite coasts provided the information that when put
together made everything come into focus. JJ Coulter (right
coast) and Dick Rasmussen (left coast) both reported the
error, and tirelessly followed all kinds of suggestions from
me until quite by accident, but to no avail. By a stroke of
luck, the error showed itself when Dick tried to follow JJ's
directions, and got them wrong. (Isn't it amazing the good
stuff we discover by accident?)
Here's the deal. If you go to Setup|Program Options|Data
you'll find two checkboxes at the bottom of the screen,
dealing with adjusted or unadjusted values. The first is
"Display Raw Unadjusted Data". This checkbox by default is
There's very little reason to uncheck this checkbox, and I
haven't done it in, well, quite some time, since about
version 2.50 apparently. It turns out, that with that
checkbox unchecked, we certain adjustments can create a
divide by zero error which is then displayed as "invalid
floating point operation" by Windows, causing a program
crash and lots of other unpleasantries.
The fix, for now, is extremely simple: Be sure that Display
Raw Unadjusted Data is CHECKED. You can have it's
companion, the checkbox marked "Display Raw Unadjusted
Ratings" either checked or unchecked as you wish. This is a
feature I use often, and just wrote about in NAP regarding
Todd Green, for instance. But the other one, the one about
DATA, should always be checked.
We will kill this bug quickly and the fix will appear in the
new version we are working on right now. BTW, that version
is the multi-lap, unlimited recording time version, and we
hope to have it out very soon.
>I am having a intermittent problem with the GEEZ software (Windows NT4.0,
>using the old dongle, with patches). If I download a run from the Palm,
>then process it, everything is fine. I then save the run, along with all
>adjustments and notes. When I go to re-load it, I get a 'Floating Point
>Exception' error, and while the run comes up, most of the stats are 0.00,
>and I can't adjust anything without getting the same error. It does not do
>this on all runs, just some.
>Also, the printout (hardcopy) stats of peak left, right, accel, and brake
>don't match the Statistics panel. Some of the numbers printed out are the
>sustained peaks, except the accel value is the absolute peak. Here is the
> Absolute Sustained
>Peak Left G's 1.26 1.22
>Peak Right G's 1.23 1.12
>Peak Accel G's 0.67 0.63
>Peak Brake G's 1.17 0.89
>Peak Left 1.22
>Peak Right 1.12
>Peak Accel 0.67
>Peak Brake 0.89
>The printout should at least be more clear about which it is printing out
>(sustained, or peak), and they should be consistent with the Stats panel.
>have 'Display Raw Unadjusted Data' and 'Display Raw Unadjusted Ratings'
>Thanks for any help,
85 Van Diemen RF-85 Formula Ford
/// firstname.lastname@example.org mailing list