Re: strlen(), K+1: clarification

On Feb 22, 8:32 pm, Ben Bacarisse <ben.use...@xxxxxxxxx> wrote:
spinoza1111 <spinoza1...@xxxxxxxxx> writes:

<snip>

One issue can be resolved here. By posting repeatedly but snidely
about it without clarifying things (being a hater of clarity as shown
in his harassment of Schildt), Clive has managed to confuse a parallel
I drew last month between his use of K+1 to terminate a for loop
(where the C for repeatedly evaluates the for condition while the
Visual Basic and other for statements do not) and my use, in 2003, of
a strlen() in a for condition.

Ah, at last.  Your repeated and persistent claims about the supposed
code posted by Clive Feather were, as I most people here had
concluded, not true.  There was no strlen() in the loop condition.  I
don't suppose you'll apologise for saying he made the same mistake as
you?

He made the same mistake as me, and we are quite beyond apologies
given his conduct. strlen is not in essence any slower than a math
operation since it can be a single instruction whereas the math
instruction is in many cases two operations (push the constant, do the
math).

No scientific generalization, only folklore round de campfire,
declares that strlen *must* be slower than subtracting a constant on
all possible machines. When my mistake was pointed out to me, with the
vilest sort of rudeness, I mentally categorized it, I filed it the
*** away, as "OK, C sucks, don't evaluate invariants OF ANY SORT in a
for in cases where you need speed").

I saw Clive's mistake as the same overall mistake, and I feel he got a
free pass on the mistake as properly defined (don't evaluate an
invariant subexpression in a for loop): but looks like I forgot that
the thugs here don't have my ability to classify things properly and
regard L+1 as completely different in the for from strlen(s).

Both cases are "mistakes" iatrogenetically caused by the poor design
of C. I had no problem with Clive's expressing the bubble sort with an
invariant subexpression that could have been moved to the initializer:
I thought it good practice because an uncorrupted Kernighan wrote in
1976 "code what you mean". I had a big problem with the fact that the
thugs here recognized one of their own, and failed thereby to call
Clive on this pseudo-error.

End of story.

You now would like to suggest that K+1 in a condition is the same as
strlen.  If you had not said he'd used strlen there would have been
no confusion.





I'd pointed out that because Clive is so clearly One of the Thugs, his
thug pals here won't call him to account, and allow him to claim that
the K+1 is optimized away in all situations, which of course it is not
when optimizing is off. IF c for loops should NEVER contain invariant
operations (a claim made to me by the Thugs in 2003), and IF their use
indicates incompetence, THEN Clive is incompetent: this is the crazy
logic of this group when someone is being singled out for stalking and
harassment, even as Clive had to fabricate a Scholastic and closet C
with which to abuse Schildt.

Clive, although he has some issues, is not incompetent and has a right
to be here.

But the interesting technical point, revelatory as must be said of
Clive's limitations (for as regards Schildt, he's clearly one who
starts the personal destruction and must take the consequences) is
that only the most unimaginative nonprogrammer would fail to see that
strlen(s) and K+1 are the same from the standpoint of an effective
optimization strategy, which isn't (as Clive may fancy) just about the
elimination of unneeded arithmetic operation but about the search for
and elimination of repeated invariants, which strlen(s) can often
be...is usually.

Which brings up a technical problem I'd like to discuss, because my
purpose here apart from brisk self-defense isn't gossiping and
trashing personalities like some sort of little baby girl.

C programs can't be optimized, and once again, we see: C sucks.

That is, in

strcpy(s, "ABC"); for (a, i = 0; i < strlen(s); i++) ...

you can't optimise strlen(s) and move its evaluation out of the loop
because you don't know in general what a does, and this is not because
of some convenient Cloud of Unknowing which can be invoked as a deus
ex machina as Clive invoked the Great God, Undefinabus, it's because
of aliasing. Because of a's call, optimization either stops in its
tracks or proceeds to a train wreck but in the equivalent C Sharp code

s = "ABC"; a(); for (i = 0; i < s.length; i++) ...

the call of a(), insofar as a is safe code (as it almost always is),
has no effect on s when s is not global: if s is a global, because of
the absence of aliasing, a can be examined to see if it changes s.

Or, the optimizer can store the length of s in a temp after i is
zeroed. A C optimizer could also perform this "code motion" to avoid
a's affecting the length of s; but then the body of the loop has to be
examined for aliased modifications to s and its length.

More precisely, the C optimizer has to find only the possibility and
at this point it has to fail to optimize. The C Sharp optimizer
likewise has to give up when it finds safe code, but the safety of the
latter is a design feature which means that statistically, we can
predict that optimized C programs fail much more frequently than
optimized C Sharp, Java or even VB programs!

And, of course, they do, to the delight of the Fat Bastards and the
thugs who won't learn anything new because they are too busy harassing
people.

This means that statistically, C Sharp and Java code may be just as
"efficient" or even faster than actually running C code because the
maintainers of the latter cannot optimize the code safely.

In fact, as opposed to Java, C Sharp and Visual Basic programs, C
programs should not be optimized because after optimization many will
exhibit buggy behavior. To optimize a C program you need to employ Yet
Another Fat *** (YAFB) of a C consultant to check the program for
nonstandard praxis that defeats optimization, and this is simply not
necessary as regards Java and .Net, unless the programmer of the .Net
application (not the Java application) has opened a can clearly marked
Worms, using unsafe facilities.

One final note. Clive will have difficulty in seeing the similarity of
strlen(s) and K+1 I am sure. This is because people who learn things
in school by rote and without pleasure (anhedonically) tend to become
nasty little sods in later life, and to in general have knowledge that
doesn't scale.

Clive may very well believe that strlen() cannot be optimized because K
+1 simplification is math and he may have learned that "compiler
optimization is the optimization of mathematical operations".

But I've discovered that as long as you have even my layman's
knowledge of math, you realize that many optimizations easily transfer
to string operations! In fact, string concatenation and strings
themselves seem to form a group, mathematically, where a null string
is the zero element and, perhaps, a string of length one is 1.

This means that you can eliminate K + A in an optimization-safe
language like C Sharp using safe code when dataflow analysis shows you
that A is a null string and the plus sign is string concatenation.

There is much wrong in here that I just can't face picking it apart.
I'll leave you to believe that strings + concatenation form a group
and that C can't be optimised.

If you happen to more group theory than me, I'd welcome an
explanation. I think you need practice in expressing yourself in
writing and comprehension: my experience on Lamma island was that
people who are deficient in these regards lose their temper and give
up.

You've kept your temper admirably.

But note that I didn't say "strings with concat are a group" because
I'm not a mathematician and have only an amateur's knowledge of groups
(which is more than most, but insufficient to speak with authority). I
said that because they are "like" a group, we should optimize them!

--
Ben.- Hide quoted text -

- Show quoted text -

.

Quantcast