[Pidgin] #301: Make number of saved popular statuses configurable

[Pidgin]

#301: Make number of saved popular statuses configurable
---------------------------+------------------------------------------------
  Reporter:  gagern        |       Owner:  seanegan
      Type:  enhancement   |      Status:  new     
  Priority:  minor         |   Milestone:          
 Component:  pidgin (gtk)  |     Version:  2.0     
Resolution:                |    Keywords:          
---------------------------+------------------------------------------------
Comment (by gagern):

 To keep information about the last hundred changes, counts simply won't
 do. You have to keep track of the order in which counts expire, which
 means that you have to keep a log of those hundred changes. Whether you
 remove nonsurvivers doesn't really make much of a difference imo, and
 would further comlicate matters. Therefore sliding windows require quite a
 few lines of storage, and I don't know how this would interact with
 backwards compatibility. The same goes for moving average.

 An alternative would be some form of decaying usage count, like at every
 change, multiply all counters by 0.98, then increment the one you changed
 to by 1. This can be done with only a single real-valued additional
 attribute per saved status. After 35 changes of status, your usage count
 would have lost half its weight if it was not used any more.

 The only way to avoid problems with hysteresis would be to remember past
 decisions. Otherwise, no matter how quick or slow your comparison function
 responds to changed user behaviour, you can always get users circling
 around the critical cutoff.

 I had a look at {{{saved_statuses_sort_func}}} in
 [source:libpurple/savedstatuses.c]. I fear it is also a cause of the
 cyclic use problem I described initially, as the limit of 10 is easily
 reached, and after that only timestamps count. So while this function is
 not bad, there is some space for improvement.

 To extend my own idea of frequency estimations, you could use the inverse
 of the time since last use as another estimate. This would by itself lead
 to the same order as the simple comparison of last usage times, but as a
 kind of frequency it would be on the same scale as the frequency estimate
 suggested above. You could then clip those if needed and weight them
 against one another, to balance overall against recent behaviour. Of
 course you could do all this in the inverse as well, i.e.
 time_since_created / use_count gives you the mean time between uses, which
 can be combined with the time since last use. This is nearer to what is
 there right now, and yields exactly the same results as the dual frequency
 approach.

 Talking of the product we don't have, if you mean Pidgin 2.0.0, I agree
 this should have precedence. If you however mean a change to the fixed
 choice of six, then I believe this modification to be closely related to a
 good choice function, so those two should perhaps be implemented together.

 I guess I'll have to get myself a monotone tree of pidgin, to experiment a
 bit, although the size of the bootstrap database worries me already.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/301#comment:9>
Pidgin <http://pidgin.im>
Pidgin