Closed pitust closed 1 year ago
don't forget about reflection
Reflection is not in System
though.
Reflection is not in
System
though.
Oh, my bad
Clever, I've updated the rules again. Thank you!
I've updated the rules again
Environment.StackTracks
Typo alert
Reading into this stuff as I am concerned of weak rules. Not an expert in C# but I know there are a lot of ways to "obfuscate"/"encode" data within strings/arrays that can sit inside your actual C# file. Have we covered all of them? I think this idea of "tokens" is a little short sited. Surely you should be measuring by the compiled size. And by all means you cannot import/load/open/stream data from elsewhere. The binary should be self contained and have a max size. This also makes your life much easier for people who do not want to or able to write terse code. I can see some submissions being code golf flexes. You have obviously choose ~1000 tokens as stock-fishes implementation even if code golfed wouldn't be that small. You are instead exploring what is the best solution when the brain's are nerfed. I do think it's a very interesting concept, just your measuring at the wrong stage.
TL;DR;- You should be measuring the compiled program not the source code. As an impossible tic tac toe AI can be written in very short source code but you also could do it in a thousands of lines the similar logic will still be there.
Reading into this stuff as I am concerned of weak rules. Not an expert in C# but I know there are a lot of ways to "obfuscate"/"encode" data within strings/arrays that can sit inside your actual C# file. Have we covered all of them? I think this idea of "tokens" is a little short sited. Surely you should be measuring by the compiled size. And by all means you cannot import/load/open/stream data from elsewhere. The binary should be self contained and have a max size. This also makes your life much easier for people who do not want to or able to write terse code. I can see some submissions being code golf flexes. You have obviously choose ~1000 tokens as stock-fishes implementation even if code golfed wouldn't be that small. You are instead exploring what is the best solution when the brain's are nerfed. I do think it's a very interesting concept, just your measuring at the wrong stage.
TL;DR;- You should be measuring the compiled program not the source code. As an impossible tic tac toe AI can be written in very short source code but you also could do it in a thousands of lines the similar logic will still be there.
Agreed. People are definitely going to code golf this. See https://codegolf.stackexchange.com/ for inspiration.
It might be better to put this in a new issue though, since this one is already closed.
Compiled size may vary with compilation envoirement, compiler flags, compiler version and so on. It also brings the question of if we are allowing writing assembly directly, using binary packers, etc. It would also require digging into the compiled IL into the binary to find out why exactly your size is what it is. It wouldn't be a good measure, at least not for this kind of challenge which is aimed more at beginners. Compared to the usual code golfing grading of character count, tokens have the advantage of allowing somewhat readable code with variable names, formatting, etc. Strings are counted by their length, storing data in identifiers is banned, and arrays inherently count as multiple tokens too.
If you have any ideas for rule bypasses, you should probably mention them explicitly instead of requesting a change in the challenges fundamental rules.
A code golfing challenge that focuses on binary size is not suitable for an audience that is new to code golfing.
As an impossible tic tac toe AI can be written in very short source code but you also could do it in a thousands of lines the similar logic will still be there.
How is this relevant at all?
Thank you @ZeliTheZealot, I instead started a discussion about it. I'm not an expert in C# I might try and implement what I'm talking about I'm thinking of using Mono.Cecil
, to count the "operations" and variables by the "bytes", or something like that. any suggestions or thoughts? instead of just shooting it down
I think you might make some more friends @leumasme over at the discussion
You can still store arbitrary data in identifiers, then retrieve it by calling the function and having it extract the stacktrace. Something like this would probably work: