Talk:Ancient Temple/@comment-29520543-20160810015306/@comment-26935235-20160814043304

Pictures alone aren't proof. The first picture just shows money, which can be obtained with any method. The second picture actually has a setup, but it could just be a setup made after you got the money. I'm not saying that you are lying, I'm just saying that you haven't provided sufficient proof. Next time you should provide exact ore values that reproduce the bug and possibly even a video. I wasn't going to wait 20 minutes for Morning Star to bring ores to their max value.

As for the bug, I did some testing and found that doing x % y with an x above 1e17 and a y that isn't a power of 2, a value around 15 times less will be returned (exactly 2^53x less). For reference, 53 is the number of bits that are used in doubles for the fraction part of the number that allows for it to represent decimals and numbers that aren't a power of 2. It gets weirder though because sometimes it is positive and sometimes it is negative. It still happens with values that are below -1e17 and gives both positive and negative numbers, so negative value ores can potentially become positive again. Because the numbers are 15-16 times smaller, and doubles support around the same amount of base 10 digits, it looks like a floating point error happening with the least significant digits which is weird. math.fmod doesn't have this bug though and it works with higher numbers normally, so it looks like berezaa should switch to using that to fix the Ancient Temple.

What is bothering me is the nature of the bug. It sounds like some of the least significant bits are being set, but floating point notation leaves out the leading 1, and represents numbers sort of like this: .100101010100101e101 instead of 1 .100101010100101e101 (this is in binary of course). It doesn't make sense for the least significant bits to result in a number 2^53 times less when the format implies that it can never be the case, because the exponent of the double itself would need to be touched. Dividing a number like 1e80 by 7, getting rid of the integer, and multiplying by 7 again shouldn't result in a number 2^53 times less than x, especially when 7 is only 11 (binary), just barely less than 2^3. It isn't simple floating point precision errors, because the same calculations run with math.fmod and even with an implementation in Lua give correct results. It makes me wonder what the exact implementation of the % operator is.