From: Hector Santos on
And so did a few others repeated the obvious in the comp.lang.c++ group.

The difference?

No one provided example CODE like the dude over in the comp.theory
which peter sadly said he got no answers here and comp.lang.c++.

Problem for Peter?

The dude only provided 1/2 code. Its eating Peter alive he has to
figure out the other half! <g>

That what will take him to another sorry thread in some other sorry group:

Hi, I have a new technology that is guaranteed to be the
fastest thing since roach racing.

But I only got 1/2 a C/C++ solution by this other guy
in another group. Why can't people be 100% complete
like I am when they are helping me? Can you give me
the 2nd half of this code provided to me?

Bonus: 30% stock in my invention for anyone who helps.
When it is completed in 2024, you will be a BILLIONAIRE!

--
HLS

Joseph M. Newcomer wrote:

> Oh. A techhique that has been known to me for about 40 years. And one which I pointed
> out.
> joe
>
> On Thu, 20 May 2010 11:29:51 -0500, Peter Olcott <NoSpam(a)OCR4Screen.com> wrote:
>
>> I got this answer from comp.theory. It was completely obvious once it
>> was explained. It is trivially simple to create a DFA based recognizer
>> without a state transition matrix data table. Simply encode case
>> statements corresponding to inputs within the case elements of a case
>> statement corresponding to states.
>>
>> In at least some cases the (case within case) method might be faster
>> depending upon whether or not memory is reduced enough to more than
>> offset the higher case statement overhead to increase cache locality of
>> reference.
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

From: Peter Olcott on
On 5/20/2010 12:26 PM, Leigh Johnston wrote:
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
> news:LZqdnVcWS8NL82jWnZ2dnUVZ_qOdnZ2d(a)giganews.com...
>> On 5/20/2010 12:10 PM, Leigh Johnston wrote:
>>
>> I posted this thread to cut to the chase of the other thread to reduce
>> the amount of discussion on the other thread. The other thread was
>> endlessly debating this point, now this thread provides the end to
>> that endless debate. There is no need to repond to this thread.
>
> So this thread was intended to simply be you stamping your foot? :)
> Really I think you should spend less time ruminating here and spend more
> time implementing and profiling stuff. You have caused me to waste time
> here also.
>
> /Leigh

You are definitely right on this. I do enjoy talking here though, and
several people have provided excellent advice, including you. I do still
focus too much on optimization. This has the disadvantage of making
development cost more. I am getting better and better at ignoring moot
optimizations.

There are advantages to focusing on optimization at the design stage.
The system is fundamentally designed to be fast, and no redesign is ever
needed to improve speed. I do still err too much on the side of
optimization.
From: Peter Olcott on
On 5/20/2010 12:14 PM, Joseph M. Newcomer wrote:
> Oh. A techhique that has been known to me for about 40 years. And one which I pointed
> out.
> joe

You only mentioned a case statement not a set of case statements nested
within a case statement. Since I was already using a case statement in
my own table driven code it was not immediately obvious what you were
referring to because you failed to provide this extra missing detail.

I would guess that this case within case design would tend to be
somewhat slower, but, it is too close to call without direct measurement.

>
> On Thu, 20 May 2010 11:29:51 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote:
>
>> I got this answer from comp.theory. It was completely obvious once it
>> was explained. It is trivially simple to create a DFA based recognizer
>> without a state transition matrix data table. Simply encode case
>> statements corresponding to inputs within the case elements of a case
>> statement corresponding to states.
>>
>> In at least some cases the (case within case) method might be faster
>> depending upon whether or not memory is reduced enough to more than
>> offset the higher case statement overhead to increase cache locality of
>> reference.
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

From: Hector Santos on
On May 20, 1:43 pm, Peter Olcott <NoS...(a)OCR4Screen.com> wrote:
> On 5/20/2010 12:14 PM, Joseph M. Newcomer wrote:
>
> > Oh. A techhique that has been known to me for about 40 years. And one which I pointed
> > out.
> > joe
>
> You only mentioned a case statement not a set of case statements nested
> within a case statement. Since I was already using a case statement in
> my own table driven code it was not immediately obvious what you were
> referring to because you failed to provide this extra missing detail.

No he didn't. You failed to have the LOGIC, COMPETENCE, IQ, and
IMAGINATION that nested and/or recursive based state transitions logic
are par for the course. Even CockRoachers understand that. There is
no need explain anything to you, just like I told you in one line:

And your uinderstanding is WRONG!

in regards to your moronic statement about C/C++ limited to ASCII.
One line is all that was needed. Lets see, it looked like it took
20+ mail tag messages before you realized how pathetic and wrong you
were - AGAIN.

Peter, didn't you say were a computer science major? Top 10 or 15 in
your class? Or is that yet another fib? What school did you attend
and what year did you graduate?
From: Sam on
Peter Olcott writes:

> On 5/20/2010 11:46 AM, Leigh Johnston wrote:
>> Google for "premature optimization" and then go away.
>>
>> /Leigh
>
> Rudeness can quickly kill your career prospects in ways that you may not
> even be aware of.

So is holier-than-though snobbishness.