[Freeciv-Dev] Re: [PATCH] Formatting cleanup.

[Gaute B Strokkenes <gs234@xxxxxxxxx>]

On Mon, 8 Oct 2001, rp@xxxxxxxxxx wrote:

> As a bystander I would like to say that it is still unclear to me
> what an 'unreal' coordinate is supposed to be, and yes I do try to
> follow the whole thread.

Look at is_real_tile() in map.c.  It's a bit of a misnomer since it
takes a pairt x, y as its argument rather than a tile pointer, but
there you are.

Basically a real coordinate pair is one that refers to an actual,
on-map tile.  An unreal pair is one that does not.  For example, if
you take a coordinate pair such as (14, 0), which refers to one of the
tiles on the very top of the map, and subtract 1 from the y-coordinate
in order to "go north", then the result, (14, -1), is an unreal
coordinate pair: it does not refer to an on-map tile.

> Also for many postings it is unclear which exact set of topologies
> they discuss.

Personally I am only interested in the rectangle and the cylinder,
their isometric-view variants of both, and possibly any others should
they turn out to be particularly straight-forward to implement.

> The whole notion of normalization doesn't apply to some of the
> example maps.

Congratulations, you win the big price!  What has basically happend is
that some people have proposed nightmarish topologies that no one is
ever going to want to implement or be particularly inclined to play
on, in the hope of proving that normalisation is a real tiles only
thing.  What they usually fail to realise is that normalisation can
not be applied as-is to these topologies at all...

>> > I'm not entirely sure what you mean by "converting it to a real
>> > coordinate".  I assume you mean something like map_adjust_y() or
>> > nearest_real_pos().  If you wish to take most abstract view
>> > possible, this is more wrong than playing games with unreal
>> > coordinates, since there is no particular guarantee that there is
>> > a well-defined nearest real tile in an arbitrarily nasty
>> > topology.
> 
> This is an example: there is no "most abstract view possible".  You
> can become more and more and more generalized.

It is precisely this desire to generalise everything that I dislike.
One of the reasons is that you have to go to great lenghts to explain
and define your terms before you can have a reasonable discussion or a
reasonable implementation.  This is a lot of bother.  I think it's
much better to stick to the cases that we wish to deal with and
consider the facts that we are discussing as obvious observations.

Put another way, I think that the business of producing arbitrarily
strange topologies in order to prove points about the current
implementation is useless.

> So please state this "most abstract view" in mathematical terms, to
> allow us to determine which topologies and map views satisfy it.

Well, the map can be described as a graph.  The graph is "locally
gridlike" by which I mean that given any point, if you look at a
reasonably small piece of the graph surrounding that point, the graph
is a two-dimensional grid, possibly with some of the vertices removed
(unreal tiles).  Oh, and we only want to deal with finite graphs.

This definition is good enough for our purposes.  Note that we do not
assume anything about orientability etc.

It is not convenient to represent the map as a graph in memory.
Instead, we use pairs of integers, i.e. coordinate pairs.  How you
assign coordinates to tiles is a matter of convenience, but in the map
that we have implemented we have chosen a particular tile that (0, 0)
refers to, and then declared that (x, y) refers to a given tile if you
can get to that tile by starting at (0, 0) and walking x steps east,
and then y steps north.  On the map that we have, several (in fact an
infinite number of) coordinate pairs refer to the same tile, which is
why we have the normalisation concept.

PS coordinate pair == position.

>> I mean nearest_real_pos().  This conversion is sometimes necessary,
>> and it's okay for it to be a bit fuzzy.  For instance, the client
>> uses it to convert out-of-bounds clicks to clicks on real tiles.
> 
> I know it's none of my business, but remarks like this don't give me
> any confidence that the map view code will be bug-free again this
> year.  "Sometimes we throw in some partly-understood conversion
> function there to make it work", that's what it seems to say.  There
> just don't seem to be any decent definitions of concepts here, only
> a bunch of conversion algorithms.  The data model is missing.

Hear, hear.

>> Proof?
> 
> There aren't even any *definitions* a proof could be based on!

Sure there are, but no one told you about them. 8-) The bit at the top
gives you everything you need to follow it.  Everyone else in the
discussion so far seemed to be aware of is_real_tile() and its
meaning, so I do not think that I can be blamed for not mentioning it;
additionally I would like to add that I consistently use the word
position or coordinate pair to refer to an (x, y) pair, and the word
tile to refer to an actual square that you can see on your screen
(i.e. a tile pointer).

>> > But really, I think all this talk about supporting arbitrarily
>> > strange topologies really has that much value.  The only
>> > topologies that I think we really want to support are the
>> > rectangular, cylindrical and isometric-view cylindrical variants.
>> > Additionally, a torus might be so easy to do that there may well
>> > be no real reason not to.
> 
> OK, well, then add that information to your postings, define the
> Freeciv data structures you need and the conversion routines, and
> you can prove whether or not any piece of map manipulation code is
> correct or not.

I'm not sure what you're asking me to do here.  I'm just saying that
having lots and lots of strange topologies is probably not desirable.

I think that it is unreasonable to demand that each and every piece of
code should come with a formal proof of its correctness.  When you're
dealing with a known range of well-behaved objects it ought not to be
necessary to explicitly list any and all properties that you wish to
use and where you use them, you can just take them as trivial
observations.  It is only when you wish to be so general that you can
no longer clearly picture all the cases you are dealing with that you
need to worry excessively about these things, and start providing
formal proofs.  The desire to avoid having to go to the trouble of
having to do so ever time one does something nontrivial with a
coordinate pair is one good reason to restrict things to a manageable
set.

> As a user I'd like to have a torus, it would make it easier to have
> a fair start when player density is high.

That's a good point.

-- 
Big Gaute                               http://www.srcf.ucam.org/~gs234/
I think I'll do BOTH if I can get RESIDUALS!!