patchFreeciv - Patches: patch #2733, amortize_abs_zero()

 
 
Show feedback again

patch #2733: amortize_abs_zero()

Submitted by:  Marko Lindqvist <cazfi>
Submitted on:  Sat Jun 18 23:48:44 2011  
 
Category: aiPriority: 5 - Normal
Status: Wont DoPrivacy: Public
Assigned to: Marko Lindqvist <cazfi>Open/Closed: Closed
Planned Release: Contains string changes: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun Jan 4 08:54:44 2015, comment #3:

This would be redundant with want being floating point value in 3.0.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Mon Jul 2 16:36:19 2012, comment #2:

This patch didn't prove beneficial for the ai.

> Obviously it would be better to do just slightly (want value
> between 0 and 1) beneficial thing than nothing.


I will look if it would be feasible to always do even value 0 things instead of nothing. Often what is now of value 0, will be valuable in the future (tile taking to use, some effect's other requirements getting fulfilled)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Mon Oct 31 18:32:10 2011, comment #1:

If this is something for 2.5 would it not be best to do the step to a float? Most of the time amortize is used to calculate a want value which is compared to another value - changes would be only required for some variable definitions (int => float), or?

Matthias Pfafferodt <syntron>
Project Member
Sat Jun 18 23:48:44 2011, original submission:

Integer math is not really suitable for amortize() kind of operation. Especially problematic is return value 0. Many callers handle (or rather don't handle at all) that specially. For example: if best tile improvement thing settler may do gets want value 0, settler keeps its current, i.e., doing nothing, state. Obviously it would be better to do just slightly (want value between 0 and 1) beneficial thing than nothing.

While changing amortize() return value from int to float or double may seem like correct solution, it would require changing a lot of codebase to use those types to be really correctly implemented.
Instaed attached patch trades one problem to another, but hopefully less dramatic, problem. Instead of returning value "0" too often, new function amortize_abs_zero() returns "1" or "-1" too often. It returns "0" only if there really is no value in doing something.

This patch needs a lot of testing to see that it really improves, and not decrease, overall performance of ai.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #13276:  AmortizeAbsZero.diff added by cazfi (7kB - text/plain)

 

Depends on the following items: None found

Digest:
   patch dependencies.

 

Carbon-Copy List
  • -unavailable- added by syntron (Posted a comment)
  • -unavailable- added by cazfi (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Error: not logged in

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Jan 4 08:54:44 2015cazfiStatusIn Progress=>Wont Do
      Assigned toNone=>cazfi
      Open/ClosedOpen=>Closed
    Mon May 12 06:30:22 2014cazfiStatusReady For Test=>In Progress
      Planned Release2.5.0=>
    Sat Jun 30 16:03:25 2012jtnDependencies-=>patch #2714 is dependent
    Thu Oct 27 21:50:24 2011cazfiPlanned Release2.4.0=>2.5.0
    Sat Jun 18 23:48:44 2011cazfiAttached File-=>Added AmortizeAbsZero.diff, #13276
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup