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