[Freeciv-Dev] (PR#4177) Re: [freeciv-ai] Re: improve diplomat logging + bugfix

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

Per I. Mathisen wrote:
> On Tue, 6 May 2003, Gregory Berkolaiko wrote:
> 
>>>-  time_to_dest /= ut->move_rate;
>>>   time_to_dest *= (time_to_dest/2); /* No long treks, please */
>>>
>>>   /* Almost kill_desire */
>>>   want = (p_success * gain - p_failure * loss) / 100
>>>-         - SHIELD_WEIGHTING * time_to_dest;
>>>+         - SHIELD_WEIGHTING * (time_to_dest / ut->move_rate);
>>>
>>>If time_to_dest is == ut->move_rate, the penalty for long treks is never
>>>applied, leading to ballooning want in this case.
>>
>>You logic escapes me.
>>
>>If
>>      time_to_dest is == ut->move_rate
>>it means the diplomat can reach the city in one move. So it's nice and
>>convenient to bribe. Why is it any worse than any other city which we
>>can reach in one move?
> 
> 
> It isn't so much about ttd == move_rate, but rounding the results too
> early. A penalty which was meant to be there didn't kick in.

But this isn't just a rounding issue.  Your code gives a different 
equation than the original code - it's O(time_to_dest^2 / move_rate) 
rather than O((time_to_dest / move_rate) ^ 2).  Originally I thought 
this was what you were trying to fix, but now I see that Greg is right - 
the original code was correct, and your code is wrong.  Probably very wrong.

Upon further review, the original code is quite wrong as well; you've 
hinted at one of the reasons: if time_to_dest == move_rate, then after 
the initial calculations it (time_to_dest) will be changed to 0.  So not 
only will you not have the "long trek" penalty but there is no distance 
penalty at all.  One possible fix is

   time_to_dest /= ut->move_rate;
   time_to_dest *= (time_to_dest + 1) / 2; /* No long treks, please */

but this is assuming the original method of calculation was in any way 
useful, which I'm not convinced of...

jason