[Freeciv-Dev] Re: Map coordinate cleanups.

[Jason Dorje Short <jshort@xxxxxxxxxxxxx>]

If you don't want to read the whole thing, at least skip down to the
end.

Gaute B Strokkenes wrote:

> You have basically understood everything.  The only thing that I have
> to add is this: normalization is independent of realness.

Wrapping is independent of realness.  You define "normalized" to mean
"canonically wrapped" which is also independent of realness.  We define
"normalized" to mean "wrapped and real", which is certainly not
independent of realness.

For the rest of this discussion, I'll use the term "wrap".  It means the
same thing as your term "normalize", but not the same as our term
"normalize".  "Wrapped" means "canonically wrapped".  Rather than use
"normal" or "normalized" as I was before, I'll say "wrapped and real".

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

As someone already pointed out, they are not different tiles - neither
of them are tiles at all.  Logically, the should both be caught by
is_real_tile and treated identically.  Under the current tile system,
both would point to void_tile.

> 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?

There is no reason to "restrict" wrapping of coordinates to real tiles. 
However, any attempt to wrap non-real tiles may give useless values. 
Consider the case of an orthogonal map (cylinder topology).  Trying to
wrap non-real coordinates will give coordinates that will take lots of
code just to decipher.  It's not _useful_, since every non-real
coordinate should be treated identically.  Anything different is a bug.

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

I believe my definition of "normal" and "normalize" has just as much
mathematical validity as yours.

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

"Pleasing" and "real" are not the same thing.  You gave the example of
normalizing a vector - but vectors don't generally have the problem of
having invalid values.  How would you normalize the vector (0, 0)?

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

I don't draw a distinction between "normal" and "normalized".  I say it
defines "normal[ized]" as "wrapped and real" because of the exact
reasons you gave.  I doubt the original author gave much thought to the
issue, but that's certainly the way things are treated right now.

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

There is no guarantee that non-real coordinates will be wrappable at
all, and even less guarantee that they will have useful "canonical"
wrapping positions.  Trying to enforce wrapping of non-real tiles is IMO
artificial.  The correct solution is to just treat all non-real tiles
identically.

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

I think we may have unresolvable differences here.  I believe
correctness calls for making no assumptions whatsoever about unreal
tiles.


However, my more immediate concern is with naming.  No matter what you
may think about "correct" names, I think you'll agree that "normalized"
and "proper" will be very confusing to the typical programmer.  I
suggest that we use the term "wrapped" to mean "canonically wrapped"
from here on, and pick one of "normal", "normalized", "proper", etc. to
mean "wrapped and real".

jason