[Freeciv-Dev] Re: (PR#4718) topology cleanup for client autocenter code

["rwetmore@xxxxxxxxxxxx" <rwetmore@xxxxxxxxxxxx>]

Jason Short wrote:
> [rwetmore@xxxxxxxxxxxx - Sun Aug  3 06:14:47 2003]:
[...]
>>It is the case that (xm + ym) will always cover the full map, while
>>the
>>MAX of either one will fail in iso-native topologies. The sum is also
>>more efficient than the compare, and one should never write bad code
>>when
>>good is trivially available.
> 
> This is the case, 

You should have stopped here ... :-)

 > but it's a hack to hard-code it in this code.  The

Less of a hack than the MAX() stuff that as you said fails to handle things
correctly in the set of known topologies. At least use a hack that gets it
right for now.

But I have a sneaking suspicion that a bounding box limit which is what you
keep trying to remove now, will actually suffice for most forseeable
topologies, and make not turn out to be such a hack as you rashly assume.

> original patch had a map_std_xsize() and map_std_ysize() functions that
> returns the dimensions of the map in "map" coordinates - this is exactly
> what your code does. 

I think you are hung up on the coordinates aspect. This is a single radius
parameter, not a coordinate pair and how it is calculated is largely
immaterial. You could use an arbitratily large value, except that the
bounding box is more appropriate and efficient. Step back from the trees ...

> But IMO we're better off without these functions,

Different argument, and probably wrong there too. These functions express
a concept, which when you finally find a(nother) use for it will likely
change your mind. The concept is there ... you just haven't realized its
real uses.

> since then there would be the temptation to use them and this is the
> only place that "needs" them.

Really, don't be so certain of these things all the time ... it just leads
to trouble.

> Note, "needs" is in quotations since this piece of code probably doesn't
> have to exist at all.  It's just a 4th-level backup for finding
> something to center on.

Do it right wherever it occurs ... the constant effort to justify suboptimal
coding over and over again would be effort better spent in looking for the
ways to do optimal coding that doesmn't need such propping up either now or
when it fails down the road :-).

> jason

Cheers,
RossW
=====