C Compilation..

[jameskuyper]

Yes. I think that whatever you may think of Heathfield's ideas and
posting style, even the most die-hard sycophants will have to admit that
he really put his foot in it this time.

You simply have to realize that in the real world, customers pay the
bills *and* customers don't give a darn about "how ya did it". They
care that it works and works well.

So, how does creating incorrect code quickly meet that need? Incorrect
means "it does not work".

... No real world customer is going to
prefer a "100% portable"

Who was talking about "portable"? He said "correct". If "portable" is
one of the requirements for a program (as it should be, to varying
degrees, for most programs), then it's relevant to "correctness".
However, he was making a much more general statement. Consider a
program with no portability requirements whatsoever: there is only one
machine anywhere in the entire world that it needs to run on. However,
it is required to calculate a particular value with a specified
accuracy. Richard Heathfield's point was that designing an algorithm
that actually calculates that number to the required accuracy is more
important than one which calculates a number that doesn't, no matter
how fast the algorithm is that calculates the wrong number.

 

[Kenny McCormack]

So, how does creating incorrect code quickly meet that need? Incorrect
means "it does not work".


Who was talking about "portable"? He said "correct". If "portable" is

You're making a ridiculous point. Of course it has to be correct in
terms of producing the right answer (and whatever else is actually
required). That's just man-of-straw.

In this newsgroup, "correct" has a very different and much larger
meaning. If you stick around for awhile, you will see.

(I could write volumes more on this - to get you to see what is meant -
but I don't have that kind of time)

 

[Antoninus Twink]

Who was talking about "portable"? He said "correct".

I believe Kenny was referencing my post, where I pointed out that
Heathfield has turned portability into such an idol that for him speed
(and even correctness) play second-fiddle to this golden calf.

 

[Antoninus Twink]

For example, the claim that I don't care about speed is patently
foolish, and it would seem likely that the basis (such as it is) for
that claim is based on a single program in which I missed a single
optimisation that would have taken longer to implement and test than
it could have conceivably saved in a million years of running the
program.

It's based on your posting history observed over many years.

Do you deny advising someone to call time() in a busy loop for
portability, rather than using sleep(3) or whatever other mechanism is
provided on his platform?

 

[santosh]

It's based on your posting history observed over many years.

Do you deny advising someone to call time() in a busy loop for
portability, rather than using sleep(3) or whatever other mechanism is
provided on his platform?

Er, I think I did that, though I wouldn't call it "advising" anyone. It
was merely mentioned (and admitted to) as a poor implementation of
sleep.

 

[Keith Thompson]

Keith Thompson wrote: [...]

You're both right. Sometimes speed is simply part of the
requirements. (And sometimes it isn't.)

*Sometimes* getting the right answers too late isn't much better than
getting wrong answers.

Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late? By wrong, I
don't mean an inaccurate answer that is acceptably close to the true
value; I mean an answer which is unacceptably far away from the true
value.

Perhaps under some bizarre circumstances. But my point was just that
in *some* circumstances, late answers are no better than wrong
answers, not that wrong answers are acceptable.

(You wrote "unacceptably far away"; it's difficult to argue that that
would be acceptable.)

 

[Kenny McCormack]

I believe Kenny was referencing my post, where I pointed out that
Heathfield has turned portability into such an idol that for him speed
(and even correctness) play second-fiddle to this golden calf.

Yes, and also that, in the lingo of this newsgroup, "correct" means
"100% portable". This statement is not argumentation; it is cold, hard
fact.

The problem is that, by redefining most of the standard concepts that
most of us know and use in our lives as programmers, they (the CLC regs)
have painted themselves into a corner. They can no longer use ordinary
terms like "correct" in their ordinary sense, since they have gone to
such lengths to make everything means something else (in the CLC frame
of reference).

I am reminded of how, on the old "What's My Line?" program, they redefined
the term "animal" to mean, essentially, "2 or 4 footed mammals". Which
is obviously limiting, in terms of what we know to really be animals.
Much like the CLC regs have defined "C" to be a tiny subset of what we
know to really be the "C" language.

 

[Kenny McCormack]

It's based on your posting history observed over many years.

Yes. As I've posted in my other response, they've redefined the terms,
so that "correct" doesn't mean what it normally means (to us normal
people).

Do you deny advising someone to call time() in a busy loop for
portability, rather than using sleep(3) or whatever other mechanism is
provided on his platform?

They don't really explicitly "recommend" it - but they describe it in
terms designed to make the newbie think that it is somehow immoral to use
*any* "system specific" functionalities (*). And, of course, you all know
why I put "system specific" in quotes...

(*) And that it is somehow morally superior to do the stupid thing (the
busy loop) rather than taint their mortal soul with "system specific"
functionalities.

 

[Richard]

Yes. I think that whatever you may think of Heathfield's ideas and
posting style, even the most die-hard sycophants will have to admit that
he really put his foot in it this time.

You simply have to realize that in the real world, customers pay the
bills *and* customers don't give a darn about "how ya did it". They
care that it works and works well. No real world customer is going to
prefer a "100% portable" solution that is so slow that, for all
practical purposes, it can be said to simply not work. Nor is any real
world customer going to answer in anything other than the obvious way
when asked "So, Mr. Customer who is paying my bills, I can make this
code run faster - making you look better to your bosses - but at the
cost of making it not quite so aesthetically pleasing to the denizens of
this Usenet newsgroup called (amazingly enough) 'comp.lang.c'. Whaddya
think? Should I do it?"

Mind you, all of the above is spoken as one who really does take pride
in my work, likes to make my code aesthetically pleasing, and is
actually somewhat miffed to find that my customers really don't give a
darn about "how ya did it". But that's reality - a domain in which few
clc regulars have had to function in, in decades.

Extremely well said.

Maybe AT should re-post his little dialog between CBF and his
hypothetical customer. Was quite illuminating.

--

 

[Kenny McCormack]

Mind you, all of the above is spoken as one who really does take pride
in my work, likes to make my code aesthetically pleasing, and is
actually somewhat miffed to find that my customers really don't give a
darn about "how ya did it". But that's reality - a domain in which few
clc regulars have had to function in, in decades.

Extremely well said. [/QUOTE]

Elvis: Thank you very much!

 

[dj3vande]

Keith Thompson wrote:

Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late?

If you're asking the wrong question anyways, it doesn't matter what the
answer is, and the sooner you get it the sooner you can discover it's
useless.


dave
(had that happen more often than I care to admit)

--
Dave Vandervies dj3vande at eskimo dot com

loose the global variables. Really.

Please don't. I'd much prefer it if you kept them under control, or humanely
put them to sleep. --Richard Heathfield in comp.lang.c

 

[Keith Thompson]

If you're asking the wrong question anyways, it doesn't matter what the
answer is, and the sooner you get it the sooner you can discover it's
useless.

If you're computing a course to get away from some Really Bad Thing
that's about to happen, getting an incorrect course that takes you
safely to the wrong place is better than waiting so long that the
Really Bad Thing gets you before you can leave.

 

[Willem]

Keith Thompson wrote:
) If you're computing a course to get away from some Really Bad Thing
) that's about to happen, getting an incorrect course that takes you
) safely to the wrong place is better than waiting so long that the
) Really Bad Thing gets you before you can leave.

