From: Peter Olcott on
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.
From: Leigh Johnston on
"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
news:wtadnXb96NPj_mjWnZ2dnUVZ_r4AAAAA(a)giganews.com...
> 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.

There is nearly always more than one way of achieving the same goal and
whether or not one way is faster than another can only be definitively
determined through profiling.

Google for "premature optimization" and then go away.

/Leigh

From: Peter Olcott on
On 5/20/2010 11:46 AM, Leigh Johnston wrote:
> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
> news:wtadnXb96NPj_mjWnZ2dnUVZ_r4AAAAA(a)giganews.com...
>> 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.
>
> There is nearly always more than one way of achieving the same goal and
> whether or not one way is faster than another can only be definitively
> determined through profiling.
>
> 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.

If you don't like what I am saying then simply do not respond to my posts.

From: Hector Santos on
In other words, you got an AH-HA in Computer Science 101? One would
thing that for a guy with an IQ of a Doctor (I say CockerRoach) you
wouldn't have to ask these silly questions.

BTW, once again, you went to another forum and told a lie:

"I was wondering if there is a generally faster way to
implement a DFA recognizer than by using a state transition
matrix.

I already asked this question on several other groups and
never received any definitive answer."

You were told by my count 3-4 people here the same exact answer you
got over there. The difference and this is the bottom line with you,
the fellow over there PROVIDED you with an example simple CS 101 piece
of code.

The thing is, you are probably biting your lip because he only provide
1/2 code example, You have to figure out the rest - and that will
take you another 11 years!

--
HLS
Peter Olcott 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.
From: Leigh Johnston on


"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
news:gaydndk9W-fp9mjWnZ2dnUVZ_rkAAAAA(a)giganews.com...
> On 5/20/2010 11:46 AM, Leigh Johnston wrote:
>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
>> news:wtadnXb96NPj_mjWnZ2dnUVZ_r4AAAAA(a)giganews.com...
>>> 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.
>>
>> There is nearly always more than one way of achieving the same goal and
>> whether or not one way is faster than another can only be definitively
>> determined through profiling.
>>
>> 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.
>
> If you don't like what I am saying then simply do not respond to my posts.
>

Spamming newsgroups with off-topic posts is more rude then somebody telling
said spammer to cease and desist. How many more threads are you going to
create on this off-topic subject? You must have created six so far. None
of them relate directly to the C++ programming language.

/Leigh