[Freeciv-Dev] Re: Map coordinate cleanups.

[Gaute B Strokkenes <gs234@xxxxxxxxx>]

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.

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?

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.]

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.

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.

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.

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
How do I get HOME?