This is not just an issue with ML code, it's an issue with any code that doesn't do what the OP wanted that's posted to the site at all.

It could either be a problem of understanding what the algorithm is (not really knowing the correct thing to code to achieve the aim) or it could be a problem of converting a correct algorithm into code (implementation).

The first kind of problem would be on topic, but the second would usually be off topic. As whuber says, we're not a code review site.

Here's the kicker: It could also be both, and even if it is only one or the other, disentangling the two kinds of issues in block of code is often very difficult.

We should as far as feasible focus on questions that are about the first thing -- not just because we're not a code review site but

• that's where such questions have to begin; it's too hard to make progress on such problems if you're not clear what you're trying to do

• because that's where the statistical issues mostly will be

* We can't completely eliminate questions with code, however, for a variety of reasons, nor do I think we should. This is more about "how should questions where there's an ambiguity of problem-category be structured?" -- a question that doesn't do a good job of separating the two kinds of issues is generally a bad question. It's a problem of premature coding.

So to work on a questions "what should I be implementing?" we should not in general be looking at a chunk of code. We should be talking about a problem expressed in words and algebra. That focuses them on the part of the problem they they should focus on first and allows us to focus on the part of the problem we can talk about here. It helps to disentangle the mire of "what am I trying to do" from "did I do it right" -- such disentangling is generally the province of the question, not of an answer.

Once that question is clear a suitable thing to code up may result -- which might be expressed in various ways -- often in words and algebra but perhaps in pseudocode or possibly even in code if it happens to be by far the easiest way to express it and it suits the OP. So answers might occasionally give code but code should usually be avoided in questions, so we're not constantly bringing in implementation issues (clouding the question).

Once the OP is sure they have the algorithm/approach they need, the question "does this chunk of code correctly implement this clearly stated algorithm" would nearly always be off topic here, but set up properly could be a great question for another site.

This is not just an issue with ML code, it's an issue with any code that doesn't do what the OP wanted that's posted to the site at all.

It could either be a problem of understanding what the algorithm is (not really knowing the correct thing to code to achieve the aim) or it could be a problem of converting a correct algorithm into code (implementation).

The first kind of problem would be on topic, but the second would usually be off topic. As whuber says, we're not a code review site.

Here's the kicker: It could also be both -- but even if it is only one or the other, disentangling the two kinds of issues in block of code is often very difficult.

We should as far as feasible focus on questions that are about the first thing -- not just because we're not a code review site but

• that's where such questions have to begin; it's too hard to make progress on such problems if you're not clear what you're trying to do

• because that's where the statistical issues mostly will be

* We can't completely eliminate questions with code, however, for a variety of reasons, nor do I think we should. This is more about "how should questions where there's an ambiguity of problem-category be structured?" -- a question that doesn't do a good job of separating the two kinds of issues is generally a bad question -- it's a problem of premature coding.

So to work on a questions "what should I be implementing?" we should not in general be looking at a chunk of code. We should usually be talking about a problem expressed in words and algebra (or pictures or whatever other way of transmitting concepts works for this problem). That focuses them on the part of the problem they they should focus on first and allows us to focus on the part of the problem we can talk about here. It helps to disentangle the mire of "what am I trying to do" from "did I do it right" -- such disentangling should generally be the province of the question, not of an answer.

Once that "what specific approach should I use to solve this" kind of question is clear a suitable thing to code up may result -- which might be expressed in various ways -- often in words and algebra but perhaps in pseudocode or possibly even in code in some instances. So answers might occasionally give code but code should usually be avoided in those kinds of questions, for their own sake. (At the very least, code should be right at the end, after a proper description of the problem, not the problem description itself! I think "is this code right? ", where you must infer the issue from the code, should usually just be closed.)

Once the OP is sure they have the algorithm/approach they need, the question "does this chunk of code correctly implement this clearly stated algorithm" would nearly always be off topic here, but set up properly could be a great question for another site.

This is not just an issue with ML code, it's an issue with any code that doesn't do what the OP wanted that's posted to the site at all.

It could either be a problem of understanding what the algorithm is (not really knowing the correct thing to code to achieve the aim) or it could be a problem of converting a correct algorithm into code (implementation).

The first kind of problem would be on topic, but the second would usually be off topic. As whuber says, we're not a code review site.

Here's the kicker: It could also be both, and even if it is only one or the other, disentangling the two kinds of issues in block of code is often very difficult.

We should as far as feasible focus on questions that are about the first thing -- not just because we're not a code review site but

• that's where such questions have to begin; it's too hard to make progress on such problems if you're not clear what you're trying to do

• because that's where the statistical issues mostly will be

* We can't completely eliminate questions with code, however, for a variety of reasons. This is more about "how should questions where there's an ambiguity of problem-category be structured?"

So to work on a questions "what should I be implementing?" we should not in general be looking at a chunk of code. We should be talking about a problem expressed in words and algebra.

Once that question is clear a suitable thing to code up may result -- which might be expressed in various ways -- often in words and algebra but perhaps in pseudocode or possibly even in code if it happens to be by far the easiest way to express it and it suits the OP.

Once the OP is sure they have the algorithm they need, the question "does this chunk of code correctly implement this clearly stated algorithm" would nearly always be off topic here.

This is not just an issue with ML code, it's an issue with any code that doesn't do what the OP wanted that's posted to the site at all.

It could either be a problem of understanding what the algorithm is (not really knowing the correct thing to code to achieve the aim) or it could be a problem of converting a correct algorithm into code (implementation).

The first kind of problem would be on topic, but the second would usually be off topic. As whuber says, we're not a code review site.

Here's the kicker: It could also be both, and even if it is only one or the other, disentangling the two kinds of issues in block of code is often very difficult.

We should as far as feasible focus on questions that are about the first thing -- not just because we're not a code review site but

• that's where such questions have to begin; it's too hard to make progress on such problems if you're not clear what you're trying to do

• because that's where the statistical issues mostly will be

* We can't completely eliminate questions with code, however, for a variety of reasons, nor do I think we should. This is more about "how should questions where there's an ambiguity of problem-category be structured?" -- a question that doesn't do a good job of separating the two kinds of issues is generally a bad question. It's a problem of premature coding.

So to work on a questions "what should I be implementing?" we should not in general be looking at a chunk of code. We should be talking about a problem expressed in words and algebra. That focuses them on the part of the problem they they should focus on first and allows us to focus on the part of the problem we can talk about here. It helps to disentangle the mire of "what am I trying to do" from "did I do it right" -- such disentangling is generally the province of the question, not of an answer.

Once that question is clear a suitable thing to code up may result -- which might be expressed in various ways -- often in words and algebra but perhaps in pseudocode or possibly even in code if it happens to be by far the easiest way to express it and it suits the OP. So answers might occasionally give code but code should usually be avoided in questions, so we're not constantly bringing in implementation issues (clouding the question).

Once the OP is sure they have the algorithm/approach they need, the question "does this chunk of code correctly implement this clearly stated algorithm" would nearly always be off topic here, but set up properly could be a great question for another site.