From: Peter Olcott on
On 5/19/2010 2:25 PM, Joseph M. Newcomer wrote:
> Nigel did a presentation of his work to our group, and pointed out that both lexing and
> parsing performance were improved by generating code. His paper concentrates on the more
> complex problem of parsing.
> joe

Now your claims are getting blurrier. The question is whether or not a
faster lexer can be constructed that does not use any sort of table when
compared to the fastest state transition matrix method.

>
> On Wed, 19 May 2010 10:47:50 -0500, Peter Olcott<NoSpam(a)OCR4Screen.com> wrote:
>
>> On 5/19/2010 10:29 AM, Joseph M. Newcomer wrote:
>>> Actually, I state *opinions* that nobody has to accept.
>>> joe
>>>
>>> On Tue, 18 May 2010 22:34:59 -0700, "Mihai N."<nmihai_year_2000(a)yahoo.com> wrote:
>>>
>>>>
>>>>> I can't accept this without direct proof.
>>>>
>>>> Yet, we are all supposed to take everything *you*
>>>> say without any proof.
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer(a)flounder.com
>>> Web: http://www.flounder.com
>>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>>
>> The evidence that you provided to show that a faster alternative existed
>> to a state transition matrix based lexer did no lexing only parsing. The
>> title of the paper pertained to parsing, not lexing.
> 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
On May 19, 3:57 pm, Peter Olcott <NoS...(a)OCR4Screen.com> wrote:

> The terms of the bet (immediately above) did not stipulate this
> requirement, are you welching on your bet?

No, it was based on the your original claim shown:

"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."

and Mr Delgado stating he will be looking forward to seeing it on the
27th:

http://groups.google.com/group/microsoft.public.vc.mfc/msg/6241ac7e99d6e169

The sucker bet is you producing this "code" in one week that reflects
your claim for a UTF-8 recognizer. What you showed is nothing an
updated image and text of an 4 years old marketing link. It can easily
be hype for a non-existing process. In fact, here is a URL to show
how easy it to make an unsubstantiated claim:

http://opensite.winserver.com/fake/unique.html

This shows you proved nothing but spill marketing hype with an output
illusion for a unproven process.

--
HLS
From: Peter Olcott on
On 5/19/2010 8:08 PM, Hector Santos wrote:
> On May 19, 3:57 pm, Peter Olcott<NoS...(a)OCR4Screen.com> wrote:
>
>> The terms of the bet (immediately above) did not stipulate this
>> requirement, are you welching on your bet?
>
> No, it was based on the your original claim shown:
>
> "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."
>
> and Mr Delgado stating he will be looking forward to seeing it on the
> 27th:
>
> http://groups.google.com/group/microsoft.public.vc.mfc/msg/6241ac7e99d6e169
>
> The sucker bet is you producing this "code" in one week that reflects
> your claim for a UTF-8 recognizer.

>>>>> I got $50 bucks on NEVER producing anything representing his claims.

The specific terms of the bet did not make these stipulations that you
are now later adding, so technically these later limitations are
invalid. I will grant some of these stipulations to you anyway.

Again I still win the bet even with these new terms making the claims
apply to a UTF-8 recognizer. I have already produced "something"
(software design) that perfectly meets the the terms of the bet
"anything" and it does represent my claims about a UTF-8 recognizer.

I will give you one more break since I already won the bet, thus can't
owe you anything no matter what. You don't have to actually pay me, and
I will not consider it to be welching unless I fail to provide the code
that I said I would provide within the timeframe that Pete Delgato said
I should provide it:

"I'll be happy to look for the code on the 27th!"


> What you showed is nothing an
> updated image and text of an 4 years old marketing link. It can easily
> be hype for a non-existing process. In fact, here is a URL to show
> how easy it to make an unsubstantiated claim:
>
> http://opensite.winserver.com/fake/unique.html
>
> This shows you proved nothing but spill marketing hype with an output
> illusion for a unproven process.
>
> --
> HLS

From: Pete Delgado on

"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote in message
news:LJadnZn7mZltOWnWnZ2dnUVZ_q2dnZ2d(a)giganews.com...
> I will give you one more break since I already won the bet, thus can't owe
> you anything no matter what. You don't have to actually pay me, and I will
> not consider it to be welching unless I fail to provide the code that I
> said I would provide within the timeframe that Pete Delgato said I should
> provide it:
>
> "I'll be happy to look for the code on the 27th!"

Peter,
*I* did not specify the timeframe, you did when you stated:

>" I just posted the complete detailed design of the UTF-8 recognizer. The
>code will follow within a week."

I merely specified the date that I would attempt to look for your code here
which allows you a full seven days to produce the code and post it.


-Pete


From: Peter Olcott on
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.