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.
@xanni - I think we should stick to the merits of your proposed change and not derail things with an added debate over TDD.
If you want to discuss TDD and Exercisms strong focus on it, I would recommend that you do so in a new, separate thread.
A student gets out of an exercise what they put into it to be honest. If they want to hardcode values, that’s their prerogative, and they’re only cheating themselves out of the full experience of solving the exercise as intended.
As long as the documentation doesn’t contradict the test suite, we’re okay. But if the docs mention non-squared inputs, we should have test cases for that. That likely raises the overall difficulty for most tracks as well.
Click to see the long version.
I had almost mentioned the wording of “compute” since that is not required, to pass the tests. We could as easily do a lookup, as you say.
That said, it is not our purpose (exception would be the concept exercises) to guide the way in which a solution is arrived, the tests only providing that a problem is solved.
There is nothing “wrong” if the tests are passed because the student decides to do anything that causes the tests to pass. There might even be something learned from doing so.
What the students consider is for the most part left to them. Hopefully we provide an engaging exercise, but what they want to learn from it (as practice exercises) are intentionally left up to them, with few exceptions.
True, the links aren’t really that helpful. Most people dislike math, so it’s only natural to reach for the most convenient solution.
Pre-existing math functions or libraries. Hmm, so x ** 0.5 doesn’t really look like a function call or a library. Permitted 
No need to mention anything about radicands. The square roots of x, by definition, are the numbers y for which y² = x. We only use the word radicand to denote a number beneath the root sign, which is purely representational. That’s all. The typical mathematical expression is simply:
Given a natural number, compute its square root
This is also accurate. I wouldn’t add anything more, as I’m well aware that people tend to be very allergic to math.
Complex numbers as a concept? That sounds interesting! I’ll see if I can come up with something. Teaching math can be tricky, no doubt about that.
With all that said, seeing three threads discussing an exercise with only five sentences—and still not reaching a conclusion—is, at least to me, an unpleasant experience. It’s neither healthy nor a good use of anyone’s time. I’m really sorry, but I don’t know how else to put it. When solutions are littered with x ** 0.5 approaches, almost any change is likely better than none.
This solution isn’t wrong. This exercise gives students the opportunity to implement their own square root. The purpose is not to force them to do so. If students read the exercise, understand the challenge and decide they hate math and don’t want to implement square root themselves, but prefer x ** 0.5, that’s entirely acceptable. The goal is to make them aware they can re-invent the wheel, and no more.
You said the magic words: Engaging exercise.
This holds true if students attempt to solve the exercise without using built-in functions—which isn’t likely if we simply say, ‘Compute the root; here are some links.’
The exercise needs to be presented in an engaging way, which admittedly requires a bit of creativity on our part.
I don’t disagree with that. However, nobody is going to implement their own square root function just because they’re made aware of alternative methods. A good teacher finds ways to make the presentation engaging and guides students toward discovering something new. A bad teacher simply throws in a few links and leaves. That’s how I prefer to think, at least, when teaching in real life.
In other words, I don’t expect any of the proposed changes so far to make any difference.
Anyway, I digress.
We added ** to the Python instruction append. 
You beat me to it. I was in the process of typing that if we have this much debate over two sentences in the exercise, perhaps it is not an exercise we should be offering.
If this exercise doesn’t teach anything about fluency in a given programming language, or offer some challenge that leads to fluency in that programming language - should it be a practice exercise at all?
And what is fluency here? Is it always about reinventing the wheel, or can it be about unusual methods to accomplishing your goal? Would fluency look different in Fortran than in Python? What about Julia or JavaScript or Rust or Scheme?
Sometimes fluency is simply being aware there are multiple ways to solve something, and picking the most appropriate for the situation.
Agree that an engaging exercise is the key: preventing, admonishing, directing — none of that really works. Any student not really engaged is going to just look something up and then move on. And maybe we should let them.
BUT - what could we do with these instructions and/or a story/scenario that would better hook students who weren’t in love with the math? What programming situation could we invent that would point them toward something else? One exercise I can point to that does this pretty well is Saddle Points, with its tree-house story. Is there something similar we could do here?
Maybe we should rethink all of it, rather than trying to patch something that is basically “do math for us, plz”.