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

[Reinier Post <rp@xxxxxxxxxx>]

On Sun, Oct 07, 2001 at 09:52:19PM -0400, Jason Dorje Short wrote:

[among many other things]

> > > I say again: any time you are wrapping an unreal coordinate, or
> > > doing anything at all to it for that matter outside of converting it
> > > to a real coordinate, you are doing something fundamentally,
> > > theoretically wrong.
> > 
> > I'm afraid that it is your reasoning that is fundamentally,
> > theoretically wrong.
> 
> Naturally, I disagree.

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.  Also for many postings it is unclear
which exact set of topologies they discuss. The whole notion of
normalization doesn't apply to some of the example maps.

As long as all of you are clear on this it doesn't matter, but from
remarks such as these I get the idea that this isn't the case.

Perhaps it would be better to provide some clear mathematical definitions.
Defining these things in terms of patches to the code base doesn't seem to
work very well.

> > 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.  So please state this "most
abstract view" in mathematical terms, to allow us to determine which
topologies and map views satisfy it.

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

> My underlying assumption is that every topology we implement will map
> cleanly onto a plane.

What exactly is a "topology" here, an adjacency graph?  And what does
"map cleanly onto a plane" mean exactly, does it merely have to be
planear, or does it have to map onto a rectangular grid of adjacent tiles?
Is the grid allowed to have holes?  Can nodes in the graph be mapped
onto multiple tiles?  Please provide some actual definitions!

> Given that, there will always be at least one
> nearest_real_pos.  There may be more than one (as in my example from the
> previous post).

Again, what on earth is a "real" position?
 
> > > Give me enough chances, and I'll find a topology that proves it.
> > 
> > I consider that unlikely, given my above proof.
> 
> Proof?

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

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

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.

> > But everything else, including the stuff that I have mentioned from time
> > to time (Möbius strip, Klein bottle, RP^2 and so on) really strikes me
> > as having little value beyond the gee-whizz factor.

Well, hexagonal maps and approximations of spheres would be interesting.

> Correct, but I believe once we have a good implementation of the
> topology routines, these will fall into place - not that most of them
> ever need to make it into the real distribution.

First you need a good *definition* of the data structures,
then you can specify the conversion routines.

-- 
Reinier Post