Weak Rules

[busterbeam]

#24 (comment)

I commented on a closed issue. but a summary is measuring it brain capacity through the weak analysis of formal programming language is not the best I think. It would probably better to just measure compiled binary size, but of course double check that that binary is not talking to the outside for help and/or lookup tables. If you not careful your just going to get code golfed submissions even if you say variable name length is fine.

If the compiled size is what your measuring people will most certainly just code normally.

[wischi-chr]

C# includes all kind of stuff from the source in the compiled output, including method names, etc. So your suggestion would probably lead to unreadable submissions and method name shortening because it reduces the compiled size.

C# even includes the path of the source file in the output so it would make a difference in which path you compile your program.

[busterbeam]

I don't follow you. your saying compiled code becomes more interpretive? and one piece of source code that may have different syntax structure will not compile to the same binary as another source file that has the identical logic structure.

I'm getting the feeling we are talking right past each other. any sensible programming language will have a more logical compiled format that parsing as tokens far better. Will the number be 1000 tokens? probably not, you may measure it instead as no more than 10KiB.

compiled size, not whatever your talking about

[wischi-chr]

No it doesn't become more interpretive but variable names are not optimized away in C# so if you write a method with a parameter name remainingNumberOfMoves the binary will be larger than if you name the parameter just n.

So in order to be competitive people will use single letter identifiers for classes, methods, parameters, etc. just to get the binary size down. People that know what they are doing will use (or write) C# source minifier (like in JavaScript) or obfuscator before they submit their solution.

The solutions would then all be pretty much unreadable and look more like code golf than anything else.

[busterbeam]

Another way I can put this is. the tokenCounter.cs to work optimally for the competition will tend towards a compiler. In which case why not compile to a certain standard, and if there is edge cases in the compiled code I'm sure they are much more easily dealt with that way, right?

[mcthouacbb]

@busterbeam I would prefer token count over binary size because

1. As @wischi-chr mentioned, C# includes stuff from the source file in the compiled binary
2. The token counter can be modified and tweaked to better fit the competition(such as excluding certain tokens), whereas the compiled binary is more or less fixed
3. It's easy for people to reason about the token count, which makes it easier to decrease the token count. Decreasing the binary size is not something that people can easily figure out without compiling.

[JoseBritto]

@busterbeam I don't think extreme competitiveness is the agenda here. In my opinion the simple rules of this challenge and the existence of a framework to make everything work lowers the barrier to entry and sort of levels the playing field a bit for less experienced developers so anyone can compete and have an actual chance to win even if they don't know much about the inner workings of the language and compiler tricks. (This is a very interesting video about binary size optimization)

It is also far more easier to chatch cheaters this way instead analyzing every single binary (which i believe would take a lot of time to perfect).

[busterbeam]

@wischi-chr and @mcthouacbb alright I have read into what I'm looking for. And maybe I will probably have to build it to demonstrate. I plan to use Mono.cecil to "analyze" the compiled (for release) MyBot.cs, compiled to DLL. I guess yes not "raw bytes". If this challenge was done in c for x86 some people may done the trick of 16bit opcodes or something.

You say how "people will not understand", but people have also asked questions about tokenCounter even though Sebastian has provided a GUI and source code for it all. So my suggestion is is using the complete Mono.cecil to have better defined counting logic which would again be passed to the GUI as a count. Correct me if I'm wrong but the MyBot.cs still has to be compiled to be run, how can people "not know how to compile"🤦‍♂️. This is not C and Sebastian has suggested people use Visual Studio and built the frameworks. I'm suggesting you modify that already decent framework to have a better "token counting" framework that is harder to fool and will discourage poorly structured code.

Thank you for repeating but I was and am fully aware the idea of the token counter not counting bytes but a method/variable name as 1 token instead of how many characters etc..

I don't like lecturing this out. But really do hope either the token counter becomes significantly stronger (almost like a compiler in its own right) or my suggestion is followed somewhat (doesn't have to use Mono.cecil)

[wischi-chr]

As @mcthouacbb already said, the current implementation is easy and even if some people are not sure what counts as a token and what doesn't - you get a feel for it very quickly and there is a strict correlation - more source code, more tokens.

Adding a compiler would make it vastly(!) more complicated and confusing. Compilers do a lot of "magic" and with your metric trivial changes like changing the type of a parameter, or adding a parameter to a function could add or remove hundreds of tokens because the compiler decided because of some wired heuristic to inline a method or don't inline it. To unroll loops, drop variables because it can proof some path is never taken, etc.

And maybe I will probably have to build it to demonstrate.

It might sound harsh but I fully expect you to fail at that, but I really want to encourage you to try it anyway just to see how complicated and confusing it would be and how almost stupidly simple (and elegant) the current solution is.

[busterbeam]

I do code in C a little, so I do understand the "magic" of compilers. What I have learnt from this "magic" is that the best "coders" in the competition will be ones who write like compilers... are you getting my flow yet? those who understand to flatten their loops and use weird math tricks.. this competition becomes less about employing good AI and more about software architecture. There is a reason Sebastian has abstracted out chess operations, instead of requiring users to build there own.

To state that this is too large a change to late in the challenge is also incorrect as at most the competition has been out for ~5% (at the time of writing calculated since the YouTube video drop) of its total duration. If we were after ~25% I would probably not suggest it.

[wischi-chr]

Let's just make this simple. Implement an alternative metric for code size and I'll show you a few concrete examples why it's not a good idea.