Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

eliuds-eggs: Reword exercise restrictions #2497

Closed
wants to merge 1 commit into from
Closed

eliuds-eggs: Reword exercise restrictions #2497

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions exercises/eliuds-eggs/instructions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,5 +4,5 @@ Your task is to count the number of 1 bits in the binary representation of a num

## Restrictions

Keep your hands off that bit-count functionality provided by your standard library!
Solve this one yourself using other basic tools instead.
Avoid using any library functions that count the number of bits in a number.
Instead, try solving this yourself using more basic tools.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does one measure how basic something is? Would bitshifts and loops be more basic or less basic? I think sticking to "other" might be better here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does one measure how basic something is? Would bitshifts and loops be more basic or less basic? I think sticking to "other" might be better here.

Good point. We can't. I didn't really think much about that for two reasons:

  • The restriction specifies what should be avoided but doesn't clearly define what is permitted.
  • Using 'other basic' might suggest a comparison, implying that the restricted tools and potential alternatives are similarly complex.

So, if we want to avoid any kind of comparison —which might be preferable— we could simply say 'other tools.' If a comparison is still desired, I’m personally indifferent.

Thoughts, maintainers?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that other tools/approaches fits better in this case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"other tools" sounds good to me!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Sun, Nov 17, 2024 at 09:30:28AM -0800, Isaac Good wrote:

@IsaacG commented on this pull request.

@@ -4,5 +4,5 @@ Your task is to count the number of 1 bits in the binary representation of a num

Restrictions

-Keep your hands off that bit-count functionality provided by your standard library!
-Solve this one yourself using other basic tools instead.
+Avoid using any library functions that count the number of bits in a number.

That seems excessive, especially if you choose to write a library
function not using the built in bit-count functionality provided by your
standard library.

+Instead, try solving this yourself using more basic tools.

"other tools" sounds good to me!

I agree with the "other tools" approach, for sure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping what we have on Problem Specifications is also an option. The wording is a suggestion, a request, rather than a restriction, the restriction would be in the tests, if those restrictions exist.

Is a comment needed for that in general? Based on the solutions I have seen that ignore the suggestion, it seems that it is generally interpreted as a suggestion rather than a restriction.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't have a consensus here, it might be best to bump this back to the forum to discuss until we can agree on something.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the solutions I have seen that ignore the suggestion, it seems that it is generally interpreted as a suggestion rather than a restriction.

I don't know how it is interpreted. All I see is a clear restriction stated in a very aggressive manner.

Restrictions: Keep your hands off that bit-count functionality provided by your standard library!

Copy link
Member Author

@tasxatzial tasxatzial Nov 20, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't have a consensus here, it might be best to bump this back to the forum to discuss until we can agree on something.

Well, folks, I don’t know. The only thing I'll say is that those instructions didn't achieve what they were supposed to. My reasoning for this is outlined in my initial forum post.

Regarding the wording, while I agree that it matters, for this particular exercise, once someone reads the phrase "Avoid ... that directly counts the number of bits" they'll immediately understand the restriction because it clearly conveys the intent. In contrast, terms like "bit-count functionality" can easily be misinterpreted, as "functionality" implies a broad range of things. In fact, it's even worse than using the word function.

That said, none of the terms — function, functionality, or more basic tools—seems likely to make a significant difference here. As I mentioned earlier, the purpose of the restriction is to specify what cannot be used, not what can.

Additionally, the second sentence — Instead, try solving this yourself using other tools — feels superfluous at this point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I mentioned earlier, the purpose of the restriction is to specify what cannot be used, not what can.

This basically outlines why I think that an append file would be the better solution, as it can be directed to the specific language track, and that restriction is very much dependent on the language, in terms of what should or should not be used in that track. Those specifics can be addressed more locally than Problem Specifications can.

I get the wording "Restrictions" is pretty strong, yet no matter how we communicate to the student, it is up to them to determine where they get the value of "learning" from, even if it contradicts the restriction and the learn something by using something that is restricted. In terms of "absolutes" there are ways to more directly restrict something programmatically, but also ways that a clever student can bypass those restrictions, and doing so may also provide learning opportunities to them.

It is not an easy problem.

The "confused me" problem is something that we likely deal with (OK, I deal with this) every day, and the solution to this is very often solving the problem (or not) but then submitting it for review and asking, which likely will give an opportunity for clarity.

Additionally, the second sentence — Instead, try solving this yourself using other tools — feels superfluous at this point.

As I mentioned in the forum, I would interpret this as "provide this functionality yourself", regardless of the "other tools" since solving this myself will provide that "other tool" at that point. Is it superfluous? By definition it definitely is as it is extra confirmation that the solution is "something other than a built in solution".