[Freeciv-Dev] Re: directional system: more magic code cleanups

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

At 09:12 AM 01/09/24 +0200, Raimar Falke wrote:
>On Mon, Sep 24, 2001 at 01:19:14AM -0400, Ross W. Wetmore wrote:
>> I notice you left the two normalize_map_pos() operations in for the
>> Ross code, but neglected to add them for the others. This will change
>> the profiling results somewhat, as function calls will probably
>> dominate the time, and even the extra double compare in a macro
>> is probably significant here.
>> 
>> Since these are there really to handle the truly oddball cases where
>> the src and destination are separated by more than a full map in the
>> wrapped case, and none of the others are checking for this it is
>> redundant.

>I haven't made any change to normalize_map_pos calls.

Then your profiling numbers are wrong as pointed out to you above. You
are comparing apples and oranges if you don't remove them in one or add 
them to the other so that both are either handling the delta_x > map.xsize
cases or they both aren't. 

Your code is buggy under these conditions, but they are presumably not
normal behaviour and there is a judgment call as to whether the check is
warranted or not.

>> The code appears to have been reformatted as well since I generally
>> lineup the things like if clauses in ways that enhance similarities
>> rather than obscure them. I don't believe the multi-line if's are 
>> broken in quite the way that the sample code was in when sent to you.
>> So I take some offense at your "readability" comments.
>
>Yes I reformatted the code. Yes I changed two things: MAP_WRAP_[XY] in
>your code and one error in my code. 

If you change someone's code by reformatting it, then you should not
make comments about how unreadable you have made it vs how readable
your unformatted code looks. 

That is only fair.

>> I suspect, that your "bugs" are really just the fact that the scalar
>> product cases don't prefer the diagonal move when diagonal or cartesian
>> are equivalent.
>
>Ross it doesn't work this way. I tested the code and showed that the
>result of your method is different than 3 others. I expected from you
>that you take a look and either prove that your method is right and
>the other three are buggy and tell why this is so OR you post a fixed
>version of your code OR you show that there are really different
>results possible. BUT NOT a "I suspect".

I think I have proved how my method works and how it balances the game
play in many more emails than I want to remember, so you will have to 
come up with a better monkey argument than this. It has also been running 
and tested for far longer.

Since you haven't posted this data to show what the differences are, 
(and from your code it looks like you have arranged to make a single
difference fill up screeds of screen or file real estate without giving
any really useful information), and you haven't done any analysis except 
say that the two methods are different, it is a little difficult to 
refute such vaporware claims which don't even have credibility going 
for them.

Moreover since it is just "different" from your routines, you really 
should have looked more closely at the characteristics of your algorithm
as I have done with mine and shared with the mailing list. Your claims 
of "buggy" seem to be more wishful thinking than fact. 

If you are just out to prove something, then make sure your proof is 
solid :-).

To help you along ...

If you put values of 32768 and 131072 into your second algorithm, then
you are essentially doing the same 2*y vs x or 2*x vs y compares in a
more complicated manner. It is not as easy to follow how it works
in the equal case, but it looks like it correctly prefers the diagonal.
If you do this, and your "differences" go away, then the "whose got
the bug" game goes something like the following.

The difference in interpretation is that in the trigonometric cases you
are dividing a circle, or constant distance from the centre point into
8 equal parts to get your dividing line betwen cartesian or diagonal
moves.

But in game coordinates a constant distance from the centre point is a 
square, because a diagonal move is no more costly than a cartesian one.
My algorithm divides a square into 8 equal parts, which is the slight
difference in the numbers suggested above from yours.

You should have exactly the same number of steps, just stepping one 
direction a turn or so earlier than warranted in some longer moves.

So, it appears that, well nice and theoretically elegant, your algorithm
is perhaps not as well suited for Freeciv, right? Is this sufficient
"proof" for you to at least stop and think things through?

But these are relatively minor differences in the overall scheme of things.

It is clear from even the biased profile results, that the original O(n)
algorithms are at least an order of magnitude worse than either of the
final two that just look at the sign and magnitudes. This should have
been obvious, but I commend you for the effort to prove it conclusively.

And if you take the function calls out you will only improve the performance
for the leading candidate :-)

So you need to decide if the differences show where your trig based 
algorithms have misstepped, and if so, then decide whether you want to 
live with occasional misses from an inappropriate choice of algorithm, or 
you need a correct one to match the application environment.

>       Raimar
>-- 
> email: rf13@xxxxxxxxxxxxxxxxx
> "Sit, disk, sit. Good boy. Now spin up. Very good. Here's a netscape
>  cookie for you. Fetch me some data. Come on, you can do it. No, not that
>  data. Bad disk. Bad." 
>    -- Calle Dybedahl, alt.sysadmin.recovery

Cheers,
RossW
=====