There are two basic ways to store such things (pile of same type while averaging quality):
You have to store an amount (A) anyway (increment on pit and decrement on get), so we can forget about this.
The other value is the quality (Q), i use only one in this example with Qi as quality of item added/removed:
1) Store average quality (Qa)
Put: Qa=floor((Qa*A+Qi)/(A+1)), A+=1
Get: A-=1, return Qa
Needs memory location to hold Qmax.
Returns possibly less total q than put in, q is same for all items returned, order of insertion matters.
Option is to store more digits after the decimal point to lessen the problem, needing more memory to hold the fractions.
2) Store sum of quality (Qs)
Put: Qs+=Qi, A+=1
Get: q=floor(Qs/A), Qs-=q, A-=1, return q
Needs memory location to hold (Amax*Qmax).
Returns total q put in, items returned might oscillate +/- 1 in q, order of insertion irrelevant.
According to the effects we see we currently have 1).
Given that the extra memory for 2) is one extra byte for piles <2^8 items, or none in case 1) stores fractions, storage is cheap these days, plus the math is cheaper for 2)... I would like to have the second solution.