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

[Jason Dorje Short <vze49r5w@xxxxxxxxxxx>]

Ross Wetmore wrote:
> Raimar Falke wrote:
>
> > On Tue, Apr 08, 2003 at 11:03:59PM -0500, Jason Dorje Short wrote:
> >
> > > Raimar Falke wrote:
> [...]
>
> > > But I think you have not thought through things fully.
> >
> > That is quite possible. I'm still trying to understand.
> >
> > > How would you implement:
> > >
> > >  - square_map_iterate
>
> You decide what you want square_map_iterate to do. With the "map"
> in the name I presume you want this to run in map coordinates, and
> thus it would be a local 3x3 square just like it is now. This makes
> it compatible with adjacent_iterate when you need the center. In an
> iso view this would appear as a rhomboid or diamond shape, i.e. a
> square rotated pi/4.
Note, there is no "map" in the current square_iterate.

Really, at this point we don't decide what square_iterate should do - we 
accomodate square_iterate for what its users do.  All of its users want 
square_map_iterate.
> But if you want a block_iterate for dealing with rectangles oriented
> along the natural map axes as in defining the polar regions of the
> map, or something that iterated over a region of constant radius with
> efficient wrapping across map edges, you would do it in native coordinates
> and probably call it (block/square)_native_iterate().
Hmm, here we get into deeper concepts and run into problems...

This is a point I've always been confused on.  Why does your 
block_iterate orient itself natively?  Shouldn't it be 
native_block_iterate or some such?  Isn't a native block a basically 
useless concept?  I can (vaguely) imagine a use for a 
natural_block_iterate, this has _some_ local use.  But when (outside of 
global operations which should use whole_map_iterate) would one ever use 
a native_block_iterate?
> The important thing to remember is that many operations are muddled
> in the current code which was never written to deal with general
> topologies, just a simple rectangular map window where the same
> coordinates are the right ones for multiple contexts.
This is, by definition, going to be true.  Up until now native, natural, 
and map coordinates are all the same.  With iso-maps we introduce 
(separate) native coordinates.  Of course most users won't have thought 
about which coordinate system they are using!
If we later refine/redefine the coordinate systems, we will find 
ourselves in a similar situation.
> But even true isometric which changes the orientation of the natural
> map axes to be pi/4 rotated wrt the internal standard map ones starts
> to break down some of these symmetries and thus requires you to think
> about the real context in each case. map_view complexities with all
> kinds of ugly special case code are the result of doing things in one
> coordinate system which happens to be the wrong one in half the cases.
> Note, *only* map_view is ugly now because the current code does not
> handle true isometric maps, and only provides an iso view of a
> standard rectngular map.
Hmm, upon further review I think mapview issues are more complicated 
because they deal with both local and global concepts.  Thus neither map 
(local) nor native (global) concepts will entirely satisfy them.
> In most spots updates to generalize the core code involve trivial code
> changes.
Yes, so long as we choose an appropriate coordinate system.

> What native does is provide an easy context for the global operations,
> while internal map coordinates deal with local ones. Most of the inner
> code is of the local variety so most of this code is never touched. The
> outer loops often contain a global iteration, and thus you loop in
> native coordinates and provide a conversion at the top of the loop
> to map coordinates. Since the global loop in the current code is
> equivalent to native for its limited topologies, the actual code
> doesn't change except to rename the loop variables and provide the
> conversion line. Once you have done this, you have genralized the
> core and all topologies just work.
This passage is very good.  It may take upon new meaning after 
considering the mapview situation (see above).
> [...]
>
> > > it's not just a question of how many places need to be touched, but 
> > > of how difficult/ugly/unmaintainable the new code will be.
>
> The code is actually simpler using native coordinates where they are
> best and map coordinates where they are best - by definition really.
Well, yes.

The thing is, most pieces of code don't do *anything* with the 
coordinates - they just pass them off from one operation to another.  So 
the question is, what coordinate system should the interfaces for all 
functions use?  Raimar is (I think) suggesting that they should use 
native coordinates, and convert to map coordinates when necessary.  But 
our implementation (which involves fewer changes, but may not 
necessarily be "better") is that they use map coordinates.
My only answer is that we should use map coordinates for now, since they 
are much easier - we may consider switching later.
> [...]
>
> > Also I think that in my idea I want to make your native coordinates
> > the "normal" "map" coordinates.
"map coordinates" is the name Ross and I have used for the tile-oriented 
coordinate system.  The coordinates that are 
stored/passed-around-between-functions I would call "standard coordinates".
jason