Prev: check boxes in a tree
Next: Not sure about manifest file regarding transparent check boxes inUnicode version
From: Joseph M. Newcomer on 20 May 2010 13:14
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: Joseph M. Newcomer on 20 May 2010 13:16
There is nothing rude about stating that there is nearly always more than one way to
achieve something, or suggesting a google search string.

Could you point out PRECISELY where this person was "rude"?

My career prospects never suffered from my being outspoken. On the contrary, I have been
very successful.
joe

On Thu, 20 May 2010 12:03:48 -0500, Peter Olcott <NoSpam(a)OCR4Screen.com> wrote:

>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.
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 20 May 2010 13:18
On 5/20/2010 12:10 PM, Leigh Johnston wrote:
>
>
> "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

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.
From: Peter Olcott on 20 May 2010 13:19
On 5/20/2010 12:16 PM, Joseph M. Newcomer wrote:
> There is nothing rude about stating that there is nearly always more than one way to
> achieve something, or suggesting a google search string.
>
> Could you point out PRECISELY where this person was "rude"?
>

This
>>>and then go away.

> My career prospects never suffered from my being outspoken. On the contrary, I have been
> very successful.
> joe
>
> On Thu, 20 May 2010 12:03:48 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote:
>
>> 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.
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

From: Leigh Johnston on 20 May 2010 13:26
"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:
>>
>>
>> "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
>
> 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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: check boxes in a tree
Next: Not sure about manifest file regarding transparent check boxes inUnicode version