[Freeciv-Dev] Re: to wrap or not to wrap?

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 01:01 AM 01/10/13 -0400, Jason Dorje Short wrote:
>"Ross W. Wetmore" wrote:
>> 
>> At 11:39 AM 01/10/10 -0400, Jason Dorje Short wrote:
>> >Raimar Falke wrote:
>> >wrap_map_pos(&x, &y) takes the vector (x, y) and physically wraps it
>> >into its proper position.  It is independent of (x, y) being real, so it
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >will only work for topologies that wrap "regularly".  However, the fact
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >that it'll work on any position or vector makes usage much simpler.
>> >
>> >For a real position, it will have identical effect to
>> >normalize_map_pos.  For an unreal position, it will wrap the coordinate
>>                                                      ^^^^^^^^^^^^^^^^^^^
>> >normally just as if it were real (which is only possible under a limited
>>  ^^^^^^^^  i.e. do bogus transformations of gaming coordinates.
>
>The transormation is not "bogus" if we define topologies as Gaute has
>proposed; i.e. such that equivalence classes of coordinates are defined
>as differing by a linear combination of given vectors.  It's a bit of a
>tautology, but if we are willing to limit our topologies in this way we
>can make the conversion a lot easier.

Unfortunately this does not work for the standard cylinder map. And it
does not allow you to decouple the wrapping in x and y to handle the
rectangular 4 set trivially.

You *cannot* wrap to a "normal" position first, then start thinking about
what restrictions you might want to put on. That is the reason why Gaute
is wrong, and why the initial Freeciv hacks to deal with unscrambling
things after the eggs were turned into omelet were so endemic and 
un-generalizable.

And all the wonderful algebraic noise is not particularly useful since
it is not applicable to the problem that needs to be dealt with here.
It clearly is just obscurring that.

>Personally, I now believe the use of wrap_map_pos (with the added
>restriction to topologies) is a good intermediate step; at least it will
>allow us to convert the code to entirely use one set of constructs
>(wrap_map_pos) before we set about a full cleanup.  The "full cleanup"
>will be very difficult.

You are wrong ... on all counts, as has Gaute been since the summer.

Think it through all the way first before you start implementing. 
Especially when you have 1) someone telling you that this is bad, 
2) a working practical implementation that handles everything fine 
at levels beyond where you are currently limiting yours to.

Just concentrate on fixing things using normalize_map_pos() which 
internally deals with any topology issues like wrap conditions for 
coordinates separately. Get Flat-earth through torus working cleanly 
and then the true isometric flavour in all these modes. This is the 
real set of problems of the moment.

After that weird diamonds and such with all kinds of limitations may
be easier to deal with because the code will be consistent and 
work through a well defined interface as a starting point.

>> >set of topologies).
>> >
>> >Like I said, it is confusing and will probably lead to misuse.
>> 
>> I don't see any real use for this. Perhaps you could give the example
>> (again if I missed it). I think it is more than confusing, I think it
>> is fundamentally wrong to think of a topology unaware 2-D wrap.
>
>Again, so long as you define the topology as always wrapping in the same
>way it is acceptable.  To use vague mathematical terms, we're taking
>advantage of linear algebra here instead of just plain set theory.

Always wrapping 2D topologies == torus. None of the other current 
flavours of rectangular coordinates including standard CIV are supported 
by this so it isn't of much real use.

Vague mathematical terms just means it is a great theory, but has no
immediate practical applicability. I have refereed enough papers for
scientific journals to recognize the argument and discussion technique :-).

>The "use" for it is that it makes cleanup of the GUI code much, much
>easier (see my previous overlong patch that allowed map wrapping in the
>opposite direction).

The GUI code is a separate issue. It deals with a very specific flat-earth 
type window object that can be thought of as floating over a game map.
And in this case the GUI coordinates are both clipped equivalently.

Note that while the game coordinates may wrap to give you the effect
of continuous scrolling in a given direction, the GUI ones never do.

The issue of transforming one set of coordinates to the other is not a
"generalized coordinate system" problem. But it is the GUI problem.

The game map coordinates are something one would like a general system
for, but it is very unlikely that the GUI and game systems will ever
be one and the same, so there are always going to be transformations
using techniques like clipping and wrapping for the specialized
transformation code.

And until you and Raimar, really internalize the concept that the GUI 
coordinates and the game coordinates are two separate systems dealing
with two fundamentally different objects, you are going to continue to 
confuse and amalgamate the two into a very broken Freeciv omelet.

>> Put another way, I can see the corresponding clip_map_pos(&x,&y) being
>> used in certain kinds of GUI operations that draw into a fixed window
>> object. This is because GUI window pixel coordinates are non-wrapped
>> in both directions. But one would never wrap such coordinates in the
>> same way.
>
>I don't understand.

Then think on it some more ...

>> Or, yet another flavour, I can see independently wrapping or clipping
>> individual coordinates as suboperations in certain specialized code that
>> knows exactly what it is doing, but I don't see use for a generalized two
>> coordinate function.
>
>Huh?  You cannot wrap coordinates individually.  

Sorry, the current code does this all over the place. Which has been
part of the current problem. And a cylinder needs to wrap in only one
of its 2 coordinates, so clearly this is also a required part of the
current Freeciv system.

But, I'll let you take this impromptu comment back ... :-)

>And any such
>"specialized code", no matter how little it is used, must go into
>map.[ch] so that it can be easily adjusted to handle alternate
>topologies (case in point: nearest_real_pos).

Specialized code goes where specialized code needs to go. By definition
it is not general and so your concern for trying to make it fit
general topologies is admirable but misplaced. 

To make this easier for you to swallow, specialized code might be a 
"subclass" that handled a particular specific topology. Only the class 
interface needs to be in map.h.

>jason

You are getting there. I don't mean to dampen your enthusiasm, but you 
aren't there yet. And I am sure you will in a couple more iterations.

Cheers,
RossW
=====