More on This Old Thread:

In reply to:


A suggestion: implement a non-linear curve by scaling values from a certain point.

Replace the "divide by 32 seconds to get a number" by the following procedure, then continue with the calculation as before:

Keep the initial divison by 32 seconds.
Values up to 16383 remain the same as they are now.
Values from 16384 to 4210687 are divided by 256 and added to 16320.
Values over 4210687 are forced to 32767 (so the values are limited, as before).

This means that we squash 4210687 seconds (1559 days or so - more than 4 years) into our 15-bit value, as opposed to the current 12 days, by using less precision (two hours instead of half a minute) for things played more than 6 days ago.



Blert: Insufficient generality, 10 yard penalty.

How about this:

TIME should be the log(base 2) of the actual time difference, with as many bits of precision as are possible at any given time (if you're messing with unix time_t's, the largest log base 2 will take 4 bits of integer, leaving the other 11 for the fractional part).

Note that this scales kind of self-correctingly: if you've played everything recently you get an extra couple bits in the fraction to differentiate them with. Also, this completely gets rid of the 'ages ago' category, though of course songs can still 'collide' by having the same 'TIME'

--pj