Talk:Recycler: Difference between revisions
Jump to navigation
Jump to search
(Talk: Recycler formula) |
(reply to Tecanec) |
||
(One intermediate revision by one other user not shown) | |||
Line 12: | Line 12: | ||
btw I can't access the Discord link, I have no idea what server it's leading to. | btw I can't access the Discord link, I have no idea what server it's leading to. | ||
[[User:Vadcx|Vadcx]] ([[User talk:Vadcx|talk]]) 04:17, 31 October 2024 (UTC) | [[User:Vadcx|Vadcx]] ([[User talk:Vadcx|talk]]) 04:17, 31 October 2024 (UTC) | ||
* Now that you mention it, there is an error, but it's not the one you thought you noticed. The problem is that I multiply by 100% when the formula is supposed to give a number of items. The floor is correct, since there can only be an integer number of items. And no, it won't "almost always" result in 1 or less; If a recipe takes 4 or more of the same item, then the result is always 1 or *more*. The random element also ensures that increments of less than 4 remain meaningful - think of it as a sort of "random rounding". - [[User:Tecanec|tecanec]] ([[User talk:Tecanec|talk]]) 13:59, 31 October 2024 (UTC) | |||
** Oh I see it clearly now. I simply hardcoded r = 0.5 as the statistical average :P However that's exactly the formula the game seems to use if the ingredients are cleanly divisible without a remainder.<br>Hm. Maybe in other words the randomization only kicks in if there's a non-zero remainder in <code>(ingredient / 4) = integer + remainder</code>. Implementation note: division by 2, 4, 8... is very cheaply done by a right shift. Similarly it'd be trivial to determine if there's a remainder with AND; and only then invoke the full formula. Neat! |
Latest revision as of 14:09, 31 October 2024
Recycler formula
floor(0.25 * i / o + r) * 100%
: User:Tecanec are you sure the formula is written exactly like that? What's currently inside floor(...) will almost always calculate to <=1.0, and flooring 0.0~0.999 will result in a 0.0. I think the formula should've been floor( (0.25 * i / o + r) * 100% )
. This one matches my spreadsheet expectations and you can test it yourself by recycling the nuclear reactor:
Formula unfloored (B) | input count (C) | output count(D) | “random” (E) | net return (G) |
---|---|---|---|---|
=0,25 * $C2 / $D2 + $E2 | 5000 | 5000 | 0.5 | =C2-C2*B2 |
btw I can't access the Discord link, I have no idea what server it's leading to. Vadcx (talk) 04:17, 31 October 2024 (UTC)
- Now that you mention it, there is an error, but it's not the one you thought you noticed. The problem is that I multiply by 100% when the formula is supposed to give a number of items. The floor is correct, since there can only be an integer number of items. And no, it won't "almost always" result in 1 or less; If a recipe takes 4 or more of the same item, then the result is always 1 or *more*. The random element also ensures that increments of less than 4 remain meaningful - think of it as a sort of "random rounding". - tecanec (talk) 13:59, 31 October 2024 (UTC)
- Oh I see it clearly now. I simply hardcoded r = 0.5 as the statistical average :P However that's exactly the formula the game seems to use if the ingredients are cleanly divisible without a remainder.
Hm. Maybe in other words the randomization only kicks in if there's a non-zero remainder in(ingredient / 4) = integer + remainder
. Implementation note: division by 2, 4, 8... is very cheaply done by a right shift. Similarly it'd be trivial to determine if there's a remainder with AND; and only then invoke the full formula. Neat!
- Oh I see it clearly now. I simply hardcoded r = 0.5 as the statistical average :P However that's exactly the formula the game seems to use if the ingredients are cleanly divisible without a remainder.