[Freeciv-Dev] Re: Last Email On this subject (PR#1025)

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 09:07 PM 01/10/20 -0700, Raahul Kumar wrote:
>--- "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx> wrote:
>> At 10:17 PM 01/10/19 -0700, Raahul Kumar wrote:
>> >--- "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx> wrote:
>> >> Actually I think Gregory had it right and if one followed your comments 
>> >> it is liable to confuse the situation far more in the future.
>> >
[...]
>> >> Think of it this way:
>> >> 
>> >> 1) There is a move_cost associated with a move, in this case
SINGLE_MOVE.
>> >> 
>> >> 2) You need to compute the cost to move there (i.e. to attack) but you
>> >>    are not allowed to move there, or through there to another tile.
>
>I agree with above 2 comments so far.

Actually, I think you backtrack on 1) below. Your point seems to be that
you don't think the pseudo-attack move_cost should be SINGLE_MOVE. If you
really do agree with this, then I think hell just froze over :-)

SINGLE_MOVE actually makes the most sense of all the current non-numeric
possiblities. You need a "full move" to properly attack.

It is also the case that this might be useful as an actual move cost for
things like boarding/disembarking (it's other use), or land-sea ATVs. No 
changes would be required if this latter were (later) implemented.

If you want to add a new define/enum such as MOVE_COST_ATTACK that is 
fine by me, but unnecessary IMHO.

The negative sign is the critical element telling one this is not just 
a standard warmap move cost, but rather flagged for special treatment. 
Folding this into the define/enum just hides this natural interface.
Making the code explicitly indicate this will help people not make
assumptions that this is just a normal (positive) movecost factor. To
help Gregory provided an explicit comment.

>Ross, I feel we are seperated by the English language. Both of us seem to
feel 
>we have made our point. Let me select some criteria and analyse our mutual
>arguments. If you prove by these criteria that I am wrong I will recant.
>Alternatively, if someone else reads Greg's code and feels that it is
>clear,I'll
>also admit that I'm wrong(It will definately be a snowy day in hell).
>
>Readibility - It seems to me this is the crux of our problem. I feel that
>with the current code, there is no actual link between SINGLE_MOVE_COST,
>and the negative move cost returned by the current code. I want the code
>to make this explicit. You obviously seem to agree 
>
>Quoting Ross
>
>>The fact that you can't actually move there makes the cost value irrelevant
>>since this cost is never built into subsequent moves out of this tile, and
>>the code currently tends to ignore it.
>
>So what are we arguing about? You have just agreed with my main point. Greg,
>it's up to you. This is actually not worth the amount of time the two of us
>have spent on it. There are far more important things we could be doing.

Good, now you agree with the rest of us, and we can make beautiful music 
together :-).

>1) Magic numbers(especially the number 3!!!!!) used to divide igter/3,used
for
>move cost, used for sea moving units etc without one explanation. Closely
>related, the cryptic one letter variable names. Words cannot express the
>homicidal rage I felt. That is why the my tone has not been friendly. Sorry
>about
>that. It seems to me that you want to introduce this chaos all over again,
one
>- SINGLE_MOVE_COST at a time.

There is no MAGIC_NUMBER generated here, so this has no relevance.

There is no single letter variable here, so this is irrelvant.

The fact that you don't appreciate the value of the negative sign and want
to lump it into a new "move_cost" identifier that mingles and obscures two
very different aspects in your rage at unrealted problems, is I think a poor
argument in favour of your suggestion.

MOVE_COST values are one thing - flags to or conventions of the warmp 
main algorithm another. Don't mix the two concepts.

>2) Impossible to make simple changes. The code is currently sphaggetti code.
>Make one change and it affects things everywhere. No one to date (including
>Thue) has ever given me a satisfactory explanation on the value of threshold,
>why we multiply it by 6 etc. Your way keeps this problem alive. 

More unrelated ranting, so again irrelevant to this discussion.

BTW: I agree with most of the items you target in your rants. The only 
     problem here is they just aren't relevant.

>3) The comments are actually wrong. Not misleading, not quite detailed
enough,
>but sometimes outright wrong. This does not apply solely to the AI code.

For the most part this is not Gregory's problem. Anything he does to
help given his intimacy with the code would be greatly appreciated, but
to pin things on him that are pre-exisitng issues and not really the
point of his patch is both unfair, and shows poor understanding of the
original code and Gregory's work by the person making such comments.

"Suggest" additional updates, but don't "blame" those not responsible
and your postings will generate less personal rebuttals in response.

>Yet
>again, the  two of us don't seem to parse a sentence the same way. Having the
>value of -3, people naturally assume there is a connection between
>SINGLE_MOVE_COST and the negative variant. Greg did, I did, even Raimar did.
>You are the only one it seems who finds the current way "natural".

This is new code. Though it handles the same stuff as exiting code that
uses SINGLE_MOVE.

Gregory did not replace a 3 here in the same way he replacd magic numbers 
elsewhere. And he clearly commented exactly what was meant. This is in
fact one of the main elements of his un-obscuring of a lot of the warmap
core implementation. You are missing the main element of his patch if you
still don't recognize this.

The point should be clear by now that SINGLE_MOVE is not an unreasonable
choice. Making up a new name is not particularly unreasonable either, but 
certainly not needed and certainly not justification for the sort of 
disparaging remarks used in your "suggestion".

>> There are a number of ways to look at the warmap and cost stuff. Gregory's
>> way is useful in that it highlights certain natural interfaces that yours
>> tends to obscure in this particular instance.
>> 
>
>My intent is quite the opposite. I am certain Greg's way obscures things.
Read
>my email from top to bottom.

I have. Most of it wasn't particularly useful or relevant other than to 
convey the fact that your arguments are based more on some emotionally
disturbing past experiences than useful constructive criticism :-).

But that is ok. Everyone has a right to sound off on occasion or be wrong.
The true measure is how you recover and proceed from then on. At least in
some measure you have tried to get back to the issues above. That is good.

Cheers,
RossW
=====