As per the discussion at Square Root exercise instructions could be clearer the sentence “It is possible to compute the square root of any natural number using only natural numbers in the computation.” is not specific to Python and should therefore be moved to the overall problem specification.
Pull request created: Update description.md by xanni · Pull Request #2495 · exercism/problem-specifications · GitHub
In the future, please hold off on any PR creation until after maintainers come to some sort of consensus.
What is the addendum and what is the purpose of the addendum? The topic title doesn’t mention which exercise this pertains to. The post does not include any details about the change nor the rational for the change.
Looking at the linked PR, this appears to be for the Square Root exercise. It appears to add,
+ It is possible to compute the square root of any natural number using only natural numbers in the computation.
From what I’ve seen of this exercise, students will either not actually implement their own sqrt(), will brute force search integer ranges for the solution or will follow the Wiki link and use one of the listed formulas.
How would that change impact how students solve this?
Sorry about that, I should have repeated the description of the purpose of the change. At least in the Python track, the vast majority of the submissions simply use some variant of “n ^ 0.5” as the implementation. While the Wikipedia links do provide all the necessary information, I’m trying to provide a more explicit hint to encourage students to more strongly consider writing their own implementation.
The change doesn’t really reflect that, though. It’s too vague, and personally, I’m not even sure how to interpret it.
How about something that can be applied across all tracks, without the need for an appendix:
Avoid using built-in functions or libraries that directly compute the square root. Instead, create your own approach to approximate or calculate the square root.
1 Like
Ooh, I like that.
I second this.
If we’ll be changing the problem-spec, it has to be something that is generally applicable across all tracks and ideally not vague.
Doesn’t this to without saying? Does saying this actually change anything?
Change compared to the existing instructions? Or the instructions proposed by the OP?
Do you think it needs A/B testing? :) I just think the more explicit the instructions the better. I couldn’t actually find any implementations of a square root algorithm in the first couple of pages of the community solutions as nearly everyone just implemented something like “n ^ 0.5”.
To be honest, the intentions of this exercise are unclear to me. Is it meant to be an open-ended problem, allowing different approaches to calculate the square root? Is the use of built-in functions discouraged?
One could argue that the Wikipedia links on square root calculation methods are sufficient, so additional guidance might not be necessary. However, given that many implementations currently use built-ins, two possibilities come to mind: either people are opting for convenience over creating their own methods, or they haven’t fully understood the problem. Adding a clarification might help, assuming the intention is to avoid built-ins.
That was my thinking, yes. I just found “sort by higest rep user”, which suprisingly still shows a lot of “n ^ 0.5” but at least surfaces a few more interesting solutions. That suggests that even many high rep users opted not to implement an algorithm (from Wikipedia or elsewhere). And that makes me wonder if the existing instructions are sufficiently clear about the intended educational benefits (and enjoyment!)
Probably a topic for a different forum, but maybe there should also be a “sort by most starred”?
Apparently it’s not clear enough from the existing doc. In the JS track we have this addendum:
The idea is not to use the built-in javascript functions such as
Math.sqrt(x),x ** 0.5orx ** (1/2), it’s to build your own.
I think people not understanding the problem plus the fact that there is already built-in convenient methods of solving this with a one-liner is what contributes to the confusion. From what i’ve seen, a lot of people would rather write/copy a one-liner that they don’t fully understand just to keep it as brief as possible, because for whatever reason they see brevity as clarity, which shouldn’t necessarily be the case.
It might be better to mention that using built-in methods is discouraged so people at least try to implement their own algorithm. The alternative would be to have some sort of test that would check for built-in or common solutions, but I don’t know how to do that on a general level, and not on a track level.
Is there a way to see the addendums for all tracks together, and thus see common trends?
To my knowledge, no.
You could search each github repoby hand, or automate it if you use a slug for the track name and see which tracks return a 404 and which ones return the instructions.append.md file.
I still think that adding something along the lines of what @tasx suggested is okay and would resolve this.
It could get even worse. If people browse the community solutions and see that most use built-in functions, they may assume this is acceptable or even intended. Obviously, anyone can solve it using a built-in, but if that’s the case, it means the exercise has essentially failed to achieve its intended purpose.
1 Like
And yet the most submitted solution on that track still uses the built in method.
I’m not saying it’s perfect but I think it’s worth pointing out clearly.
As I said, a better solution would be to have a test for built-in method use, but that would have to be on a per track basis.
1 Like