[Freeciv-Dev] Re: Map coordinate cleanups.

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Aug 18, 2001 at 01:52:28AM -0400, Jason Dorje Short wrote:
> If you don't want to read the whole thing, at least skip down to the
> end.

We always read all and reply only to the last paragraph ;)

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

No. IMHO there should only be "(un)real" positions and
"(un)normalized" positions. To test the normalizeness of a position it
has to be real. Wrapped just codes too much of the topology into the
name.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "The very concept of PNP is a lovely dream that simply does not translate to
  reality. The confusion of manually doing stuff is nothing compared to the
  confusion of computers trying to do stuff and getting it wrong, which they
  gleefully do with great enthusiasm." 
    -- Jinx Tigr in the SDM