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: Hector Santos on 21 May 2010 13:30 > On 5/20/2010 12:49 PM, Joseph M. Newcomer wrote: >> But this is also a stupid design, because it tends to impose the >> requirement of a complete copy of the string. For someone who is >> as compulsive about performance as you are, requiring a string >> copy seems remarkably silly. Particularly because it can be >> done at ZERO cost when the file is read. But I will leave >> this complex and subtle technique as an Exercise For The Reader. Peter Olcott wrote: > No. > > void UTF8_to_UTF32(std::vector<unsigned char>& UTF8, > std::vector<unsigned int>& UTF32); You see, right there we already have a FASTER method: BOOL UTF8_to_UTF32( const BYTE &utf8, const int &utf8_size, BYTE *utf32 int *int utf32_size); You see, your problem is what you see as OPTIMAL and NOVEL is limited to your own little world so limited in competence and human process environmental conditioning. You see, experience people might even return a BOOL to be used for error conditions. You see, there is a concept called "Payoff" where people will mode the mental translations of computer automation into ways that best suits them and generally for the greater good. So while you might want to pass/return objects because that MAKES sense to you and even to others, nothing wrong with that, yet to the purest, its not even a blip (delay) in the purest thinking. It is not something to brag about. There is nothing novel about the above. Its natural, yet not exclusive to the natural formulations of ideas. Yet your mind is so limited it becomes an exercise in futility. -- HLS
From: Peter Olcott on 21 May 2010 14:04 On 5/21/2010 12:30 PM, Hector Santos wrote: > > On 5/20/2010 12:49 PM, Joseph M. Newcomer wrote: > > >> But this is also a stupid design, because it tends to impose the > >> requirement of a complete copy of the string. For someone who is > >> as compulsive about performance as you are, requiring a string > >> copy seems remarkably silly. Particularly because it can be > >> done at ZERO cost when the file is read. But I will leave > >> this complex and subtle technique as an Exercise For The Reader. > > Peter Olcott wrote: > >> No. >> >> void UTF8_to_UTF32(std::vector<unsigned char>& UTF8, > > > std::vector<unsigned int>& UTF32); > > > You see, right there we already have a FASTER method: > > BOOL UTF8_to_UTF32( > const BYTE &utf8, > const int &utf8_size, > BYTE *utf32 > int *int utf32_size); The above is incorrect, and implies a slower design. Here is my updated interface: bool UTF8_to_UTF32(const unsigned char* UTF8, std::vector<unsigned int>& UTF32); Joe pointed out that the canonical form of this interface would require that the UTF8 string be NULL terminated. I took this to mean that the absence of a NULL terminator would be construed as an error. These things enable the NULL terminator to be the sentinel indicating OutOfData. This eliminates the need to check at every byte: "Am I done yet?" bool UTF8_to_UTF32(const std::string& UTF8, std::vector<unsigned int>& UTF32); With this interface the c_str() member function always provides the NULL termination byte. I can always completely eliminate the possibility of any memory leaks by using the simple heuristic of simply never ever allocating any memory myself. > > You see, your problem is what you see as OPTIMAL and NOVEL is limited to > your own little world so limited in competence and human process > environmental conditioning. > > You see, experience people might even return a BOOL to be used for error > conditions. > > You see, there is a concept called "Payoff" where people will mode the > mental translations of computer automation into ways that best suits > them and generally for the greater good. So while you might want to > pass/return objects because that MAKES sense to you and even to others, > nothing wrong with that, yet to the purest, its not even a blip (delay) > in the purest thinking. It is not something to brag about. > > There is nothing novel about the above. Its natural, yet not exclusive > to the natural formulations of ideas. Yet your mind is so limited it > becomes an exercise in futility. >
From: Peter Olcott on 21 May 2010 14:17 On 5/21/2010 12:30 PM, Hector Santos wrote: > > On 5/20/2010 12:49 PM, Joseph M. Newcomer wrote: > > >> But this is also a stupid design, because it tends to impose the > >> requirement of a complete copy of the string. For someone who is > >> as compulsive about performance as you are, requiring a string > >> copy seems remarkably silly. Particularly because it can be > >> done at ZERO cost when the file is read. But I will leave > >> this complex and subtle technique as an Exercise For The Reader. > > Peter Olcott wrote: > >> No. >> >> void UTF8_to_UTF32(std::vector<unsigned char>& UTF8, > > > std::vector<unsigned int>& UTF32); > > > You see, right there we already have a FASTER method: > > BOOL UTF8_to_UTF32( > const BYTE &utf8, > const int &utf8_size, > BYTE *utf32 > int *int utf32_size); > > You see, your problem is what you see as OPTIMAL and NOVEL is limited to > your own little world so limited in competence and human process > environmental conditioning. > > You see, experience people might even return a BOOL to be used for error > conditions. This is not the typical response of a UTF-8 to UTF-32 converter. Typically the bad byte is replaced with an error symbol and processing continues, otherwise a single bad byte can stop all processing. > > You see, there is a concept called "Payoff" where people will mode the > mental translations of computer automation into ways that best suits > them and generally for the greater good. So while you might want to > pass/return objects because that MAKES sense to you and even to others, > nothing wrong with that, yet to the purest, its not even a blip (delay) > in the purest thinking. It is not something to brag about. > > There is nothing novel about the above. Its natural, yet not exclusive > to the natural formulations of ideas. Yet your mind is so limited it > becomes an exercise in futility. >
From: Hector Santos on 21 May 2010 19:45 Peter Olcott wrote: >> You see, experience people might even return a BOOL to be used for error >> conditions. > > This is not the typical response of a UTF-8 to UTF-32 converter. > Typically the bad byte is replaced with an error symbol and processing > continues, otherwise a single bad byte can stop all processing. What credentials do you have to make such an absurd statement and state it as if it is a definitive conclusion? None! Note: My response has no direct correlation to the probability that you may have a point or even close to the existence to the possibility there is truth to what you stated, even if partial. That fact is that you have no conception of what you are talking about and therefore it needs to be completely ignored. This would be the 3rd request. You are ignoring the question. You stated you are a comp sci major. What school did you attend and what year did you graduate? -- HLS
From: Hector Santos on 21 May 2010 22:42
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? >> 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? > 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? > 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? > 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? > 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. Basically what you are admitting to that you don't understand dynamic memory operations. > 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? -- |