Objective computational challenges without "code"

Question

I recently posed a question about attempting to ruin Lepton's attempt to compress a JPEG. I've done other file-format-type questions before, to generate a WAV, defeat LZMA compression, etc, in part because I like to learn how file formats are put together at the byte level.

The question is all about file formats and compression methods, both of which are inherently computational, and rather than try to do some frankenscore of the program size and the compression size with some arcane mixing rule, a la the LZMA question, I just made the scoring all about the JPEG. Maybe if I phrased it "you need to generate the JPEG with code", it would be "about programming", but really, I don't care about saving bytes with esolang XYZ, and there are plenty of other challenges for that.

The notion that it's just about "finding the right data" I find to be a bit of a red herring. Every answer to a "true programming problem" is about finding the right string of code to be run, and using a totally naive approach (i.e. attempting to run random strings to get the correct output) in most languages would have orders of magnitude better luck than trying to do the same for this "restricted-source" question.

The core of programming is one of specifications. Computers do specific things as dictated by an input and rules as to how the input is handled. Programmers and hackers need to understand how things work in order to (mis)use them. To that end, I suppose if the specifications of the site are defined so narrowly, I could jump through them, but that kinda sucks the fun out of it.

Answer 1

We should allow computational challenges of all sorts

tl;dr: This site is about puzzles based on programming, not puzzles whose solutions are programs. This challenge qualifies.

We currently accept a variety of challenges that are not based directly on code. For instance, we accept algorithm-only challenges. The accepted answer for why we should accept such challenges is that algorithms are part of the programming process. The exact same argument applies here.

Programming doesn't end when the code is written. Testing code is an essential part of the programming process, and finding inputs to a program that have interesting behavior is a key part of testing. In this challenge, we are asked to find an input to a program which has unusual behavior for that program. Sure, the submission isn't a piece of code, but that doesn't mean it's unrelated from programming entirely.

In addition, this is not a challenge that can realistically be solved without writing computer programs. It's possible that someone will come up with a good solution by hand, but the best solutions are going to be found by a computer program, with very high probability.

Moreover, imagine the the challenge was slightly modified from "Find a JPEG that Lepton can't compress" to "Write some code that outputs a JPEG that Lepton can't compress", where the scoring metric, in either case, was the compression ratio of the resultant JPEG. Would that change anything about the merits of the question? Of course not.

Let's not let an arbitrary rule like "Solutions must be code" hold us back from good challenges such as the one in question.

Answer 2

[R]ather than try to do some frankenscore of the program size and the compression size with some arcane mixing rule, a la the LZMA question, I just made the scoring all about the JPEG. Maybe if I phrased it "you need to generate the JPEG with code", it would be "about programming", but really, I don't care about saving bytes with esolang XYZ, and there are plenty of other challenges for that.

Your scoring method is not what jeopardizes the "ontopicness" of your question. We have a lot of challenges that aren't scored by the byte count or some other metric that isn't related to the functionality of the submitted programs. Scoring a program by how well the image it generated can be compressed is perfectly fine.

So why was your question closed in the first place?

If you used some code to carefully craft the JPEG, please post it along with the image.

That implies that we do not actually have to generate the image with a program. I can take a picture with my phone, scan one of my daughter's drawings, use some photo manipulation software to create a random image, browse the Internet for noise images, etc., all of which are completely unrelated to programming.

Granted, it's unlikely that the first two approaches would result in a competitive entry; I'm actually not convinced that any approach would stand a chance against pseudo-randomly selecting the pixels with a uniform distribution. The latter two might stand a chance though, and submissions that consist of nothing more than a swirl of pixels are neither related to programming nor interesting.

So, regardless of what the community ends up deciding, why not circumvent the whole problem and make submitting the code that generated the image mandatory? That can't possibly affect the challenge in a negative way, and nobody will be able to argue that it's off-topic.

Answer 3

The difference between your LZMA challenge and this challenge is, the LZMA challenge actually required writing a program as a submission. This challenge merely requires outputting a constant output - there's no programming involved in generating the output (aside from probably writing a program to find a valid output).

All solutions to challenges must be code submissions (note that a pseudocode explanation of an algorithm can count as "code" for fastest-algorithm challenges). If the only point of a program is to output a constant output^[1], then it's not much of a programming challenge, and thus it's off topic for this site.

Simply put, this is a site about programming. If there is no programming involved in a challenge, it is off-topic.

^[1]kolmogorov-complexity challenges are a bit different, but solutions to these type of challenges typically involve programmatically generating the output by exploiting some structure/repetition in the desired output, rather than simply doing print("large string here").