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

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

On Tue, Feb 25, 2003 at 05:39:08AM -0800, Jason Short wrote:
> 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.

Good to know.

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

It isn't about (0,0) vs (-1, -1) but (-1, -1) vs (-10, -10).

It is just luck that you get a real map position if you start with a
non-real one.

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

It should make the normalization before. It the code wants to pass
non-real map positions in it has to use another macro.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "At the beginning of the week, we sealed ten BSD programmers
  into a computer room with a single distribution of BSD Unix.
  Upon opening the room after seven days, we found all ten programmers 
  dead, clutching each other's throats, and thirteen new flavors of BSD."