Bookmark this page:
- GPS-Control-Software-Update-Shows-Glitch
- 01-23-2010
If you were Registered and logged in, you could reply and use other advanced thread options
On Tue, 26 Jan 2010 16:34:08 -0500, matt weber
If I had a dollar for every time I wrote
IF ABS(A-B)<0.001 . . .
I'd have a few dollars, hahahaha!
matt weber wrote:
>
>> Happy Trails wrote:
>>>> Only a couple of days!? [awed emoticon here]
>>> Yes - I did mention that I knew what I was looking for based on the
>>> actuary's statement, did I not?
>>> Yes - I did mention that I knew what I was looking for based on the
>>> actuary's statement, did I not?
>> Sure. However, reproducing a hypothesis is not trivial. Doing
>> it without knowing the machine language is almost dipping into
>> the lottery numbers and finding the ball that says "tilt". :-)
>> it without knowing the machine language is almost dipping into
>> the lottery numbers and finding the ball that says "tilt". :-)
>>>> There have been a few bugs of this flavor on many systems in the
>>>> past. I vaguely recall one where the work around was to
>>>> split up the calculation statement. I don't remember the platform
>>>> nor the language nor the decade when it happened.
>>> That worked on this one. Splitting it up meant that a temporary result
>>> in a register got stored as permanent before the "requires more than 4
>>> FP registers" limit was hit.
>>>> past. I vaguely recall one where the work around was to
>>>> split up the calculation statement. I don't remember the platform
>>>> nor the language nor the decade when it happened.
>>> That worked on this one. Splitting it up meant that a temporary result
>>> in a register got stored as permanent before the "requires more than 4
>>> FP registers" limit was hit.
>> Yep.
>>> I remember the extra-slick IBM salesman at the time pointing out the
>>> place in the programmer's manual where it stated you were to avoid
>>> using mixed-mode arithmetic (mixing FP and integer operands in the
>>> same expression), so I rewrote it using all FP terms, and it still
>>> screwed up, as I knew it would, hahaha. I don't know why that warning
>>> was there - it handled the conversion between integer, single
>>> precision FP and double precision FP perfectly okay, both coming and
>>> going.
>>> place in the programmer's manual where it stated you were to avoid
>>> using mixed-mode arithmetic (mixing FP and integer operands in the
>>> same expression), so I rewrote it using all FP terms, and it still
>>> screwed up, as I knew it would, hahaha. I don't know why that warning
>>> was there - it handled the conversion between integer, single
>>> precision FP and double precision FP perfectly okay, both coming and
>>> going.
>> Did it really? Those warnings were put there usually because
>> floating point and integer arithmetic don't mix. It was a
>> sanity check done in the olden days. IIRC, FORTRAN II
>> didn't allow mixed mode arithmetic statements.
>> I vaguely recall a bug we had where the floating point number
>> was moved ot the register, except truncation occurred. Must
>> have had something to do with double-wordiness of floating
>> point numbers.
>> /BAH
>> floating point and integer arithmetic don't mix. It was a
>> sanity check done in the olden days. IIRC, FORTRAN II
>> didn't allow mixed mode arithmetic statements.
>> I vaguely recall a bug we had where the floating point number
>> was moved ot the register, except truncation occurred. Must
>> have had something to do with double-wordiness of floating
>> point numbers.
>> /BAH
> A fairly common problem actually. On many system the floating point
> exponent register was seperate hardware from the regular arithmetic
> accumulator. The result was intermediate results that were in a
> register were often 'full double word'. However when they were stored,
> the number of bits required for exponent bits would have to be either
> rounded, or truncated off the bottom end of the register (sometimes at
> the users option. I worked on a couple of machines that had both a
> float point store, and floating point store rounded instructions
>
>
> However my favorite was the discovery that on one machine I worked on
> A * 1.0D0 did not equal A!! (and A was declared as double precision).
>
> Another place you can get burned is if the compiler and the format
> interpreter don't process numbers the same way.
> i.e. on is a constant generated at compile/assembly time, and the
> other was read in from somewhere (card reader, tape, disc file etc).
>
> I had one customer who wanted us to implent a instruction for 'compare
> nearly equal'...
> exponent register was seperate hardware from the regular arithmetic
> accumulator. The result was intermediate results that were in a
> register were often 'full double word'. However when they were stored,
> the number of bits required for exponent bits would have to be either
> rounded, or truncated off the bottom end of the register (sometimes at
> the users option. I worked on a couple of machines that had both a
> float point store, and floating point store rounded instructions
>
>
> However my favorite was the discovery that on one machine I worked on
> A * 1.0D0 did not equal A!! (and A was declared as double precision).
>
> Another place you can get burned is if the compiler and the format
> interpreter don't process numbers the same way.
> i.e. on is a constant generated at compile/assembly time, and the
> other was read in from somewhere (card reader, tape, disc file etc).
>
> I had one customer who wanted us to implent a instruction for 'compare
> nearly equal'...
ROTFLMAO. I've never heard that one. That's a really good one.
Consistency was always preferred than accuracy.
/BAH
>Sure. However, reproducing a hypothesis is not trivial. Doing
>it without knowing the machine language is almost dipping into
>the lottery numbers and finding the ball that says "tilt". :-)
>it without knowing the machine language is almost dipping into
>the lottery numbers and finding the ball that says "tilt". :-)
The process was not quite that random.
I said didn't know "Assembler" programming, but I was capable of
decoding machine instructions using the Principle of Ops as a guide -
a lot more so after this exercise than before, hahaha.
I also had compilers (IBM DOS & OS FORTRAN IV) that optionally output
a listing of line numbers along with code generated for each
statement. Made it easy to find where you were in the machine code.
There was also a listing of machine addresses for variables, so you
could do a divide by zero or some such just before and after the
statement in question, and get a dump of what was in the variables
under examination.
Still took 2 days - would've taken 2 minutes with QBX IDE 25 years
later!
============
>>. . . it handled the conversion between integer, single
>> precision FP and double precision FP perfectly okay, both coming and
>> going.
>> precision FP and double precision FP perfectly okay, both coming and
>> going.
>Did it really?
Yes, as a matter of fact, it did.
Happy Trails wrote:
>
>> Sure. However, reproducing a hypothesis is not trivial. Doing
>> it without knowing the machine language is almost dipping into
>> the lottery numbers and finding the ball that says "tilt". :-)
>> it without knowing the machine language is almost dipping into
>> the lottery numbers and finding the ball that says "tilt". :-)
>
> The process was not quite that random.
>
> I said didn't know "Assembler" programming, but I was capable of
> decoding machine instructions using the Principle of Ops as a guide -
> a lot more so after this exercise than before, hahaha.
>
> I also had compilers (IBM DOS & OS FORTRAN IV) that optionally output
> a listing of line numbers along with code generated for each
> statement. Made it easy to find where you were in the machine code.
> The process was not quite that random.
>
> I said didn't know "Assembler" programming, but I was capable of
> decoding machine instructions using the Principle of Ops as a guide -
> a lot more so after this exercise than before, hahaha.
>
> I also had compilers (IBM DOS & OS FORTRAN IV) that optionally output
> a listing of line numbers along with code generated for each
> statement. Made it easy to find where you were in the machine code.
That is still a lot of work. Hence, my admiration for finding it
in days.
>
> There was also a listing of machine addresses for variables, so you
> could do a divide by zero or some such just before and after the
> statement in question, and get a dump of what was in the variables
> under examination.
>
> Still took 2 days - would've taken 2 minutes with QBX IDE 25 years
> later!
> There was also a listing of machine addresses for variables, so you
> could do a divide by zero or some such just before and after the
> statement in question, and get a dump of what was in the variables
> under examination.
>
> Still took 2 days - would've taken 2 minutes with QBX IDE 25 years
> later!
If you had our tools, it may have taken a similar amount of time
back then :-).
<snip>
/BAH
On 10-01-25 8:43 , jmfbahciv wrote:
> There have been a few bugs of this flavor on many systems in the
> past. I vaguely recall one where the work around was to
> split up the calculation statement. I don't remember the platform
> nor the language nor the decade when it happened.
> past. I vaguely recall one where the work around was to
> split up the calculation statement. I don't remember the platform
> nor the language nor the decade when it happened.
That's pretty common debugging in any day and age.
I'd do the same assuming I'd made a mistake in a statement. Once
working correctly, I'd leave well enough alone and move on.
Deadlines.
The other joy was moving FORTRAN from one platform to another and then
validating the code on the new platform ... tedious at best.
>nearly equal'...