Skip to main content

Timeline for Modulo code golf

Current License: CC BY-SA 3.0

7 events
when toggle format what by license comment
Jun 17, 2020 at 9:04 history edited CommunityBot
Commonmark migration
Dec 16, 2011 at 16:44 comment added captncraig Fair enough. I was assuming I had an implementation that allows an arbitrarily large bignum input. Failing to find (or be allowed to create) that, this submission probably does not meet the requirements. It definitely can't handle negative input anyways. But it is remarkably competitive in count for a BF program, even if it is not quite there.
Dec 16, 2011 at 16:13 comment added J B I have no issue with the efficiency. What got me started is that no BF implementation I know of would be able to run your code on anything close to e50. The easy hurdle is the cell size, but implementations do exist that implement these as bignums. The hard one is input. I don't know of a single implementation that returns anything over 255, and can't conceive a reasonable one returning anything over 2^32. You could always find one and read input over several operations, but your character count doesn't reflect that. (publishing a new implementation for the the task is frowned upon)
Dec 16, 2011 at 15:01 comment added captncraig The more I think about it, the more I think this is defensible. All you need to make it handle e50 is an implementation that works on arbitrarily large numbers. Those do exist. Then it is just a matter of defining efficiency. Since this performs a whole lot better than brainfuck's built in modulo operator, I say it passes that too.
Dec 15, 2011 at 23:58 comment added J B I'm torn. The problem doesn't explicitely ask for arbitrary size integers, which would be a pain to implement in BF, that's for sure. But you're not even close to performing "well" for e50, since you won't perform it at all.
Dec 15, 2011 at 23:55 history edited J B CC BY-SA 3.0
code is code is code
Dec 15, 2011 at 21:54 history answered captncraig CC BY-SA 3.0