[Freeciv-Dev] Re: (PR#3936) introducing native coordinates

[Ross Wetmore <rwetmore@xxxxxxxxxxxx>]

Jason Dorje Short wrote:
> Raimar Falke wrote:
>
> > On Sun, Apr 13, 2003 at 05:37:59PM -0500, Jason Dorje Short wrote:
[...]
> > There are certain parts of the code which are topology
> > dependent. These parts are few:
> >  - neighborhood relation: can be reduced to MAPSTEP
Neighbourhood relations are basically local operations.

There is no dependency on global topology except through very specific
calls to normalize_map_pos() that handle extra wrapping/unreal checks
on the final result. If one allowed unnormalized map coordinates to be
passed around, most of these topology checks could go away leaving just
an is_real_map_pos() core. If you dropped the realness condition, even
this would go (but that is not really advisable :-).

DIR_DX/DY updates are purely local operations.

> >  - distance: is reduced to map_distance_vector
Distance is actually a local operation handled in map coordinates.

The minor tweak to this is folding wrap operations when there are multiple
equivalent points to first choose from. But the distance calculation is
still done in a local framework once the correct points are chosen.

Note, this local framework is the standard map grid that underlies all
existing topologies. Distances are scaled to its metrics.

> >  - wrapping/normalization: is reduced to normalize_map_pos
This is the general topoplogy function to handle wrapping operations
and mapping equivalent points in certain topologies.

> None of these are topology-dependent under map coordinates. 
Normalize_map_pos() is. The rest have a minor pre or post check operation
that usually uses normalize_map_pos() but are fundamentally not topology
dependent apart from this.

> So in 
> essence you are saying that these are the only parts of the code that 
> need map coordinates.  But there may be more; I'm not sure.  Certainly 
> there are some additional (non-mapview-specific) ones in mapview.
Virtually all of the current code uses map coordinates in the map vs
native sense. PathFinding for instance uses map coordinates throughout.

The original comments are just plain confused about this.

> Conversely, if we use map coordinates as standard there are just a few 
> places that need to convert to native coordinates.  These include a few 
> map.c backend functions (normalize_map_pos, map_distance_vector, 
> rand_map_pos, map_to_index_pos, index_to_map_pos) as well as a very few 
> pieces of user code (savegames, map debug output).
> >  - mapview: is reduced to one file (mapview_common) AFAIK
> Don't just lump in everything in mapview.c and mapview_common.c into 
> "mapview" and write it off.  mapview does have some very specialized 
> needs (like clipping the window), but also some generalized ones as well 
> (like rectangle_iterate).
mapview has very little to do with map or native coordinates. It mostly
deals with GUI window coordinates. It passes all its arguments around as
normalized map coordinates as this is what the doctrine currently mandates.
But apart from this and needing to go through map coordinates to get game
data it is really not much dependent on them.

> > So I propose that we change these 4 very isolated pieces of code and
> > don't confuse the general programmer with this. I'm not against doing
> > a transformation to a nicer coordinate system in these pieces of code
> > if this makes the task easier. But these "special task" coordinates
> > will never leave this functions (or file).
A very poor working assumption or rule, especially given the fallacies in
the logic that you claim leads here. One should decide such things in a
real context and not by religious fiats.

> > I'm also for defaulting to the other coordinate system (native and not
> > your new map coordinates). I think that most of the functions are
> > using these (no need to transformation for tile access). And from the
> > 4 pieces above MAPSTEP and normalize_map_pos can be done as fast as
> > the current code. And MAPSTEP and normalize_map_pos are the most
> > common of the above functions. So I think that using native
> > coordinates is a speed win.
> This is a reasonable position - using native coordinates as standard and 
> only using map coordinates for needed operations.  The question one 
> would have to answer is: how much harder is it to do this than to use 
> map coordinates as standard?
This is *not* a reasonable position, except as a possibility to be
discussed and rejected, i.e. it is reasonable to look at it, but when the
discussion reaches an appropriate level of understanding it will be found
to be the unreasonable of the two one-sized-fits-all choices.

In the native/map split, most of the usage and almost all in tight inner
loops are hardwired to map coordinates. These are also the values stored
in savegames, and sent by the network protocol. The fundamental map grid
is just too endemic to change at present. This suggestion would break
just about everything and require enormous amounts of work.

Raimar has just not yet understood the split, probably because he has not
spent any real time working in true iso coordinates or anything other than
the current standard maps where the split is conceptual and not in the
implementation.

His assumptions on which he bases the above are wrong, so the conclusions
he has reached are also invalid.

> > > > > Note, all of these are trivial if you are simply willing to do them
> > > > > in map coordinates.
> > > > Yes. But you don't have to scare people by introducing multiple
> > > > coordinates (you have scared and confused me) and if these are only
> > > > used in one function (map_distance_vector). square_iterate and MAPSTEP
> > > > can be easy done without them as outlines before.
Nobody scared you, you did that to yourself, methinks :-).

If you listen to what people are telling you and work to understand their
solutions, rather than trying to devise or push your own, it might help.
Others have spent considerably more time and effort working through a lot
of problems and details. Take advantage of their efforts to bootstrap
yourself to the same level ...

I think the main hurdle you need to get by is to learn to stop forcing
square pegs into round holes or vice versa. Yes, they will go if you
use a big enough hammer, but you will probably ruin everything around
you in the process. Analysing individual scenarios to recognize whether
they are square or round cases and making an appropriate choice is
generally far better though it may be intellectually more of a challenge.

Lots of examples are being presented to show how this works in small,
more easily understood cases. The challenge is to make the analogous
connections in the bigger picture.

> > > My original patch requested feedback on the explanation it provided 
> > > in doc/HACKING.  Perhaps we should start this discussion over, and 
> > > you can tell me what scares/confuses you.
> > While I still think that my idea should be done I will answer this
> > question. Completely missing is a "Gentle introduction to
> > iso-maps". Basics, requirements and semantics. All this that I had to
> > research by myself in the last days. Note that this is also needed for
> > my plan. But then only for the implementors of the 4 pieces of code
> > outlines above. So it is a _bit_ less required.
You should read email lists over the last 18 mos and followup on reading
suggestions in some of them. It is not like this stuff is being sprung on
anyone in an untimely hurry, or there hasn't been a lot of explanation
and previous debate of all the pertinent points :-).

> Hmm, ok.
>
> (I still don't see why you believe your method requires fewer code 
> changes.  This may be true, but there is no evidence for it.)
It is not true, and there is lots of evidence to refute Raimars beliefs
as usual. That has never shaken his convictions though or when he just
wants to dig in his heels.

> jason
Cheers,
RossW
=====