Conversion from UTF32 to UTF8 for review
in [MFC]
|
From: Peter Olcott on 4 Jun 2010 13:30 On 6/4/2010 11:27 AM, Joseph M. Newcomer wrote: > My code is always perfect as written, except for a few bugs I have to fix. But if I > define "perfection" as "almost right" I win, every time. > joe http://www.ocr4screen.com/UTF8.h http://www.ocr4screen.com/Array2D.h In any case, not wanting to mince words the current code has in my opinion the optimal balance between performance, reliability and maintainability. The alternative 2-3 fold faster code kept crashing. > > On Thu, 3 Jun 2010 13:46:31 -0400, "Pete Delgado"<Peter.Delgado(a)NoSpam.com> wrote: > >> >> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote in message >> news:sfSdnTGTyIk3UJvRnZ2dnUVZ_uSdnZ2d(a)giganews.com... >>> On 6/2/2010 2:57 PM, Pete Delgado wrote: >>>> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote in message >>>> news:qbednWXw38bMkJjRnZ2dnUVZ_jidnZ2d(a)giganews.com... >>>>> >>>>> Since no one else here thinks that my code is anything like abysmal that >>>>> shows that there is something else going on besides an objective >>>>> assessment of the quality of my code. >>>> >>>> I think that it would be a mistake on your part to assume that the >>>> quality >>>> of your code is not suspect just because you have not gotten an abundance >>>> of >>>> posts stating that fact. You have already demonstrated an extraordinary >>>> lack >>>> of receptiveness to constructive criticism, so why would any of us >>>> continue >>>> to beat our heads against the wall? >>>> >>>> -Pete >>>> >>>> >>> After correcting three typos it worked correctly the first time. This is >>> the most objective measure of quality. >> >> The above statement is demonstrably false unless one has a very loose >> definition of "worked correctly". Perhaps you mean to say that it worked "as >> intended" with the inclusion of infinite loops, but saying that it worked >> "correctly" is simply a falsehood since the original code did not do what >> you had suggested that it would do. >> >> In addition, you have already given us your standards of code quality, none >> of which your code seems to meet, so it appears that rather than "fix" your >> code, you have "fixed" your quality metrics. >> >> I suppose that I am being rather generous since it appears to me that this >> really was not "your code" at all, but rather a derived work from someone >> else. This makes it all the more humorous because you have placed a >> copyright on the code! >> >> -Pete >> > 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 7 Jun 2010 12:36 Factor-of-two slower? That doesn't even make it vaguely competitive! Now, if you were 10% FASTER, that would be interesting! Note that code that is designed for performance is not necessarily "more readable". But you cannot claim something is a factor of 10 "easier to fully understand" because there is no quantitative metric of what constitutes "easier to fully understand". So comparing performance (an objective property, which can be measured) to some ill-defined concept like "easier to read" is a meaningless comparison. While we can teach the "art" of programming and include certain qualities of "readability" or "maintainability", they are at best aesthetic judgments, not subject to objective measures. joe On Wed, 02 Jun 2010 22:44:52 -0500, Peter Olcott <NoSpam(a)OCR4Screen.com> wrote: >On 6/2/2010 6:26 PM, Liviu wrote: >> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote... >>> On 6/2/2010 4:58 PM, Peter Olcott wrote: >>>> On 6/2/2010 4:40 PM, Joseph M. Newcomer wrote: >>>>> **** > >> By the way, did you fix the validation bug still present in the latest >> code you submitted in the other thread? >> >This is the ballpark of my final production code: > http://www.ocr4screen.com/UTF8.h > >It is only about half as fast as the tightly written "C" code that >Hector posted a link to: > http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ > >I would estimate that it is about ten-fold easier to fully understand my >design than it is to completely understand the alternative, >(your mileage may vary). > >I have found that maximum readability tends to lead to maximum reliability. 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 7 Jun 2010 16:26 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:6o7q06djgqoeh6j1ii9gbd969j21ufh8dn(a)4ax.com... > Factor-of-two slower? That doesn't even make it vaguely > competitive! > > Now, if you were 10% FASTER, that would be interesting! > > Note that code that is designed for performance is not > necessarily "more readable". > > But you cannot claim something is a factor of 10 "easier > to fully understand" because > there is no quantitative metric of what constitutes > "easier to fully understand". So > comparing performance (an objective property, which can be > measured) to some ill-defined > concept like "easier to read" is a meaningless comparison. > While we can teach the "art" > of programming and include certain qualities of > "readability" or "maintainability", they > are at best aesthetic judgments, not subject to objective > measures. > joe What about the fact that it is easier to read makes it more reliable such that it does not crash like the alternative faster version? Twice the speed and crashing is much less quality than never crashing everything else being the same. Also I would not be so sure that no objective measure or readability does not exist. I have been speaking on the software engineering forum, and quantified and even automated measures of complexity already exist. > > On Wed, 02 Jun 2010 22:44:52 -0500, Peter Olcott > <NoSpam(a)OCR4Screen.com> wrote: > >>On 6/2/2010 6:26 PM, Liviu wrote: >>> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote... >>>> On 6/2/2010 4:58 PM, Peter Olcott wrote: >>>>> On 6/2/2010 4:40 PM, Joseph M. Newcomer wrote: >>>>>> **** >> >>> By the way, did you fix the validation bug still present >>> in the latest >>> code you submitted in the other thread? >>> >>This is the ballpark of my final production code: >> http://www.ocr4screen.com/UTF8.h >> >>It is only about half as fast as the tightly written "C" >>code that >>Hector posted a link to: >> http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ >> >>I would estimate that it is about ten-fold easier to fully >>understand my >>design than it is to completely understand the >>alternative, >>(your mileage may vary). >> >>I have found that maximum readability tends to lead to >>maximum reliability. > 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 7 Jun 2010 16:46 On 6/7/2010 11:36 AM, Joseph M. Newcomer wrote: > Factor-of-two slower? That doesn't even make it vaguely competitive! > > Now, if you were 10% FASTER, that would be interesting! > > Note that code that is designed for performance is not necessarily "more readable". > > But you cannot claim something is a factor of 10 "easier to fully understand" because > there is no quantitative metric of what constitutes "easier to fully understand". So The specific quantified measure that I had in mind was the difference in the amount of time that it would take a representative sample of C++ developers to attain 100% comprehension of exactly how the code worked. The 10-fold difference was my estimate of this difference. > comparing performance (an objective property, which can be measured) to some ill-defined > concept like "easier to read" is a meaningless comparison. While we can teach the "art" > of programming and include certain qualities of "readability" or "maintainability", they > are at best aesthetic judgments, not subject to objective measures. > joe > > On Wed, 02 Jun 2010 22:44:52 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote: > >> On 6/2/2010 6:26 PM, Liviu wrote: >>> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote... >>>> On 6/2/2010 4:58 PM, Peter Olcott wrote: >>>>> On 6/2/2010 4:40 PM, Joseph M. Newcomer wrote: >>>>>> **** >> >>> By the way, did you fix the validation bug still present in the latest >>> code you submitted in the other thread? >>> >> This is the ballpark of my final production code: >> http://www.ocr4screen.com/UTF8.h >> >> It is only about half as fast as the tightly written "C" code that >> Hector posted a link to: >> http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ >> >> I would estimate that it is about ten-fold easier to fully understand my >> design than it is to completely understand the alternative, >> (your mileage may vary). >> >> I have found that maximum readability tends to lead to maximum reliability. > 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 8 Jun 2010 12:25
See below... On Mon, 7 Jun 2010 15:26:23 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:6o7q06djgqoeh6j1ii9gbd969j21ufh8dn(a)4ax.com... >> Factor-of-two slower? That doesn't even make it vaguely >> competitive! >> >> Now, if you were 10% FASTER, that would be interesting! >> >> Note that code that is designed for performance is not >> necessarily "more readable". >> >> But you cannot claim something is a factor of 10 "easier >> to fully understand" because >> there is no quantitative metric of what constitutes >> "easier to fully understand". So >> comparing performance (an objective property, which can be >> measured) to some ill-defined >> concept like "easier to read" is a meaningless comparison. >> While we can teach the "art" >> of programming and include certain qualities of >> "readability" or "maintainability", they >> are at best aesthetic judgments, not subject to objective >> measures. >> joe > >What about the fact that it is easier to read makes it more >reliable such that it does not crash like the alternative >faster version? *** A faster version that crashes is not useful. But you did not describe why it failed, so there is no way to tell what went wrong. **** >Twice the speed and crashing is much less quality than never >crashing everything else being the same. *** I agree. I used to call this "The Unix quality standard", which translates as "it doesn't matter if it is correct, as long as it is smaller and faster". But we don't know why it crashed; if you retyped it, there could be a typo in the code. So I'd be inclined to figure out why the faster one failed and fix that. **** > >Also I would not be so sure that no objective measure or >readability does not exist. I have been speaking on the >software engineering forum, and quantified and even >automated measures of complexity already exist. **** Back in the 1980s, we were seeing people start to worry about these issues. By the mid-1990s, the metrics were highly debated. I have not looked at this problem since the late 1990s, so if you have some references, it would be useful to give us some pointers so we can see what has been happening in this area. joe **** > >> >> On Wed, 02 Jun 2010 22:44:52 -0500, Peter Olcott >> <NoSpam(a)OCR4Screen.com> wrote: >> >>>On 6/2/2010 6:26 PM, Liviu wrote: >>>> "Peter Olcott"<NoSpam(a)OCR4Screen.com> wrote... >>>>> On 6/2/2010 4:58 PM, Peter Olcott wrote: >>>>>> On 6/2/2010 4:40 PM, Joseph M. Newcomer wrote: >>>>>>> **** >>> >>>> By the way, did you fix the validation bug still present >>>> in the latest >>>> code you submitted in the other thread? >>>> >>>This is the ballpark of my final production code: >>> http://www.ocr4screen.com/UTF8.h >>> >>>It is only about half as fast as the tightly written "C" >>>code that >>>Hector posted a link to: >>> http://bjoern.hoehrmann.de/utf-8/decoder/dfa/ >>> >>>I would estimate that it is about ten-fold easier to fully >>>understand my >>>design than it is to completely understand the >>>alternative, >>>(your mileage may vary). >>> >>>I have found that maximum readability tends to lead to >>>maximum reliability. >> Joseph M. Newcomer [MVP] >> email: newcomer(a)flounder.com >> Web: http://www.flounder.com >> MVP Tips: http://www.flounder.com/mvp_tips.htm > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |