My original idea was to more subtly engage the interest of students by including a hint that suggests a challenge. But I also like the very clear phrasing provided by tasx. If possible I’d actually like to do both!
we can add the suggestion by tasx (or similar) to the problem-spec
and I suppose you can make an instructions.append.md
for the specific track you want to provide an extra hint.
I should also note that BethanyG already pointed out to me in a previous discussion that Exercism can’t and doesn’t seek to make students engage with the learning opportunities - if they choose to just get a passing test maybe that’s all they wanted out of it. But I do wonder if having a “most starred” sort and making that the default rather than the “most submitted” would surface better examples.
May i propose something different. The very first line of the instructions states:
Given a natural radicand, return its square root.
Why would anyone read further if they already know how to solve it using built-ins? Perhaps we could make the purpose of the exercise immediately clear:
Given a natural radicand, approximate or calculate the square root without using built-in functions or libraries that directly compute it.
Even better. Note also that the tests assume but the existing first line doesn’t explicitly state that the range of the results are also expected to be in the set of natural numbers; it only gives the domain of the inputs. How about this:
Given a natural radicand, approximate or calculate the natural square root without using built-in functions or libraries that directly compute it.
The tests aren’t exhaustive so we can’t make any assumptions. If people want to devise an algorithm that computes the square root for any number, that’s fine.
I’m not a fan of changing the first line like that. The first line is supposed to introduce the topic and be simple. If students choose not to read further and engage, that’s their prerogative.
I just realised that if the tests only use square numbers, then it preserves the ambiguity in the problem statement as to whether the implementation should provide integer or real roots for non-square numbers, and that allows students to implement either. Which is fine. Ignore my preceding comment.
Is it simple, though? The instructions begin by mentioning the term ‘natural radicand’ and then spend two more sentences explaining what it means. Why not just say:
Given a natural number, return its square root
So is it really surprising that most solutions use the built-ins? The instructions should be simple, clear, and should be fun and engaging, but there’s none of that here.
Why not something like
Given a natural radicand, return its square root.
Avoid using built-in functions that directly compute it. Instead try to approximate or calculate it.
[the rest of the instructions go here]
This way we’re not changing the simplicity of explaining the task, while also providing explicit instruction on what is expected.
That’s fine too, but I’m not particularly fond of the term ‘natural radicand.’ Since it already refers to the number below the root symbol, it essentially translates to ‘given a natural number under a root symbol, compute its square root.’
This phrasing is quite awkward. The term ‘natural radicand’ doesn’t seem to add any value here; it only complicates the instructions unnecessarily.
I don’t follow here.
The term radicand
literally means " the quantity under a radical sign *".
Maybe the confusion stems from the definition of square root, which I believe in this case is referring to the non-negative square root of a positive real number. Even the Wiki links we provide point to that.
If you’re confused about the “natural” part, this is equivalent to “integer”, so the term natural radicand
would mean √1, √2, √3
and not √3.1415
.
Exactly, and it’s not needed. We never say:
given a natural number under a radical sign, compute its square root
This is just awkward math terminology. We say instead:
given a natural number, compute its square root
Going to chime in here to list other related discussions:
The radicand
one
The Python instruction append
A similar debate about stringency
The “star” system dates from Exercism V1, and is not at all an indicator of “exemplar” or “outstanding”.
Before we had community solutions, we gave students the ability to star any solutions they thought were interesting or they wanted to come back to. But that means that many high-star solutions are outdated, or were done under older language versions.
And in the case of Python, we’ve got multiple places were someone thought something looked “cool”, so it got a bunch of stars even when that particular solution was very very unidiomatic.
@BethanyG All these discussions for nothing—just another topic that’s been beaten to death. I even forgot that I participated in one of these before. Some things are open to debate, but math isn’t one of them; it’s not opinion-based.
As a mathematician, this really saddens me. I’ll bow out of this discussion—I’ve already said enough.
Thanks, that’s very helpful.
Given that the additional suggestions appear to have all been discussed without resolution earlier, I’d like to return to my original suggestion: the hint that only natural numbers (not real numbers) need be used in approximating square roots of non-square natural numbers is currently present in the Python addendum but is not Python specific.
If reworded to be clearer, could this be moved from the Python addendum to the problem specification to encourage students to try implementing an interesting algorithm capable of handling non-square inputs?
Since the test suite only uses squared inputs, that’d be confusing to me as a student. The test suite is the source of truth on what’s expected, not the docs.
I’m a bit concerned about the strong emphasis on TDD here. TDD has its limits, and if taken to the logical conclusion then a perfectly valid way to pass the tests is just to implement a look up table that returns the expected results for each test given the input provided by the test, for every single exercise. I don’t think students should be encouraged to consider the tests as the only requirement, ignoring the documentation.
@tasx - I’ve found your participation really helpful. I just don’t think that directive phrasing (as opposed to issuing a challenge) would encourage students to implement square root formulas unless they are already inclined to. Many also won’t follow the Wiki link, and those who do might get lost in it, and give up.
Also keep in mind that it is not clear what we mean by “built-in”. In Python ALL operators are built in, as are things like sum()
. So we need to be careful.
It might complicate the instructions, but telling students that they could learn a lot by taking on the challenge of not using their programming languages pre-existing math functions and instead implementing one of two or three example formulas listed out might nudge their pride, as opposed to blocking them or “requiring” something.
Maybe something like:
While this can easily be solved with your programming
languages pre-existing math functions or libraries that
directly compute the square root for you, we would like you
to take on the challenge of creating your own approach
to approximating or calculating the square root.
While you wouldn't want to hand-roll a `sqrt` function
in production, doing so as a learning exercise can
teach you a lot.
We've provided ___ formulas below from the [wikipedia page]()
to get you started.
I also agree that the word radicand
could trigger both confusion and math panic (which is very real for folx) — I am just not sure what phrasing would be both unambiguous and precise enough.
Remember: we’re teaching programming language fluency - not (sadly) mathematical fluency. In fact, complaints in the past have been so loud and so sustained that Exercism as a whole has developed an allergy to “mathy” exercises.
It’s bad enough that I am totally stuck on how I teach complex numbers in Python (if you have ideas for a concept exercise, pleeeeeease DM me ), and have endured very loud complaining about our Currency Exchange
numbers exercise.