Preston Crary

I tested on 1.7.4 (in a flower forest) and found two tall flowers, same place/seed on the new snapshot and there were no two tall flowers.

It makes sense that having a large number of entities that track targets over four times as far away than they used too would cause problems. With villages they also have multiple targets to consider. Guess I'm just going to forget my plans of living in a village.

Comparisons aren't that bad on performance. I would think in some cases having a complex formula is worse. They could also use a switch statement which would be slightly faster.

If this actually caused some lag they could rewrite the code to do a bisection search of the table. Worse case it would have to compare four times. However, I don't think the size of the table really warrants it.

Just a thought. Instead of using a formula, it may be better to just use a table whenever a comparator is used with a container. Something like:

This way every output change would be meaningful and since 75% would output 10 and above 75% would output 11 it would solve this problem too.

Okay, I can respect that.
Sorry, I just don't like to when someone says they can think of some reason for something but then they don't express one.

I don't think the formula you gave as an example would work though:
floor(1 + [(3/3) + (1/64)] * 7) = floor(1 + [(3/3 + (0/64) * 7)
floor(1 + 7 + 7/64) = floor(1 + 7 + 0)
floor(8 + 0.109...) = floor(8)

Maybe use Math.ceil instead of truncate?

"I could see some instances where having a stack of items in the top slot could be used"

Could you give one example please?

I think Kevin's fix would be enough for me to be happy.
However, I think the correct fix would be to revert this and make it so that brewing stands can only contain a single ingredient. The fact that Dinnerbone's algorithm was originally based on the assumption that they could only contain a single ingredient supports this.

Please revert this fix.