Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#3450) square_iterate and unreal positions
Home

[Freeciv-Dev] Re: (PR#3450) square_iterate and unreal positions

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: (PR#3450) square_iterate and unreal positions
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 25 Feb 2003 05:39:08 -0800
Reply-to: rt@xxxxxxxxxxxxxx

Raimar Falke wrote:
> On Mon, Feb 24, 2003 at 05:09:25PM -0800, rwetmore@xxxxxxxxxxxx wrote:
> 
>>Raimar Falke wrote:
>>
>>>On Mon, Feb 24, 2003 at 04:01:33AM -0800, Jason Short wrote:
>>>
>>>
>>>>Raimar Falke wrote:
>>>>
>>>>
>>>>>On Mon, Feb 24, 2003 at 02:44:37AM -0800, Jason Short wrote:
>>
>>[...]
>>
>>>I want to catch errors (here non-normal map positions passed to
>>>square_iterate). I want to catch the case where in
>>
>>square_iterate arguments do not need to be normalized.
> 
> 
> Only if the following holds true:
>  n(f(n(x))) == n(f(x))
> 
> n = normalize
> f = a function which changed the position. Adding (-1, -1) for example.
> 
> I have no idea if this holds true or not. In the current code or in
> all future possibilities.

This holds true for every topology that every civ game I know of 
supports or is likely to ever support :-).  It does not hold true for a 
mobius strip topology (but in that case square_iterate is the least of 
our worries; the entire enum direction8 will have to be restructured so 
that every direction is a vector, i.e., with a starting point associated 
with it).

All the topologies Ross and I have so far considered map cleanly onto a 
plane and are well-oriented.

>>But note, it is perfectly safe to do this if all that is done
>>here is to execute square iterate and no other map accesses are
>>made directly with (x,y).
>>
>>
>>>  If a non-normal map position is passed this will go unnoticed.
>>
>>square_iterate understands this and doesn't need to check its
>>arguments, only its outputs. Not noticing a non-problem is not a
>>problem.
> 
> 
> What outputs will square_iterate generate if you pass a non-real
> position in? It depends on the map position you passed in. 
> 
> (-1, -1) will generate
>  (-2, -2) non-real
>  (-2, -1) non-real
>  (-2,  0) non-normal
> 
>  (-1, -2) non-real
>  (-1, -1) non-real
>  (-1,  0) non-normal
> 
>  ( 0, -2) non-real
>  ( 0, -1) non-real
>  ( 0,  0) normal
> 
> (-10, -10) will generate only non-real positions.
> 
> So I argue that if you use square_iterate on a non-real map position
> you get random behavior. You may now argue that this randomness has a
> pattern and that square_iterate was coded to produce this pattern.

Random?  Surely square_iterate(-1,-1,2,2) isn't any more "random" than 
square_iterate(0,0,2,2).  In both cases some unreal positions get 
skipped and some non-normal ones get normalized.

>>>This is bad. 
>>
>>This is religion. It has nothing to do with correctness or
>>robustness which is all that should be of concern here..
> 
> Ok. I rephrase this to "square_iterate should be able to catch errors
> which are made by others parts of the code and not conceal the
> errors."

So again we are back to where we started...what about code that needs 
this functionality?

jason




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