It could be argued that 'computing a course to get away from ARBTTATH'
implies that any course that 'gets you away from ARBTTATH' is a correct
course, so 'getting an incorrect course' implies *not* getting away from it.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Richard]

raashid bhatt said:


No. C code need not even *be* compiled into a particular machine's machine
code. Often it is not - it is compiled (translated) into a particular
machine's assembly language instead. It could even be compiled into some
completely different language. Or it might not be compiled at all (C
interpreters exist).

ASM is another language. So when is translation not compilation?

 

[Richard]

You're both right. Sometimes speed is simply part of the
requirements. (And sometimes it isn't.)

Speed is always beneficial in *everything* if the speed gain is not
offset by maintenance or stability issues.

The reason desktops are 5000 times more powerful yet nothing seems to
run much quicker than the first PCs is wasteful and lazy approaches.

If you use C and do NOT consider efficiency in most cases then you are
incompetent.

 

[Joachim Schmitz]

Can you give any example of a situation where it's BETTER to get a
wrong answer early than to get the right answer late? By wrong, I
don't mean an inaccurate answer that is acceptably close to the true
value; I mean an answer which is unacceptably far away from the true
value.

Think of DeepThought's useless answer '42' after calculating some milion
years.
Not realy a real live example, but still ... an early answer probably would
have been pretty bad for the book

Bye, Jojo

 

[James Kuyper]

(e-mail address removed) writes: ....

Perhaps under some bizarre circumstances. But my point was just that
in *some* circumstances, late answers are no better than wrong
answers, not that wrong answers are acceptable.

(You wrote "unacceptably far away"; it's difficult to argue that that
would be acceptable.)

Well, yes - that was precisely my point.

 

[James Kuyper]

Speed is always beneficial in *everything* ...

Speed is not always beneficial - in real-time programming, there's often
an optimum time to do something, and extra speed beyond what's needed to
meet that deadline provides no extra benefit. The extra speed is
generally not harmful, if handled correctly by inserting an appropriate
waiting period somewhere in the process, but it isn't beneficial.

... if the speed gain is not
offset by maintenance or stability issues.

Or, getting back to the topic at hand, correctness issues?

The reason desktops are 5000 times more powerful yet nothing seems to
run much quicker than the first PCs is wasteful and lazy approaches.

If you use C and do NOT consider efficiency in most cases then you are
incompetent.

No one has suggested that efficiency be ignored, only that it's a lower
priority than correctness.

 

[Keith Thompson]

Keith Thompson said:

If you adopt the reasonable position that your personal safety is the
overriding requirement and you want it RIGHT NOW, then any course that
results in your personal safety being assured *is* a correct course and
fails to be a counterexample. And if there is no such course, then the
proper thing to do is to tell the computer to keep spitting out *accurate*
solutions, sorted and displayed by increasing risk, until you choose one
of them (presumably one that's at or near the top of the list). That way,
you decide how much time it can spend on finding solutions instead of
letting it decide for itself.

The software was designed for ordinary navigation, not for emergency
situations (though it *should* work in emergencies as well). It
produces an incorrect course randomly one time out of ten. You tell
it you want to go to Argelius, and it gives you a course to Janus VI,
clearly a bug. To recover, you have to reboot the system, which takes
at least seven minutes, something you can usually live with, but not
today, blast it, so you're darned lucky it didn't plot a course into
the middle of the nearest star. The bug has been reported but not yet
fixed. And Scotty and Spock have both been on shore leave for a week
(not their idea), so there's no time to re-write the software, and the
manual override is malfunctioning and giving off multicolored sparks.

The result is "correct" for the current situation, but incorrect for
the situation for which the software was designed.

So yes, Janus VI will do nicely, thank you.

 

[Richard Tobin]

Re-read the original question that started this thread. Do you really
think the OP was asking about ABIs?

I took the OP to mean something like "if I'm writing a C compiler, are
there any standards I need to follow when deciding what code to
generate". And since a compiler writer usually wants his compiler to
produce code that interoperates with existing libraries and operating
system features such as signals, the answer is yes.

There are various other things he could have meant, but I chose the
interpretation that had the most interesting answer.

-- Richard