I want to express this as briefly and neatly as possible. I’ve written before about what differentiates a [fixed] point-based rating system from relative ratings (my rantish is nothing new by now), but I revisited my AniDB account the other day, glanced at my votes, and realized how completely fixed they really were.
Given the image above, one may notice that there is one 10, a fair number of 9’s, and some odd 9.xx votes. The existence of the 9.xx votes was an attempt at distinguishing within a point-range, in this case 9-10. As more series became “9’s,” the range began to fill, and if we examine the edge cases, we will see the dilema.
First, let’s assume the rating is restricted to one decimal place, and we have the following set of ratings:
- 10.0
- 9.8
- 9.7
- 9.6
- 9.5
- …
- 9.0
In this state, the user may have no problems rating an item a 9.9, or a shared 9.x value (two items with the same number). Now suppose we fill the first-decimal ratings by placing a 9.9 vote, in which we would then have:
- 10.0
- 9.9
- 9.8
- 9.7
- …
Like before, the user may have no problems rating an item with a shared 9.x value, but what happens when an item must absolutely split two of these values? For example, an item should be placed below what resides in 9.9 and above what resides in 9.81. For this there are two options, which I will call a shift and a divide. I’ll deal with the divide first, since it is what has occurred in my votes from the image above.
Divide
In a divide, to place an item between 9.9 and 9.8, the system would need to allow the hundredths place, and the item would then be placed at 9.85, exactly dividing the two sibling ratings. The immediate issue with this is that rating systems are usually limited to the decimal accuracy. If the system were to not allow the hundredths place accuracy, the assured option would be to shift.
Shift
A shift is literal. In order to split the 9.9 and 9.8 ratings, we would assume the new vote is no more than 9.9, therefore it must be 9.8, and so we shift -0.1 for all ratings below the new vote. This may be the most accurate option, but by what method do we shift all the values below? In almost every case this will need to be done manually, and in almost every case this will be a frustrating endeavor.
this explicitly shows one confinement of the fixed-point system.
Though the shift will nearly be an assured solution, it isn’t a very good one, but neither is the divide. If one were to continually divide the 9.0-10.0 range, does the value of the 9.xx begin to lose significance? Glancing at my votes in the image above, I don’t know the value of a 9, but I do know there is hardly anything unique about it; it is common.
Of course, none of these issues arise in a relative rating system, where divide and shift are essentially the same operation. There is no need for decimal accuracy or manual reassignment of previous votes in light of something new. There are levels, there are items, and the basis of how they relate:
Item A is lesser/below item B (A<B)
Item A is equivalent to item B (A=B)
It is recursive, simplistic, scalable, and flexible. Every user has their own personal rating system, but relative rating systems can be mathematically merged onto one another in order to see ratings of another system in the local (user’s) system… In this way, a relative level may very well be a tensor.
If you’ve come this far, I thank you for reading and if anything isn’t clear, please question it. The only other patriot I know using this rating system would be Michael, and I greatly thank him for his patience and interest (if you’re reading… the ease-of use needs improvement, but the theory still stands ^^).
Notes
1) We are not trying to put an item in a range, but what range does the item belong to. In other words, we are not expressing that it is a certain value, but it belongs to an area… it has a place among other items.
