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 21 May 2010 23:50 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. > >>> There is no way passing OBJECTS as you have it if faster then the >>> primitive functional prototype. Not only is your proloque and epilogue >>> is different but the internal block translations contain higher overhead >>> elements. >> >> As I initially said my design is the fastest design. > > > Design? You mean conceptually design it in your mind FASTER than another > possible design or that it RUNS faster than any other implementation? > >> I specifically said that the encoding won't be the fastest encoding. > > > So how is your DESIGN faster than than another other? 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. > >> The point is not to look at nanoseconds. The point is to look at factors > > > such as twice as fast or ten times faster. > > Thats your silly nonsense point. Not any other person. > > > There is no sense making code 1/10000% faster > >> by adopting bad style. > > > What bad style? > > > The initial function call overhead on something > > like this is amortized over the function body execution time. > > 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. > >> If you give up doing memory allocation yourself, then you also give up >> the possibility of user generated memory leaks. > > > 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. > >> Because of this I generally consider dynamic memory allocation to be >> bad style. > > > 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. > >> I don't think that there was every a time when I ever had to > > > do dynamic memory allocation, > > 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! > > 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. http://en.wikipedia.org/wiki/Edsger_W._Dijkstra > > except when I implemented my own std::string and std::vector. > > I see, and of course, it turn out faster than anything else > > 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.
From: Hector Santos on 22 May 2010 00:54 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: Oliver Regenfelder on 22 May 2010 04:45 Hello, Peter Olcott wrote: >> BOOL UTF8_to_UTF32( >> const BYTE &utf8, >> const int &utf8_size, >> BYTE *utf32 >> int *int utf32_size); BOOL UTF8_to_UTF32(const BYTE &utf8, size_t utf8_size, BYTE *utf32, size_t *utf32_size); I would exchange the int for size_t, as this is the proper type for indexing arrays. Also then your application will not come into troubles on 64 bit systems with BIG UTF8 data. <sarcasm> I know that on most systems you are not handling 2GByte big strings. But as his routines will be the fastest ever they might be especially usefull on big strings. </sarcasm> Best regards, Oliver
From: Joseph M. Newcomer on 22 May 2010 05:50 See below... On Fri, 21 May 2010 22:50:40 -0500, Peter Olcott <NoSpam(a)OCR4Screen.com> 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. > >> >>>> There is no way passing OBJECTS as you have it if faster then the >>>> primitive functional prototype. Not only is your proloque and epilogue >>>> is different but the internal block translations contain higher overhead >>>> elements. >>> >>> As I initially said my design is the fastest design. >> >> >> Design? You mean conceptually design it in your mind FASTER than another >> possible design or that it RUNS faster than any other implementation? >> >>> I specifically said that the encoding won't be the fastest encoding. >> >> >> So how is your DESIGN faster than than another other? > >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 **** > >> >>> The point is not to look at nanoseconds. The point is to look at factors >> >> > such as twice as fast or ten times faster. >> >> Thats your silly nonsense point. Not any other person. >> >> > There is no sense making code 1/10000% faster >> >>> by adopting bad style. >> >> >> What bad style? >> >> > The initial function call overhead on something >> > like this is amortized over the function body execution time. >> >> 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. > >> >>> If you give up doing memory allocation yourself, then you also give up >>> the possibility of user generated memory leaks. >> >> >> 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. > >> >>> Because of this I generally consider dynamic memory allocation to be >>> bad style. >> >> >> 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. > >> >>> I don't think that there was every a time when I ever had to >> >> > do dynamic memory allocation, >> >> 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! > >> >> 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. > > http://en.wikipedia.org/wiki/Edsger_W._Dijkstra > >> > except when I implemented my own std::string and std::vector. >> >> I see, and of course, it turn out faster than anything else >> >> 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. 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 22 May 2010 07:19
Besides taking into account your note, the whole point is that using std:vector or any object for that matter would not produce the most optimized, fastest model. So that point alone breaks his claim. If one is going to be anal about switches, if statements, tables, etc, you have to be anal about the functional prototyping as well. Ideally, at least how I do things, one function would be the primitive of the other, i.e, overloads, etc. -- HLS Oliver Regenfelder wrote: > Hello, > > Peter Olcott wrote: >>> BOOL UTF8_to_UTF32( >>> const BYTE &utf8, >>> const int &utf8_size, >>> BYTE *utf32 >>> int *int utf32_size); > > BOOL UTF8_to_UTF32(const BYTE &utf8, size_t utf8_size, BYTE *utf32, > size_t *utf32_size); > > I would exchange the int for size_t, as this is the proper type for > indexing > arrays. Also then your application will not come into troubles on 64 bit > systems > with BIG UTF8 data. > > <sarcasm> > I know that on most systems you are not > handling 2GByte big strings. But as his routines will be the fastest ever > they might be especially usefull on big strings. > </sarcasm> > > Best regards, > > Oliver |