Clear coding ?

[Roger Brown]

The better solution is in (1), but he does not like it and he will show you his prefered (2), then he breaks it in (3) then asks for better solution in (4).
So we go on circles here. I recommend (1), he likes (2) he breaks it in (3) and ask in (4), you recommend (1), he likes (2) ... We go on infinite loop .
He probably has some problems and needs some help.

Hello Ferdinand,

And he seems to give your post weight with his latest offering.

I will have a look at it.

Later.

[hgm]

Note that 'trolling' is not a term defined in the charter, and, in the meaning apparently used by Marco, does not seem to violate the charter.

Once a member gains access to the message board, he may read all messages and post new or response messages with the proviso that these new or response messages:

1. Are, within reason, on the topic of computer chess
2. Are not abusive in nature
3. Do not contain personal and/or libelous attacks on others
4. Are not flagrant commercial exhortations
5. Are not of questionable legal status.

In this particular thread the only thing Henk could be accused of is "off-topic posting" per (1), as he posts about a general programming issue rather than a something specific for Chess programming. This in itself doesn't seem very harmful, however, and as long as such topics would not start to dominate this forum section, I don't think that would annoy many readers. Many other respected forum members do this occasionally too.

It is true that Henk often posts remarks or claims that seem intentionally designed to be just on the wrong side of being correct in a sort of not-too-bright way, which beg to be withspoken. This could be considered trolling, but in an innocent way, as it does not invite personal attacks. This often provides a good handle for me to make a point however. The simplicio-academician dialogue is a time-tested style of teaching, and if Henk wants to take the role of simplico, that is fine with me.

I can add that many of Henk's post seem to be intended as jokes, and that Henk has a very special brand of humor, and often seems very bored. Those with no sense for humor at all stand the risk to be highly annoyed by such posts.

[Roger Brown]

Note that 'trolling' is not a term defined in the charter, and, in the meaning apparently used by Marco, does not seem to violate the charter.

Once a member gains access to the message board, he may read all messages and post new or response messages with the proviso that these new or response messages:

1. Are, within reason, on the topic of computer chess
2. Are not abusive in nature
3. Do not contain personal and/or libelous attacks on others
4. Are not flagrant commercial exhortations
5. Are not of questionable legal status.

In this particular thread the only thing Henk could be accused of is "off-topic posting" per (1), as he posts about a general programming issue rather than a something specific for Chess programming. This in itself doesn't seem very harmful, however, and as long as such topics would not start to dominate this forum section, I don't think that would annoy many readers. Many other respected forum members do this occasionally too.

It is true that Henk often posts remarks or claims that seem intentionally designed to be just on the wrong side of being correct in a sort of not-too-bright way, which beg to be withspoken. This could be considered trolling, but in an innocent way, as it does not invite personal attacks. This often provides a good handle for me to make a point however. The simplicio-academician dialogue is a time-tested style of teaching, and if Henk wants to take the role of simplico, that is fine with me.

I can add that many of Henk's post seem to be intended as jokes, and that Henk has a very special brand of humor, and often seems very bored. Those with no sense for humor at all stand the risk to be highly annoyed by such posts.

Hello HG,

I have already noted that Henk engages you and Dr. Hyatt and apparently, with useful results, as far as you are concerned.

Are you sure that there is not some of the Socratic methodology here as well?

I clearly have more than one perspective to consider.

Your comment about the humourlessness of some is noted.

Perhaps there could be less irritation applied to their sensitivities and then the complaints would decrease?

Later.

[hgm]

I forgot to add that there often is a disappointing lack of real activity in this forum, which tends to 'force' regular visitors to open Henk's threads for lack of alternatives, even when they could know by experience that the content will probably not be very much to their liking. This seems a much more serious problem than the presence of Henk's postings.

[mar]

I can add that many of Henk's post seem to be intended as jokes, and that Henk has a very special brand of humor, and often seems very bored. Those with no sense for humor at all stand the risk to be highly annoyed by such posts.

Well I guess that sense for humor depends on taste.
So while I prefer "Monty Python" style over "Dumb and Dumber", I wouldn't say that others lack sense for humor, I would say that they lack taste.

[bob]

Functions compose well. Free or global variables usually cause problems.

Unfortunately you will always have global variables if you use threads, if you want the search to be anything even close to reasonably efficient...

I don't know if a twenty times slower transposition table will become the main computational bottleneck during normal move search otherwise using balanced trees might become an option.

It HAS to be fast. It HAS to be hashed, not searched.

If it has to be fast then functional programming fails for there is no fast

functional implementation for a transposition table.

I don't follow. Hashing is a direct probe into memory. That would seem to be as "functional friendly" as possible. The recursive search certainly represents a problem...

[Henk]

Functions compose well. Free or global variables usually cause problems.

Unfortunately you will always have global variables if you use threads, if you want the search to be anything even close to reasonably efficient...

I don't know if a twenty times slower transposition table will become the main computational bottleneck during normal move search otherwise using balanced trees might become an option.

It HAS to be fast. It HAS to be hashed, not searched.

If it has to be fast then functional programming fails for there is no fast

functional implementation for a transposition table.

I don't follow. Hashing is a direct probe into memory. That would seem to be as "functional friendly" as possible. The recursive search certainly represents a problem...

It's about creating a new transposition table using an immutable one. So
nextImmutableTTable = Insert (prevImmutableTTable, entry);

I don't know it that can be implemented more efficiently than O(log n) otherwise we get Insert(/*mutable*/ TTable, entry)

[flok]

I don't think Henk is a trol. He wrote a chess engine that plays valid moves. I know because I saw my program play against his twice via hgm's server. Ok that is not 100% guarantee.

You may think his question is silly but hey haven't we all asked a "silly" question in our lifetimes?

I also think it is not very nice to have this discussion.

[Roger Brown]

I don't think Henk is a trol. He wrote a chess engine that plays valid moves. I know because I saw my program play against his twice via hgm's server. Ok that is not 100% guarantee.

You may think his question is silly but hey haven't we all asked a "silly" question in our lifetimes?

I also think it is not very nice to have this discussion.

Hello Folkert,

Agreed.

Some of that is on me and I take full responsibility.

I was asked a question on an issue and I sought to explain why there was not necessarily one perspective on a thread or post.

I consider the public discussion on the person of the member closed.

Later.

[Henk]

Functions compose well. Free or global variables usually cause problems.

Unfortunately you will always have global variables if you use threads, if you want the search to be anything even close to reasonably efficient...

I don't know if a twenty times slower transposition table will become the main computational bottleneck during normal move search otherwise using balanced trees might become an option.

It HAS to be fast. It HAS to be hashed, not searched.

If it has to be fast then functional programming fails for there is no fast

functional implementation for a transposition table.

I don't follow. Hashing is a direct probe into memory. That would seem to be as "functional friendly" as possible. The recursive search certainly represents a problem...

It's about creating a new transposition table using an immutable one. So
nextImmutableTTable = Insert (prevImmutableTTable, entry);

I don't know it that can be implemented more efficiently than O(log n) otherwise we get Insert(/*mutable*/ TTable, entry)

Of course the naming is wrong: it should be something like
nextTTable = Insert(currentTTable, TTableEntry). It is not a doubly linked list or so.