Is this Regular Expression for UTF-8 Correct??
in [MFC]
|
From: Joseph M. Newcomer on 20 May 2010 13:55 See below... On Thu, 20 May 2010 11:36:33 -0500, Peter Olcott <NoSpam(a)OCR4Screen.com> wrote: >On 5/20/2010 11:17 AM, Joseph M. Newcomer wrote: >> See below... >> On Thu, 20 May 2010 09:11:32 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: >> >>>>>>>> I got $50 bucks on NEVER producing anything representing his claims. >>> >>> Those were not the terms of the bet, so when I produce proof that the >>> design (not the encoding) of my UTF-8 recognizer is the fastest possible >>> design you will owe me $100. If it is not the fastest possible design >>> then you owe me nothing. Alternatively If it works correctly and is >>> fast, but, is not the fastest possible design you will owe me $50. >> **** >> A design does not execute, so there is no such concept as a "fastest possible design". >> There can ONLY be a "fastest possible implementation". This means that the only >> expression of a design for which performance can be measured is compilable and executable >> code in a language of your choice. For example, I can implement a design which uses an >> indexed table by using a LISP ASSOC structure to do the table lookup, and it will not be a >> particularly good performance implementation of the design. A hand-tuned assembly-code >> version might give excellent performance of the same design. >> joe > >A design accurately meets the original specification of "anything" >representing my claims. **** A design can meet a specification, but a design is not executable, and therefore there is no proof that one of the many possible implementations based on the design is necessarily the fastest. The point here is that you cannot make assertions about relative performance of two programs unless you have running code that represents each of the possible implementations of the design. Only by measuring running code can you make a claim about performance. Nothing else matters. I can write a LISP implementation of your "fastest possible design" that implements that design precisely and which runs several orders of magnitude slower than the design would suggest. Yet it would meet the design precisely. joe **** 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 14:09 On 5/20/2010 12:55 PM, Joseph M. Newcomer wrote: > See below... > On Thu, 20 May 2010 11:36:33 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: > >> On 5/20/2010 11:17 AM, Joseph M. Newcomer wrote: >>> See below... >>> On Thu, 20 May 2010 09:11:32 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: >>> >>>>>>>>> I got $50 bucks on NEVER producing anything representing his claims. >>>> >>>> Those were not the terms of the bet, so when I produce proof that the >>>> design (not the encoding) of my UTF-8 recognizer is the fastest possible >>>> design you will owe me $100. If it is not the fastest possible design >>>> then you owe me nothing. Alternatively If it works correctly and is >>>> fast, but, is not the fastest possible design you will owe me $50. >>> **** >>> A design does not execute, so there is no such concept as a "fastest possible design". >>> There can ONLY be a "fastest possible implementation". This means that the only >>> expression of a design for which performance can be measured is compilable and executable >>> code in a language of your choice. For example, I can implement a design which uses an >>> indexed table by using a LISP ASSOC structure to do the table lookup, and it will not be a >>> particularly good performance implementation of the design. A hand-tuned assembly-code >>> version might give excellent performance of the same design. >>> joe >> >> A design accurately meets the original specification of "anything" >> representing my claims. > **** > A design can meet a specification, but a design is not executable, and therefore there is > no proof that one of the many possible implementations based on the design is necessarily > the fastest. The point here is that you cannot make assertions about relative performance The original bet required no proof, it was wide open only requiring "anything" representing my claims. You still have this original bet deeply quoted above. > of two programs unless you have running code that represents each of the possible > implementations of the design. Only by measuring running code can you make a claim about > performance. Nothing else matters. I can write a LISP implementation of your "fastest > possible design" that implements that design precisely and which runs several orders of > magnitude slower than the design would suggest. Yet it would meet the design precisely. > joe > **** > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Pete Delgado on 27 May 2010 13:15 "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message news:48SdnXZ-_ZPfvGnWnZ2dnUVZ_hEAAAAA(a)giganews.com... > On 5/19/2010 12:09 PM, Pete Delgado wrote: >> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote in message >> news:vOGdnfGVDviykWnWnZ2dnUVZ_rKdnZ2d(a)giganews.com... >>> On 5/19/2010 10:52 AM, Pete Delgado wrote: >>>> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote in message >>>> news:GOadnXHFWbfxbG7WnZ2dnUVZ_tqdnZ2d(a)giganews.com... >>>>> On 5/19/2010 12:34 AM, Mihai N. wrote: >>>>>> >>>>>>> I can't accept this without direct proof. >>>>>> >>>>>> Yet, we are all supposed to take everything *you* >>>>>> say without any proof. >>>>>> >>>>>> >>>>> Please cite examples of what I need to prove. So far no one asked for >>>>> any >>>>> proof. >>>> >>>> You provide no proof of your numerous performance claims. When pressed, >>>> you >>>> do cite your own flawed reasoning, but you never provide numerical, >>>> verifiable proof of working code - something Joe has asked you to do >>>> many >>>> times in the hopes that it would help you learn where your assumptions >>>> are >>>> flawed. >>> >>> I just posted the complete detailed design of the UTF-8 recognizer. The >>> code will follow within a week. The only thing that needs to be added to >>> this design is the actual code the does the translation from UTF-8 to >>> UTF-32. >> >> I'll be happy to look for the code on the 27th! >> >> -Pete >> >> > > It may before then. I learned on a prior job that it is best to under > promise and over deliver. Peter, I notice that you have not delivered on your promise and have not posted your code. The 27th was chosen because it is a day *after* the week you stated that you needed to complete the code. Have you posted the code and I have simply missed it?? -Pete
From: Peter Olcott on 27 May 2010 13:37 On 5/27/2010 12:15 PM, Pete Delgado wrote: > "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote in message > news:48SdnXZ-_ZPfvGnWnZ2dnUVZ_hEAAAAA(a)giganews.com... >> On 5/19/2010 12:09 PM, Pete Delgado wrote: >>> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote in message >>> news:vOGdnfGVDviykWnWnZ2dnUVZ_rKdnZ2d(a)giganews.com... >>>> On 5/19/2010 10:52 AM, Pete Delgado wrote: >>>>> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote in message >>>>> news:GOadnXHFWbfxbG7WnZ2dnUVZ_tqdnZ2d(a)giganews.com... >>>>>> On 5/19/2010 12:34 AM, Mihai N. wrote: >>>>>>> >>>>>>>> I can't accept this without direct proof. >>>>>>> >>>>>>> Yet, we are all supposed to take everything *you* >>>>>>> say without any proof. >>>>>>> >>>>>>> >>>>>> Please cite examples of what I need to prove. So far no one asked for >>>>>> any >>>>>> proof. >>>>> >>>>> You provide no proof of your numerous performance claims. When pressed, >>>>> you >>>>> do cite your own flawed reasoning, but you never provide numerical, >>>>> verifiable proof of working code - something Joe has asked you to do >>>>> many >>>>> times in the hopes that it would help you learn where your assumptions >>>>> are >>>>> flawed. >>>> >>>> I just posted the complete detailed design of the UTF-8 recognizer. The >>>> code will follow within a week. The only thing that needs to be added to >>>> this design is the actual code the does the translation from UTF-8 to >>>> UTF-32. >>> >>> I'll be happy to look for the code on the 27th! >>> >>> -Pete >>> >>> >> >> It may before then. I learned on a prior job that it is best to under >> promise and over deliver. > > Peter, > I notice that you have not delivered on your promise and have not posted > your code. The 27th was chosen because it is a day *after* the week you > stated that you needed to complete the code. > > Have you posted the code and I have simply missed it?? > > -Pete > > Something came up and I had to change priorities it is not quite done yet. I have been working on it every day. Hector posted some code that looked very good. It looks very well written and that it would be somewhat faster than my code. http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ When I post the link to my code you will be able to see that my priorities are a little different with the code that I write. I don't try to write the fastest possible code, I try to write the fastest possible code within the higher priority of the clearest possible code. It is very much easier to verify that my code is correct than it is to verify that the code Hector posted is correct. I would have to say that it is probably the clearest code that can be written within the higher priority of fast code.
From: Pete Delgado on 27 May 2010 14:17
"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message news:cpadnRRc3fZ6MGPWnZ2dnUVZ_gmdnZ2d(a)giganews.com... >> Peter, >> I notice that you have not delivered on your promise and have not posted >> your code. The 27th was chosen because it is a day *after* the week you >> stated that you needed to complete the code. >> >> Have you posted the code and I have simply missed it?? >> >> -Pete >> >> > > Something came up and I had to change priorities it is not quite done yet. > I have been working on it every day. Hector posted some code that looked > very good. It looks very well written and that it would be somewhat faster > than my code. > http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ > > When I post the link to my code you will be able to see that my priorities > are a little different with the code that I write. I don't try to write > the fastest possible code, I try to write the fastest possible code within > the higher priority of the clearest possible code. > > It is very much easier to verify that my code is correct than it is to > verify that the code Hector posted is correct. I would have to say that it > is probably the clearest code that can be written within the higher > priority of fast code. Peter, If you are attempting to write the clearest possible code, why do you continually obsess over the "fastest possible" when referring to algorithms and code? I think it's obvious to most here that you really don't know what your priorities really are or at least they seem to change as often as the wind blows. There is a book called "Writing Solid Code" (Microsoft Press) that is a short, easy read but very good on things like this. I suggest that you pick it up if you have time and take a look at it. In particular, there is a section where the author suggests that you write down your priorities in order to ensure that you are actually working toward your highest priorities first because some of your priorities may be mutually exclusive. PS: It looks like you owe Hector $50... ;-) -Pete |