[Freeciv-Dev] Re: (PR#6257) recodify map_pos<->index conversion to use n
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: |
undisclosed-recipients: ; |
Subject: |
[Freeciv-Dev] Re: (PR#6257) recodify map_pos<->index conversion to use native positions |
From: |
"Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx> |
Date: |
Fri, 3 Oct 2003 00:09:01 -0700 |
Reply-to: |
rt@xxxxxxxxxxxxxx |
rwetmore@xxxxxxxxxxxx wrote:
> Bzzzt ... remember recent history, don't relive it :-).
>
> Jason Short wrote:
>
>>Gregory Berkolaiko wrote:
>>
>>
>>>On Tue, 23 Sep 2003, Jason Short wrote:
>
> [...]
>
>>>How about introducing 2 new macros
>>> map_to_native_x
>>> map_to_native_y
>>
>>Clever. This is generally the type of thing we want to avoid - since
>>most of the time it will only lead to misuse - but here it is helpful.
>
>
> Actually, very stupid. map_adjust_x() and map_adjust_y() memories should
> hopefully rekindle the endless hassles of assuming that the two coordinates
> are independent. The transformation of a gen-topology 2-D coordinate pair
> cannot assume independence as the first extension case below shows.
>
> The equivalence operation applies only to the current standard to native
> mappings, and will be very shortlived - so short that hopefully the clever
> stupidity of it will not have time to sink in :-).
It is quite safe to take a function that is (int x int -> int x int) and
filter the results so that it's (int x int -> int). It's just that
there aren't very many reasons why you'd ever want to do this, since one
coordinate without the other usually won't do you much good.
What map_adjust_[xy] did was limit the input so that the function was
simply (int -> int) - which is unworkable.
The only acceptable alternative I see is to make this operation a
(possibly inline) function.
jason
|
|