[Freeciv-Dev] Re: Map coordinate cleanups.

[Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>]

 --- Gaute B Strokkenes <gs234@xxxxxxxxx> wrote:
> 
> You have basically understood everything.  The only thing that I have
> to add is this: normalization is independent of realness.

I think it's just matter of definition.

But since so many people disagree with your naming, may I suggest that
you descend to our requests (after all, we are probably all
non-mathematical laymen not being able to tell the difference between
"if" and "iff" :) and rename your macros as Jason suggested:

IS_WRAPPED = wrapping rules applied but not necessarily real
IS_NORM(ALIZED) = real + wrapped

It's also better in the sense that distinction between the words wrapped
and normal is more obvious than between normal and proper.


Anyway, rejoice since you MAP has produced core on my computer!! ;)
I was loading a game and it faulted because in
http://www.freeciv.org/lxr/source/client/tilespec.c?v=cvs#L1533
there is explicit shift in cardinal direction without any checks passed
on to tile_is_known function.  I don't know what is the best way to fix
it, but maybe tile_is_known should be fixed to return "unknown" for
nonreal tiles?


Best,
G.




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


____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie