Re: Numbers and truth values
- From: aleax@xxxxxxx (Alex Martelli)
- Date: Sun, 29 Apr 2007 17:18:17 -0700
Beliavsky <beliavsky@xxxxxxx> wrote:
...
If this has changed in the Fortran 1990 standard or later, then I can
only say I'm happy I stopped using Fortran heavily before such standards
became widespread in commonly available compilers -- by the late '90s,
when I was still using _some_Fortran, it was Fortran '77, as that was
the version that was widely available and well optimized.
I don't think the official status of such has changed -- it's still
illegal to change a constant and the compiler is still not required to
catch the error
Oh good -- I'm happy to hear that the original spirit IS still around.
-- but compilers may be more likely to reject
such code as before, helping programmers spot errors. IMO that's a
good thing.
In general, as an engineer, I think that making tools more complicated
so that a single tool can serve multiple purposes is not necessarily a
win. I do not want one pair of shoes that are designed to be excellent
for running AND for dancing AND for mountain hiking: I'd much rather
have three specialized pairs of shoes instead, one pair for running, one
for dancing, one for hiking.
Similarly, I'd rather have one tool to take presumably-correct sources
and generate great machine code from them, and separate tools to nitpick
the bejeezus out of the sources to make really sure they ARE indeed
perfectly correct from all viewpoints. Two (or more) simple, fully
specialized tools make for a better toolbox than one complex,
multi-purpose one. Few except engineers seem to understand this.
When is no longer using a language, one has the luxury of thinking
about it in an ideological rather than practical manner.
I thought about Fortran in exactly the same way when I was doing most of
my coding in it, and also using it to teach "numerical computing" in
university. Most errors came (and still come) from people who just
don't understand the underlying mathematical nature and realities of
floating point (and numerical computations more generally), and I never
expected a compiler to magically start warning the user about "you're
using a very badly conditioned algorithm for this computation":-), the
one thing that would have really saved me a lot of time in my advisory
and teaching roles. Exactly the same problems keep surfacing in
programs in Python and any other language too, barely veiled by today's
growing propensity for double-precision and wider-yet floats; offering a
rich library of functions is NOT a viable replacement for understanding
and approaching computation correctly (users will just call extremely
general library functions, rather than understand their problem's
specific "geometries" and address them appropriately).
(Let me offer one more plug for my favorite "book about programming
without a single line of code in it", Foreman Acton's "Real computing
made real", now out in a wonderfully cheap Dover edition: Acton makes
this case better than I've ever seen it made elsewhere, and offers many
excellent examples of how numerical computation SHOULD be done).
Alex
.
- References:
- Numbers and truth values
- From: Szabolcs
- Re: Numbers and truth values
- From: Steven D'Aprano
- Re: Numbers and truth values
- From: Szabolcs
- Re: Numbers and truth values
- From: Steven D'Aprano
- Re: Numbers and truth values
- From: Alex Martelli
- Re: Numbers and truth values
- From: Beliavsky
- Numbers and truth values
- Prev by Date: Re: fastest way to find the intersection of n lists of sets
- Next by Date: Re: relative import broken?
- Previous by thread: Re: Numbers and truth values
- Next by thread: Re: Numbers and truth values
- Index(es):
Relevant Pages
|