Prev: Intel fortran (em64t) very low-accuracy results on x86_64
Next: Problem with ALLOCATABLE scalar
From: frank on 14 Jan 2010 18:53
Colin Watters wrote:
> "frank" <frank(a)example.invalid> wrote in message
> news:7r2fq5F1gmU1(a)mid.individual.net...
>> Richard Maine wrote:
>>> ralf.schaa <ralf.schaa(a)gmail.com> wrote:
>>>
>>>> is there a typo in the listing of the example on page 88 in the second
>>>> line of "program main" ?
>>> ...
>>>> use iso_fortran_env, only :: output_unit
>>> Yes. The double colon should be just a single one.
>>>
>> That could be a crushing error for me, if I had to rely on its
>> correctness.
>
> ...really? Why?
>
>
Because you never suspect that the textbook you're using is in error on
its source listings. This one appears not to have seen a compiler.
--
frank
From: Colin Watters on 21 Jan 2010 15:43

"frank" <frank(a)example.invalid> wrote in message
news:7r9p4gFq80U1(a)mid.individual.net...
> Colin Watters wrote:
>> "frank" <frank(a)example.invalid> wrote in message
>> news:7r2fq5F1gmU1(a)mid.individual.net...
>>> Richard Maine wrote:
>>>> ralf.schaa <ralf.schaa(a)gmail.com> wrote:
>>>>
>>>>> is there a typo in the listing of the example on page 88 in the
>>>>> second
>>>>> line of "program main" ?
>>>> ...
>>>>> use iso_fortran_env, only :: output_unit
>>>> Yes. The double colon should be just a single one.
>>>>
>>> That could be a crushing error for me, if I had to rely on its
>>> correctness.
>>
>> ...really? Why?
>>
>>
> Because you never suspect that the textbook you're using is in error on
> its source listings. This one appears not to have seen a compiler.
> --
> frank

Have you ever tried feeding a text book to a compiler? Have you ever even
tried writing technical documentation, in particular, anything to do with
how to write programs? The tone of your post makes me think not.

ALL technical writing is subject to errors. Usually the number of those
errors sems to be inversely proportional to the number of copies sold,
probably because of the number of proof readers that early buyers turn out
to be. In a specalist volume such as this, with a subject matter so close
to the bleeding edge of technology, you really HAVE to expect errors. That
the authors are taking such error reports so seriously and in such good
grace is to be applauded.

Writing texts about programming is particularly frustrating because the
examples may well have been thrown at a compiler, but between that test and
the final type-setting munge there are a myrad of ways that changes can
creep in. The examples also tend to be code fragments that won't compile
without a lot of additional wrapping, and removing this for insertion into
the text is another source of problems. And finally let us not forget that
this book describes a language dialect for which there WERE NO COMPILERS,
at the time it was being written.


--
Qolin

Email: my qname at domain dot com
Domain: qomputing


From: Richard Maine on 22 Jan 2010 00:05
Colin Watters <boss(a)qomputing.com> wrote:

> this book describes a language dialect for which there WERE NO COMPILERS,
> at the time it was being written.

Still aren't, at least not in any machines that I'm aware of any of the
authors having handy access to.

I just checked in my garage; no Crays seem to have been delivered yet
today. I suppose it would improve the odds if I had ordered one. :-) I
don't think any of the other authors have handy current access to one
either, though I suppose I could be wrong on that.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: frank on 22 Jan 2010 14:23
Colin Watters wrote:
> "frank" <frank(a)example.invalid> wrote in message
> news:7r9p4gFq80U1(a)mid.individual.net...

>> Because you never suspect that the textbook you're using is in error on
>> its source listings. This one appears not to have seen a compiler.
>> --
>> frank
>
> Have you ever tried feeding a text book to a compiler? Have you ever even
> tried writing technical documentation, in particular, anything to do with
> how to write programs? The tone of your post makes me think not.
>
> ALL technical writing is subject to errors. Usually the number of those
> errors sems to be inversely proportional to the number of copies sold,
> probably because of the number of proof readers that early buyers turn out
> to be. In a specalist volume such as this, with a subject matter so close
> to the bleeding edge of technology, you really HAVE to expect errors. That
> the authors are taking such error reports so seriously and in such good
> grace is to be applauded.
>
> Writing texts about programming is particularly frustrating because the
> examples may well have been thrown at a compiler, but between that test and
> the final type-setting munge there are a myrad of ways that changes can
> creep in. The examples also tend to be code fragments that won't compile
> without a lot of additional wrapping, and removing this for insertion into
> the text is another source of problems. And finally let us not forget that
> this book describes a language dialect for which there WERE NO COMPILERS,
> at the time it was being written.
>
>

Colin, you appear to have different expectations than I do. Out of
curiosity, did you buy the book?

Right now, I'm working out of C Unleashed, which is littered with
errors. They however have a companion disc with super-useful stuff.
I've been unearthing errors in this book for years. The latest one was
when Jack Klein switched the roles of the data and the parity bits in a
Hamming code.

It doesn't give itself to be a definitive text.

> That the authors are taking such error reports so seriously and
> in such good grace is to be applauded.

Oh my heck. Number one, writing one token instead of another is not a
minor typo. Number two, do you honestly expect me to clap when someone
else needs to fix their mistakes in a textbook? Number three, I've not
seen a compendium of such applause-worthy mistakes.
--
frank
First  |  Prev  | 
Pages: 1 2
Prev: Intel fortran (em64t) very low-accuracy results on x86_64
Next: Problem with ALLOCATABLE scalar