Re: PROFESSIONAL floating-point algorithms.
From: Richard Heathfield (dontmail_at_address.co.uk.invalid)
Date: 01/04/04
- Next message: Richard Heathfield: "Re: PROFESSIONAL floating-point algorithms."
- Previous message: Willem: "Re: Writing bulletproof code"
- In reply to: Edward G. Nilges: "Re: PROFESSIONAL floating-point algorithms."
- Next in thread: Randy Howard: "Re: PROFESSIONAL floating-point algorithms."
- Reply: Randy Howard: "Re: PROFESSIONAL floating-point algorithms."
- Reply: Edward G. Nilges: "Re: PROFESSIONAL floating-point algorithms."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 4 Jan 2004 08:38:14 +0000 (UTC)
Edward G. Nilges wrote:
> Ben Pfaff <blp@cs.stanford.edu> wrote in message
> news:<87hdzc7qx1.fsf@pfaff.stanford.edu>...
>> "Arthur J. O'Dwyer" <ajo@nospam.andrew.cmu.edu> writes:
>>
>> > On Sat, 3 Jan 2004, Charles Douglas Wehner wrote:
>> > > http://www.wehner.org/fpoint/
>> >
>> > Ow! My eyes!
>>
>> Looks okay to me. 'Course, I used a text-based browser to view
>> it.
>
>
> Like your sig because I saw it long ago:
>
> "Premature optimization is the root of all evil."
> --D. E. Knuth, "Structured Programming with go to Statements"
>
> This applies of course to strlen() flames, doesn't it.
No. Knuth's intent was not that programs should be written to perform as
slowly as possible. Choosing an appropriate algorithm and implementing it
correctly does not constitute premature optimisation.
Loop unrolling is a good example of premature optimisation.
> In fact, I find it necessary to explain my mental categories, not to
> lesser minds but minds without my advantages. I was employed by
> Princeton University (gee, we know this now)
Oh? When did we learn this independently?
<off-topic stuff snipped>
> In computing science and its ethics, I take Knuth to mean that as a
> matter of strict, "lexical" priority, it is malpractice (and should be
> legally actionable malpractice) to use any form of coding trick to
> make your code fast BEFORE you have a prototype that works.
It is no "trick" to choose your algorithm intelligently and implement it
properly.
> Of course, my legalistic view is shall we say unusual.
It is, in fact, stupid. Whilst I agree that it is easier to make a correct
program fast than it is to make a fast program correct, that does not mean
we are obliged to ignore all we know about good programming practice when
writing the initial code.
> Most programmers unlike me come from an engineering background in
> which it's natural to make compromises and trade offs at all points in
> the project lifecycle. The problem is that such compromises are the
> problem as when a multiple threaded (or multiple process, dammit all
> to hell and gone) system is moved onto a faster CPU and stops working.
Can you name a specific CPU on which, for the same input data and for a
string s of a given length:
size_t len = strlen(s);
while(i < len)
{
dostuff(i);
}
will fail but:
while(i < strlen(s))
{
dostuff(i);
}
will work? And if you can, was this CPU designed by Edward G Nilges?
<nonsense snipped>
-- Richard Heathfield : binary@eton.powernet.co.uk "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton
- Next message: Richard Heathfield: "Re: PROFESSIONAL floating-point algorithms."
- Previous message: Willem: "Re: Writing bulletproof code"
- In reply to: Edward G. Nilges: "Re: PROFESSIONAL floating-point algorithms."
- Next in thread: Randy Howard: "Re: PROFESSIONAL floating-point algorithms."
- Reply: Randy Howard: "Re: PROFESSIONAL floating-point algorithms."
- Reply: Edward G. Nilges: "Re: PROFESSIONAL floating-point algorithms."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
