[Freeciv-Dev] Re: Map coordinate cleanups.

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Aug 18, 2001 at 04:15:21AM +0200, Gaute B Strokkenes wrote:
> On Fri, 17 Aug 2001, hawk@xxxxxxxxxxxxxxxxxxxxxxx wrote:
> > 
> > I have to admit I haven't learned the difference between proper and
> > normal during my coding. Maybe I have used too much copy and
> > paste. I think there should be the following sets of
> > positions/tiles:
> > 
> >  A = the base set of all possible positions
> >  B = the set of real positions: a real position is a position which have
> >  directly or indirectly a tile associated with it
> >  C = the set of normalized positions: each tile has exactly one
> >  normalized position associated with it
> >  D = A minus B = the set of unreal positions
> >  E = B minis C = the set of unnormalized positions
> > 
> > B is a subset of A. C is a subset of B. Depending on the topology
> > these are subsets or proper subsets.
> > 
> > The following methods are declared:
> >  - is_real_position(p) tests if p is in B
> >  - is_normalized_position(p) tests if p is in C
> >  - p'=normalize_position(p) p must be in B, returns the normalized
> >  version of p
> > 
> > All methods should receive and accept only normalized
> > positions. Only at the generation of positions (mapgen, iterate
> > macros) should be logic which tests if the created position for
> > realness and normalize it.
> > 
> > At least for me this segmentation is easy to understand. Can this be
> > mapped into your model?
> 
> You have basically understood everything.  The only thing that I have
> to add is this: normalization is independent of realness.

Ack.

> Consider for instance, the coordinates (2, 0).  That's a real tile,
> and the coordinates are normalized.  If we go north, we arrive at
> (2, -1).  That's not a real tile.
> 
> Now supposed that we started with (2+xsize, 0) instead.  That's the
> same tile, but this time the coordinates are not normalized.  Now we
> go north again, and arrive at (2+xsize, -1).
> 
> If we accept that normalisation does not apply to non-real tile
> coordinates, then we have to accept that if we start with equivalent
> tile coordinates and perform the same steps then we will end up at
> different tiles.  To me, that's highly counterintuitive.
> 
> If we allow that normalisation applies to non-real tiles, so that
> (2-xsize, 0); (2, 0) and (2+xsize, 0) are all considered equivalent
> (but possibly non-normalised) then that paradox, and several similar
> ones, just vanish.  And, let's face it: what *good* reason is there to
> restrict normalisation to real tiles?

Ok now I understand I agree with you that normalization is independent
of realness.

> Another thing that I'd like to point out is the way that the words
> "normal" and "normalised" have been bandied about in a nearly
> synonymous manner in this discussion.  I think that's unfortunate.  If
> you say "normal", every reasonable person thinks "plain, commonplace;
> not possessed of unusual or surprising properties".  As such, anyone
> would expect a function named is_normal_tile() to behave as Jason
> proposed.  [Incidentally, my macro is called IS_NORM_TILE() and as
> such isn't covered by this.]

Ack. I don't know if the original other really meant "normal" or was
just to lazy to write normalize(d).

> However, in technical usage when we say that something is
> "normalised", we do not mean to say that it is "plain and
> unsurprising".  What we mean is that the object has been replaced by
> one with a convenient and / or pleasing _representation_, not that the
> object itself is necessarily pleasing.  I think that it's a bad idea
> to come up with our own defintion of "normalised" which does not match
> the use of that word in other technical contexts.

Ack.

> Some people have argued that the function normalize_map_pos()
> implicitly defines a category "normal" as above.  Firstly, if anything
> it defines a category called "normalised".  Secondly, the argument is
> based entirely on the return value semantics of that functions, and
> the fact that it avoids adjusting the x coordinate when the tile is
> not real.  Now, the comment in front of the function states that the
> function returns TRUE iff the tile is "valid".  I'm sure that if the
> original author meant to create some category called "normal" he would
> have used the word.  Also, the return value just happens to be what it
> has to be for a function which is obivously supposed to be an
> all-in-one solution to coordinate headaches.
> 
> Moreover, when one asks oneself the question "Are these coordinates
> canonical or not?" the natural thing to do is simply to check whether
> the coordinate is wrapped or not.  Why bring the realness of the tile
> into it at all?  It's a very artifical thing to do.

Canonical?

> Finally, if you take the attitude that it's not necessary to normalise
> the coordinates of unreal tiles then you're only going to run into
> paradoxes like the above.  One might argue that in most cases we drop
> unreal coordinates on the floor without further ado whenever we detect
> them, and that there are only a few places where we juggle them about
> on purpose.  However, that's only a (rather dubious) optimisation; I
> think correctness should come first.

Do you agree that 95% of the code should only handle with real and
normalized positions? For the remaining 5% I don't care if the code
is:

   x1=x+dx;
   y1=y+dy;
   if(!is_real_position(x1,y1))
      continue;
   normalize_position(&x1,&y1);
   return (x1 and y1);

or

   x1=x+dx;
   y1=y+dy;
   normalize_position(&x1,&y1);
   if(!is_real_position(x1,y1))
      continue;
   return (x1 and y1);

The first one looks better from a performance point of view.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "> WHY?! Isn't it better to put $(shell cat cscope.files) on the list of
  I only have a yellow belt in makefile kungfu.  These fancy gnu make things
  are relatively new to some of us..."
    -- Mark Frazer to Vassilii Khachaturov in linux-kernel