Re: Letter to US Sen. Byron Dorgan re unpaid overtime

From: Randy Howard (randy.howard_at_FOOmegapathdslBAR.net)
Date: 12/23/03 

Date: Tue, 23 Dec 2003 16:53:06 -0600

In article <f5dda427.0312231309.14594076@posting.google.com>, spinoza1111
@yahoo.com says...
> > It matters not where it's implemented: it's still O(n). If I have special
> > hardware to do it, all I change is the constant. This really is very
> > basic computer science.
>
> The problem is that there is no "constant" in "O(n)".

Bull. That's the convention, among people that actually have even a
mere working knowledge of CS theory. For comparing complexity of
algorithms, the convention of ignoring constant factors is the norm.

You not knowing this should be embarrassing for you, but you're too
ignorant to see it.

> You are using mathematics very sloppily.

Big-O notation isn't mathematics per se, it's computer science notation
for characterizing the run-time efficiency of algorithms. It's not
partial derivatives or vector calculus. (I'm sorry if you don't
know what those are, but if you can't handle the difference between
O(n) and O(n*n), I'm afraid real mathematics is hopeful for you).

> "O(n)" is mathematical slang for on the order of n

Not is not, is is *the* generally accepted form for comparison of
algorithms in computer science. AFAIK, it isn't used in pure
mathematics at all.

> and what you mean is n*K where K is the constant time

Yes, that is assumed and in most cases the constant is ignored,
unless you are micro-optimizing, something you yourself say is
trivia and not worth participating in.

> the firmware string implementation takes to examine one byte in its
> implementation of the opcode for "find a character, in the string".

hogwash. Are you talking about strchr()? If not, why not say
"length of the string". Do all processors support a single opcode
to find the length of a null-terminated string? If not, what
happens on those platforms? Name three unique processors that do
and what that instruction would be on each of them.

> My experience is based on academic theory, and writing the firmware
> assembler and compiler for the Nortel SL-1 system, a layered CISC and
> stack based architecture, and in that system, the K constant was about
> an order of magnitude less than the K constant for the execution of a
> non-firmware instruction.

In other words, that was a micro-optimization, because it didn't change
the order of the overall algorithm. I thought that was trivia?

> I conclude that it is nonsense to declare that the "O(n)" for a
> character search in C code is the same as the "O(n)" for the firmware.

You seem to be unaware that firmware is often written in C. I don't
think you even know what firmware means. Go ahead, look it up, then
post a response pretending like you already knew. Also, nothing
guarantees that an assembly language implementation "in firmware" will
outrun something compiled and optimized by a good C compiler.

Dipshits can write bad code in any form, as you amply prove.

> I am well aware that RISC machines abandon these types of instructions
> and actually might compile a strlen to the EQUIVALENT of
>
> for ( intIndex1 = 0; strInstring[intIndex1] != '\0'; intIndex1++ ) { }
> return(intIndex1);
>
> But all this means is that in real problems, you are better off either
> using a better string representation,

To quote from "A Beautiful Mind", I am terrified, mortified, petrified,
stupefied by you. You still don't get it that it's not the single
instance runtime of strlen that is the problem. That simply *is*
the nature of '\0'-terminated strings. The part you seem incapable
of understanding is that there is no need to call it over and over
when the length of the string is not changing within the loop.

If I asked you what time it was exactly every 10 minutes, would you
assemble a new watch from spare parts every time I asked? Or would you
simply add ten minutes to your last answer on each iteration and move
on?

THIS IS NOT HARD. EVEN YOU SHOULD BE ABLE TO COMPREHEND IT.

> I am not so sure. I would not trust him to write a Fortran or Basic
> compiler since the For semantics are different.

One would not attempt to write a basic compiler using C semantics.
On the other hand, you have attempted to write C code using basic
semantics, so maybe there really are people that incompetent. I'm
sure Richard isn't one of them though, so try again. Make up
another lie and see who doesn't shoot holes in it.

> For the last time: strlen communicates intent and courteous
> individuals can change it without exhibiting their vanity and
> arrogance.

how does calling strlen on every iteration of a loop with a fixed
string communicate intent better than

size_t mystrlen = 0; /* size_t can hold any valid value */
size_t I; /* loop index value */

/* the length of string foo remains constant throughout this loop,
 * so because we know what we are doing, we will call it only once
 * and reuse it over and over inside the loop without incurring
 * additional runtime performance penalties. Interestingly, this
 * method will allow us to use any length string which is supported
 * on this hardware architecture without O(n*n) runtime penalties
 * found with more naive, novice methods. Hopefully this is clear
 * to the reader. If you can't understand this, perhaps you should
 * take up poetry.
 */
mystrlen = strlen(foo);

for(I = 0; I < mystrlen; I++)
{
        /* do something useful foo */
}

Or is the communication you are intending to tell everyone that you
are a moron? In which case, I agree, your method is much better
at communicating that fact.

> I think I have post facto fully explained my views on this matter. Let
> it drop.

You fully explained why you have no clue. You can choose to learn from
it, or persist in your ignorance. Given your track record to date,
the former isn't likely to happen.
  
> It happens to be good practice to create a prototype that best conveys
> intent and then make it faster. That's why I used strlen.

strlen isn't the problem. YOUR USE OF STRLEN is the problem. grok?

> > Back to the front though. Obviously then, this Algol-60 for loop is also
> > "deviant and passive agressive":
> >
> > for NewGuess := Improve(OldGuess)
> > while abs(NewGuess - OldGuess) > 0.0001
> > do OldGuess := NewGuess;
> >
> > It wasn't, of course, designed by Ritchie unless he secretly snuck into
> > the committee room without anyone noticing. C certainly doesn't have a
> > monopoly on for loops which re-evaluate the condition once per iteration.
> >
> Thanks for the information concerning Algol-60. At the time it was
> designed, its designers were unaware of the need to track meaning, and
> so was Ritchie.

Even today, you don't understand either language any more than my dog
understands geometry. I thought you said Algol was the way to go, so
much so that you were going to write your own compiler for it. Now you
suddenly are informed (you didn't know) that it doesn't behave the
way you dreamed that it did, so it's designers were flawed. A few
days ago, it was only C that was flawed. There is a flaw in C, which
I've realized during this discussion. There is nothing in the compiler
which requires an IQ test for the author before code generation. If
it did, you would have never had this problem in the first place.

Hypocrisy isn't sufficient. A new word must be created to encompass
the full magnitude of your existence.

> It is that Richard in fact knows that I've forgotten more C than he
> knows

Correction: You have forgotten all C that you ever knew. You also
appear to have forgotten all computer science, mathematics, logic
and common sense. As such, you you have forgotten a great deal
more than most people forget in a lifetime.

> But I find nothing in Richard's posts that manifests an awareness of
> either general computing culture or culture outside computing.

That might be because this group isn't about sociology, and culture
outside of computing is not on topic here.

On the topic of general computing, it appears that even the most
basic elements of general computing are foreign to you.

[persiflage & pseudo-intellectual pretend sociology bull*** snipped]

> My usual method of course is to get it right and then optimize, and I
> follow the lead of hero computer scientist Niklaus Wirth in this
> regard.

You couldn't darn his socks. I can't think of any sentient person
in this business that would even allow you to fill printer paper
after reading this thread.

> They were losers because in fact the dominant architectures today
> remain CISC, and the unix and C sub-culture/tribe is being pushed out
> by architectures based in CISC.

That must be why the largest UNIX variant market today (Linux) runs
first, and most often on CISC processors. Do you EVER think before
you write?

> They flee to the false promise of linux despite the fact that we now
> know that vast sections of linux code were copied from a commercial
> unix product

Incorrect. It has been shown, quite convincingly in multiple places
that SCO thinks they have copyright over code taken from freely
available BSD licensed code, as well as some source examples (from
their own claims) which were published 40 years ago.

On the odd chance that you actually want to know, start here:
http://www.gnu.org/philosophy/sco/sco-without-fear.html
http://www.perens.com/SCO/SCOSlideShow.html
http://www.catb.org/~esr/writings/smoking-fizzle.html
http://www.lemis.com/grog/SCO/code-comparison.html

> and that companies that use linux are in for a world of hurt.

Again, you're wrong. But hey, it's a tradition now, stick with it. 

-- 
Randy Howard            _o     
2reply remove FOOBAR    \<,    
______________________()/ ()______________________________________________
SCO Spam-magnet: postmaster@sco.com