Designing a Finite State Machine DFA Recognizer for UTF-8
in [MFC]
|
Prev: Designing a Finite State Machine DFA Recognizer for UTF-8
Next: Simple Valication Check... Question
From: Peter Olcott on 22 May 2010 09:21 If you can't be polite I will not talk to you anymore! On 5/21/2010 11:54 PM, Hector Santos wrote: > Peter Olcott wrote: > >> On 5/21/2010 9:42 PM, Hector Santos wrote: >>> Peter Olcott wrote: >>> >>>>> First, typo fixes, the above should be: >>>>> >>>>> BOOL UTF8_to_UTF32( >>>>> const BYTE *utf8, const int &utf8_size, >>>>> BYTE *utf32, int *utf32_size); >>>> >>>> That is still wrong. >>> >>> >>> So you are claiming that this primitive prototype is less efficient than >>> you passing an object? >> >> No I am claiming that you still have a typo. > > > Are you smart enough to tell us where? Also you said > > "implies a slower design." > > Explain how that is so? > >>> But you just said the encoding would be faster. What part of "YOUR" >>> design is faster than anything else? >> >> It is a combination of a state transition table with a switch >> statement, that is what will make it faster than a switch statement by >> itself or a sequence of multiple if else if statements. > > > Besides that fact that you are using OBJECT elements, this is factored > out because its a COMMON concept, which means that the primitive > functional prototype STILL makes it faster than your OBJECT version > which proves without a shadow of a doubt that it is faster than your > silly version. > >>> So the DESIGN including memory leak prevention? How does that pertain to >>> the primitive functional prototype? You do know what the term primitive >>> means here? >> >> I am passing in a std::vector which shows that I am not allocating >> memory myself, and you are passing in a pointer to a buffer and its >> length which tends to show that you are allocating memory yourself. > > > You're a SIMPLETON. You are ALLOCATING memory using std:vector as well. > It doesn't matter of the LIBRARY is doing for you. You are still > allocating memory. There is no way you can do this FASTER then a > primitive function generator. > >>> But how that related to the FASTER translator? And how doe std:vector<> >>> prevent memory allocation leaks? >> >> It you never directly allocate any memory yourself, then you never >> make any memory allocation mistakes. > > > SIMPLETON! There is no such thing as a bad language, just BAD > programmers - YOU ARE WORST THAN BAD - TERRIBLE. > > You have no RIGHT to speak about CODE OPTIMIZATION. > >>> Thats because you never did any real programming and you have a >>> primitive mind, not the primitive I speak of above, but SIMPLETON, >>> SIMPLE MIND, PRIMITIVE MIND. >> >> Why do you insist on being such a jackass? I have respect for you. The >> fact that you can't show respect for me indicates a huge issue with >> your own self esteem. Get over it already! > > > But I can prove I am EXPERIENCED JACKASS. You are in the other hand are > an unethical JACKASS that pretends to be intelligent about software and > you show that you are not. > >>> Basically what you are admitting to that you don't understand dynamic >>> memory operations. >> >> I am saying that user specified dynamic memory allocations are like >> gotos were to Edsger Dijkstra. > > > Are you serious? You are? > >>> Request #4: You are ignoring the question. You stated you are a comp sci >>> major. What school did you attend and what year did you graduate? > > >> I graduated from the University of Nebraska, disclosing graduation >> dates can in some cases reduce employment prospects. For self employed >> people (like you and Joe) this is no issue. > > > Whats the secret of not stating what year? No sweat I can find out. > I'm a 1982 Drexel graduate with a Chemical Engineering degree. > > Nevetheless, so why do you show to have such a low intelligence level > when it comes to computer programming and do not seem to understand > basic computer science and programming concepts? > > I believe you said you were unemployed. > > Trust me as an person who has hired and managed people, you are doing > FAR MORE damage to yourself with these postings of yours that clearly > shows you have a very low competence and understanding of technology and > software programming. A simple GOOGLE search will show that you a) not a > team player, b) has an unworthy and lack of trusting demeanor c) argues > nearly 100% of time, d) does not know how to hold his own or research a > solution on his own and e) make statements that are absurd and nearly > always proven wrong. > > If you are concern about any of this, I would recommend that you change > your behavior, but its really too late since you been behaving like this > for quite a long time, and the archives are rich with the Peter Olcott > story. > > It has nothing to do with "CUSSING" or rudeness, Joe and I. You > exhibited this behavior with everyone and everywhere you go going back > quite a few years. It has to do with the fact you are really out of your > league here and attempting to be nice to people won't remove the fact > that your interaction with technical people is really bad. > > -- > > HLS
From: Peter Olcott on 22 May 2010 09:33 On 5/22/2010 4:50 AM, Joseph M. Newcomer wrote: > See below... > On Fri, 21 May 2010 22:50:40 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: > >> I already posted it you should be able to tell. I also checked on >> another (more specialized) newsgroup for alternative designs. There were >> only two basic alternatives provided. Joe said that hand coded lexers >> can be faster than table driven ones. The evidence that he provided for >> the is a paper that showed improvements to table driven parsers. > **** > And that implementation has a hard-coded lexer in it as well. I was searching for a paper > that corresponded to Nigel's presentation to our working group, and that was the closest > one to what he presented. The lexer is generated from the lex tables. It's hard code all > the way down. Maybe you can go read some of his other papers. I'm not going to take the > time to justify every little detail to you. > joe > **** There are only three basic designs for lexers that I uncovered: (1) Case statement within case statement solutions (2) Multiple sequences of if else if statements (3) State transition matrix based solutions It seems that the latter one has far fewer instructions in its instruction trace table, and in many cases (such as the UTF8_to_UTF32 converter) is small enough to entirely fit within cache. Although you have convinced me that one can not be sure of the actual relative performance without actual benchmark testing, I am still going with the last option as the best choice. Others can feel free to benchmark against this choice when I complete this code next week.
From: Hector Santos on 22 May 2010 09:52 Pedro, You should feel lucky of the few people still responding to you! You are like a sad lost puppy that people want to fed out of sympathy. You do notice that almost everyone tells you, in their own ways, subtle or not, you're an idiot? You did say you were unemployed. Ever wonder why? Ever wonder why you still having produced any product in 11 years? Not even any evidence of usable software FOR ANYTHING OR ANYONE? Ever wonder why you always are proven wrong for ALL claims you make? -- HLS Peter Olcott wrote: > If you can't be polite I will not talk to you anymore! > > On 5/21/2010 11:54 PM, Hector Santos wrote: >> Peter Olcott wrote: >> >>> On 5/21/2010 9:42 PM, Hector Santos wrote: >>>> Peter Olcott wrote: >>>> >>>>>> First, typo fixes, the above should be: >>>>>> >>>>>> BOOL UTF8_to_UTF32( >>>>>> const BYTE *utf8, const int &utf8_size, >>>>>> BYTE *utf32, int *utf32_size); >>>>> >>>>> That is still wrong. >>>> >>>> >>>> So you are claiming that this primitive prototype is less efficient >>>> than >>>> you passing an object? >>> >>> No I am claiming that you still have a typo. >> >> >> Are you smart enough to tell us where? Also you said >> >> "implies a slower design." >> >> Explain how that is so? >> >>>> But you just said the encoding would be faster. What part of "YOUR" >>>> design is faster than anything else? >>> >>> It is a combination of a state transition table with a switch >>> statement, that is what will make it faster than a switch statement by >>> itself or a sequence of multiple if else if statements. >> >> >> Besides that fact that you are using OBJECT elements, this is factored >> out because its a COMMON concept, which means that the primitive >> functional prototype STILL makes it faster than your OBJECT version >> which proves without a shadow of a doubt that it is faster than your >> silly version. >> >>>> So the DESIGN including memory leak prevention? How does that >>>> pertain to >>>> the primitive functional prototype? You do know what the term primitive >>>> means here? >>> >>> I am passing in a std::vector which shows that I am not allocating >>> memory myself, and you are passing in a pointer to a buffer and its >>> length which tends to show that you are allocating memory yourself. >> >> >> You're a SIMPLETON. You are ALLOCATING memory using std:vector as well. >> It doesn't matter of the LIBRARY is doing for you. You are still >> allocating memory. There is no way you can do this FASTER then a >> primitive function generator. >> >>>> But how that related to the FASTER translator? And how doe std:vector<> >>>> prevent memory allocation leaks? >>> >>> It you never directly allocate any memory yourself, then you never >>> make any memory allocation mistakes. >> >> >> SIMPLETON! There is no such thing as a bad language, just BAD >> programmers - YOU ARE WORST THAN BAD - TERRIBLE. >> >> You have no RIGHT to speak about CODE OPTIMIZATION. >> >>>> Thats because you never did any real programming and you have a >>>> primitive mind, not the primitive I speak of above, but SIMPLETON, >>>> SIMPLE MIND, PRIMITIVE MIND. >>> >>> Why do you insist on being such a jackass? I have respect for you. The >>> fact that you can't show respect for me indicates a huge issue with >>> your own self esteem. Get over it already! >> >> >> But I can prove I am EXPERIENCED JACKASS. You are in the other hand are >> an unethical JACKASS that pretends to be intelligent about software and >> you show that you are not. >> >>>> Basically what you are admitting to that you don't understand dynamic >>>> memory operations. >>> >>> I am saying that user specified dynamic memory allocations are like >>> gotos were to Edsger Dijkstra. >> >> >> Are you serious? You are? >> >>>> Request #4: You are ignoring the question. You stated you are a comp >>>> sci >>>> major. What school did you attend and what year did you graduate? >> >> >>> I graduated from the University of Nebraska, disclosing graduation >>> dates can in some cases reduce employment prospects. For self employed >>> people (like you and Joe) this is no issue. >> >> >> Whats the secret of not stating what year? No sweat I can find out. >> I'm a 1982 Drexel graduate with a Chemical Engineering degree. >> >> Nevetheless, so why do you show to have such a low intelligence level >> when it comes to computer programming and do not seem to understand >> basic computer science and programming concepts? >> >> I believe you said you were unemployed. >> >> Trust me as an person who has hired and managed people, you are doing >> FAR MORE damage to yourself with these postings of yours that clearly >> shows you have a very low competence and understanding of technology and >> software programming. A simple GOOGLE search will show that you a) not a >> team player, b) has an unworthy and lack of trusting demeanor c) argues >> nearly 100% of time, d) does not know how to hold his own or research a >> solution on his own and e) make statements that are absurd and nearly >> always proven wrong. >> >> If you are concern about any of this, I would recommend that you change >> your behavior, but its really too late since you been behaving like this >> for quite a long time, and the archives are rich with the Peter Olcott >> story. >> >> It has nothing to do with "CUSSING" or rudeness, Joe and I. You >> exhibited this behavior with everyone and everywhere you go going back >> quite a few years. It has to do with the fact you are really out of your >> league here and attempting to be nice to people won't remove the fact >> that your interaction with technical people is really bad. >> >> -- >> >> HLS >
From: Joseph M. Newcomer on 22 May 2010 12:38 See below... On Sat, 22 May 2010 08:33:43 -0500, Peter Olcott <NoSpam(a)OCR4Screen.com> wrote: >On 5/22/2010 4:50 AM, Joseph M. Newcomer wrote: >> See below... >> On Fri, 21 May 2010 22:50:40 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: >> >>> I already posted it you should be able to tell. I also checked on >>> another (more specialized) newsgroup for alternative designs. There were >>> only two basic alternatives provided. Joe said that hand coded lexers >>> can be faster than table driven ones. The evidence that he provided for >>> the is a paper that showed improvements to table driven parsers. >> **** >> And that implementation has a hard-coded lexer in it as well. I was searching for a paper >> that corresponded to Nigel's presentation to our working group, and that was the closest >> one to what he presented. The lexer is generated from the lex tables. It's hard code all >> the way down. Maybe you can go read some of his other papers. I'm not going to take the >> time to justify every little detail to you. >> joe >> **** > >There are only three basic designs for lexers that I uncovered: >(1) Case statement within case statement solutions >(2) Multiple sequences of if else if statements >(3) State transition matrix based solutions **** (4) The case-pair decoder, with the current state and character pair Note that I already showed you this, so it would have taken zero effort to "uncover" it. Weren't you paying attention? I even wrote out the code, and it is not any of the above three cases! joe **** > >It seems that the latter one has far fewer instructions in its >instruction trace table, and in many cases (such as the UTF8_to_UTF32 >converter) is small enough to entirely fit within cache. > >Although you have convinced me that one can not be sure of the actual >relative performance without actual benchmark testing, I am still going >with the last option as the best choice. Others can feel free to >benchmark against this choice when I complete this code next week. 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 22 May 2010 13:34
On 5/22/2010 11:38 AM, Joseph M. Newcomer wrote: > See below... > On Sat, 22 May 2010 08:33:43 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: > >> On 5/22/2010 4:50 AM, Joseph M. Newcomer wrote: >>> See below... >>> On Fri, 21 May 2010 22:50:40 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: >>> >>>> I already posted it you should be able to tell. I also checked on >>>> another (more specialized) newsgroup for alternative designs. There were >>>> only two basic alternatives provided. Joe said that hand coded lexers >>>> can be faster than table driven ones. The evidence that he provided for >>>> the is a paper that showed improvements to table driven parsers. >>> **** >>> And that implementation has a hard-coded lexer in it as well. I was searching for a paper >>> that corresponded to Nigel's presentation to our working group, and that was the closest >>> one to what he presented. The lexer is generated from the lex tables. It's hard code all >>> the way down. Maybe you can go read some of his other papers. I'm not going to take the >>> time to justify every little detail to you. >>> joe >>> **** >> >> There are only three basic designs for lexers that I uncovered: >> (1) Case statement within case statement solutions >> (2) Multiple sequences of if else if statements >> (3) State transition matrix based solutions > **** > (4) The case-pair decoder, with the current state and character pair That is (1) above. > > Note that I already showed you this, so it would have taken zero effort to "uncover" it. > Weren't you paying attention? I even wrote out the code, and it is not any of the above > three cases! > joe > **** >> >> It seems that the latter one has far fewer instructions in its >> instruction trace table, and in many cases (such as the UTF8_to_UTF32 >> converter) is small enough to entirely fit within cache. >> >> Although you have convinced me that one can not be sure of the actual >> relative performance without actual benchmark testing, I am still going >> with the last option as the best choice. Others can feel free to >> benchmark against this choice when I complete this code next week. > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm |