[Freeciv-Dev] Re: Map coordinate cleanups.

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Aug 16, 2001 at 10:13:58PM -0400, Jason Dorje Short wrote:
> Gaute B Strokkenes wrote:
> > 
> > On Thu, 16 Aug 2001, jshort@xxxxxxxxxxxxx wrote:
> > >
> > > Are you saying there is a reason other than speed to make them
> > > macros?
> > 
> > Yes.  For one thing, this makes it feasible to put them in other
> > places where it would be silly to use a function.  A slightly cheesy
> > example would be the definition of IS_PROP_TILE(), which basically
> > IS_NORM_TILE && IS_REAL_TILE.  That would be a silly thing to write in
> > terms of functions.  A somewhat more relevant example might be the
> > adjc_dir_iterate() macro you wrote.  I added an assert() which
> > amounted to IS_PROP_TILE() to it before committing it.  This actually
> > had a measurable impact on performance, and having a function call
> > would probably make it even slower.  Doing it this way means that we
> > can use the macro there with no worries.
> 
> Um, all of those reasons are just "it is faster".  I'm not disputing
> that it's faster - I just don't really care.  Despite the
> adjc_dir_iterate macro patch I made, I really don't care about speed
> (especially when it's something a compiler *should* be able to optimize
> anyway).  I believe the macro form is uglier, and I don't look forward
> to having to replace it later to allow for orthogonal maps.  All of
> these are small issues, though, and I don't think we should argue over
> the macro/function thing any more.
> 
> > It seemed obvious to me that the phrase "normalize_map_pos" had been
> > picked because of the meaning of normal or normalized as "in the
> > preferred form" rather than the commonplace meaning as "plain,
> > ordinary" which is how you seem to be interpreting it.
> > 
> > I then picked "proper" because that is the word which is most often
> > used to exclude objects which fit the definition, but are not `nice'.
> > For instance given a set A, A is a subset of A--but it is not a proper
> > subset.
> 
> These definitions of normal/proper work just as well with my function
> names.
> 
> normal = the preferred form = anything that's on the world and wrapped
> 
> proper = the nice form = anything that's wrapped
> 
> I see this as a bigger issue than the macro one; these names will be
> around for a long time.  It would be nice to keep the current mindset
> (normal=wrapped and real), but picking names that will make sense to
> future programmers is even more important.

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? Have I forgot something?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  reality.sys corrupt. Reboot Universe? (y,n,q)