Happy Trails wrote:
On Mon, 25 Jan 2010 08:43:54 -0500, jmfbahciv jmfbahciv@aol 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?

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". :-)


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.

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.

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

Alan Browne wrote:
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.

That's pretty common debugging in any day and age.

This is the first I've heard of the technique in a long time. However,
I live in a rarified atmosphere where this kind of stuff is SOP.

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.

Unless the platforms' arithmetic are not consistent. Those are
really [NOT] "fun"....unless you have a really nice data set.
Then it could be fun.

/BAH

On 10-01-26 9:03 , jmfbahciv wrote:
Alan Browne wrote:
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.

That's pretty common debugging in any day and age.

This is the first I've heard of the technique in a long time. However,
I live in a rarified atmosphere where this kind of stuff is SOP.

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.

Unless the platforms' arithmetic are not consistent. Those are
really [NOT] "fun"....unless you have a really nice data set.
Then it could be fun.

Usually we had data that we could test with, this (in one case) included
a huge roll of punched paper tape. Fortunately I didn't do that one!

--
gmail originated posts are filtered due to spam.

On Tue, 26 Jan 2010 09:00:29 -0500, jmfbahciv jmfbahciv@aol wrote:

Happy Trails wrote:
On Mon, 25 Jan 2010 08:43:54 -0500, jmfbahciv jmfbahciv@aol 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?

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". :-)


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.

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.

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
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'...

In article , matt weber wrote:
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).

That brings to mind the infamous Pentium FDIV bug:
http://en.wikipedia.org/wiki/FDIV_Bug

--
TJH

tjhiggin.at.hiwaay.dot.net

On Tue, 26 Jan 2010 16:34:08 -0500, matt weber
wrote:

On Tue, 26 Jan 2010 09:00:29 -0500, jmfbahciv jmfbahciv@aol wrote:

I had one customer who wanted us to implent a instruction for 'compare
nearly equal'...

If I had a dollar for every time I wrote

IF ABS(A-B)0.001 . . .

I'd have a few dollars, hahahaha!

On Tue, 26 Jan 2010 09:00:29 -0500, jmfbahciv jmfbahciv@aol 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". :-)

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.

Did it really?

Yes, as a matter of fact, it did.

Alan Browne wrote:
On 10-01-26 9:03 , jmfbahciv wrote:
Alan Browne wrote:
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.

That's pretty common debugging in any day and age.

This is the first I've heard of the technique in a long time. However,
I live in a rarified atmosphere where this kind of stuff is SOP.

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.

Unless the platforms' arithmetic are not consistent. Those are
really [NOT] "fun"....unless you have a really nice data set.
Then it could be fun.

Usually we had data that we could test with, this (in one case) included
a huge roll of punched paper tape. Fortunately I didn't do that one!

I did not like handling paper tape, oiled nor fanfold. ;-)

/BAH

matt weber wrote:
On Tue, 26 Jan 2010 09:00:29 -0500, jmfbahciv jmfbahciv@aol wrote:

Happy Trails wrote:
On Mon, 25 Jan 2010 08:43:54 -0500, jmfbahciv jmfbahciv@aol 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?
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". :-)

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.
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.
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
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'...

ROTFLMAO. I've never heard that one. That's a really good one.
Consistency was always preferred than accuracy.

/BAH

Happy Trails wrote:
On Tue, 26 Jan 2010 09:00:29 -0500, jmfbahciv jmfbahciv@aol 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". :-)

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!

If you had our tools, it may have taken a similar amount of time
back then :-).


snip

/BAH