Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Map coordinate cleanups.
Home

[Freeciv-Dev] Re: Map coordinate cleanups.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: rf13@xxxxxxxxxxxxxxxxxxxxxx
Cc: Jason Dorje Short <jshort@xxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Map coordinate cleanups.
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Fri, 17 Aug 2001 09:47:02 -0400

Yes!!!

I think you've got it all. Except that the "All methods ..." part is still
a goal or TODO in some cases.

Now lets make sure everyone is at the same level.

Cheers,
RossW

At 12:11 PM 01/08/17 +0200, Raimar Falke wrote:
>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)
>
>



[Prev in Thread] Current Thread [Next in Thread]