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
Alan Browne 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.
> 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.
> 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.
>>> 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 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.
>> 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.
> 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.
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.
>>>> 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 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.
>>> 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.
>> 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. ;-)
> 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!
>
/BAH
jmfbahciv wrote:
> 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.
>>>> 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!
>>
>> 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. ;-)
The same was true of a few tape readers <grin>.
> /BAH
J. Clarke wrote:
> jmfbahciv wrote:
>> 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!
>>>> 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. ;-)
>
> The same was true of a few tape readers <grin>.
> The same was true of a few tape readers <grin>.
ROTFL. Some. The readers I used rarely ate tape as long
as you didn't obstruct the flow of tape on the other side
of the reader.
I never worked with Mylar tape. We dup'ed papertape
for our distribution media. It might have been nice
to have shipped diags on Mylar (paper)tape; I might
not be as deaf as I am now from dup'ping paper tapes
on the Burpee punch.
/BAH
>