Moving generic instructions from Python addendum to overall problem specification

@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.

4 Likes
TL;DR: There is definitely a focus on other things besides TDD, and that is to not force specific solutions.

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.

1 Like

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 :slight_smile:

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.

1 Like

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.

1 Like

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.

2 Likes

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. :wink: :smile:

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”.

2 Likes

I’m really happy we finally seem to be getting to the heart of the issue - how to make this particular exercise interesting and engaging for students.

Personally, I enjoyed finding an implementation that converges after a very small number of iterations.

Might there be some students who enjoy looking up an algorithm on Wikipedia and implementing it? Those students might love this exercise. The students that hate math can opt to bypass this exercise by using the built in options.

Just off the top of my head, how’s this for a narrative:

We are launching an interstellar exploration rocket, and we will need a way to compute an approximate natural number square root in order to align the transmitter to maintain Earth communications. However due to the extremely limited amount of power available, we’ve had to choose a CPU that doesn’t have hardware floating point. Therefore we would like to implement our own reasonably efficient square root function that doesn’t need to use anything other than integers.

That story allows for the linear or binary search algorithms as well as successive integer approximation, among others.

From my experience, there’s no such thing. If you present math/anything in an unappetizing way, everyone is going to hate it. And when they don’t like something they’ll eventually get demotivated and leave. That might be fine, but leaving means less donations.

It might be better to remove the exercise altogether as Bethany suggested. ‘Exercism is fun, effective…’ — that comes straight from the landing page. Is this a fun and effective exercise?

The narrative is a start. Then what? We need a way to demonstrate that this problem is interesting and worth solving with the non-standard methods.

Okay, how about something like this:

We are launching a deep space exploration rocket and we need a way to make sure its coordinates are aligned properly with its target.

The first step in our coordinate calculation involved being given a number as input, and finding out which other number when multiplied by itself will equal our input number, or in other words, finding the square root of our input number.

Because the journey will take very long, we had to make our rocket’s onboard computer very power efficient, so it wouldn’t drain the batteries. Unfortunately that means that we can’t rely on fancy math libraries and functions, as they would take more power. Instead we want to calculate or approximate the square root by ourselves.

Your task is to implement a function that calculates or approximates the square root of a given number. Here are some constraints:

  • Try to avoid using the pre-existing math libraries of your language.
  • As input you’ll be given a positive whole number, i.e. 1, 2, 3, 4…
  • At this step of the calculation we’re only interested in “perfect squares” so you don’t have to worry about floating point numbers.

You can check out the Wikipedia pages on square root and methods of computing square roots to help with choosing a method of calculation.


I think this would make the exercise more engaging and it might discourage the use of buit-ins enough to have people actually get math-y. And it doesn’t prevent or contradict the tests so if a student wants to bypass all the math and use x ** 0.5 or other, then they can do so and there’s probably nothing that we can do to change that, outside of explicitly disallowing that with a test.


Also, I tried following exercism’s style guide, so less math domain specific terms to avoid confusion, even though I personally have no problem with radicand and the likes of it.

1 Like

I think we can make this exercise fun with a rework, and I feel that it’s a good teaching exercise, so it should stay.

In the end, no matter the exercise and how fun and engaging the wording is, if people want to write some sort of lookup table like solution or something equally unidiomatic, then there’s nothing we can do to stop them. I’d even argue that we shouldn’t attempt to stop them, just to discourage this sort of behaviour. It’s a great conversation point for a mentoring request for example and for iterating on your solution, which I feel is part of the idea of exercism.

2 Likes

Of course, the purpose of all this isn’t to prevent someone from opting for the easy solution, but rather to find a way to communicate an idea effectively and keep them engaged for as long as possible. Isn’t this what we should all be striving for?

2 Likes

Yep, i’d have to agree with you. Exercism isn’t really meant to have super restrictive guide rails, I think so people failing the task or just circumventing it by using an ‘easy’ solution is a reality we have to live with.

I think that the rework suggestion that I posted above makes the exercise interesting and engaging enough. I’m open to suggestions if you think it isn’t.

A very experienced educator once told me (not his exact words):

You are here to guide the students. It’s ultimately your responsibility to help them love something they may dislike.

So while there’s definitely value in simply clicking a button and seeing the tests pass, I firmly believe that Exercism is and should be more than that.


Your suggestion looks fine to me, as I’m not great at making up stories.

1 Like

Just to be extra clear about it, I’m not disagreeing with you. What you’re saying makes sense and I also subscribe to the idea of ‘properly’ teaching people.

My view is that, if people don’t want to be though, then there’s nothing you can do as a teacher to change it, no matter how good you are, and this makes it so hard to [...] help them love something they may dislike.


I think that I/we are getting off-topic however, so I’ll stop this discussion and I’d like to focus back to the relevant topic - reformulating the docs for the square-root exercise to make it more engaging and discourage the use of library solutions.

If anyone likes/dislikes my suggestion from above, or has one of their own, I’d be happy to hear and contribute to it.

It is indeed very hard. Nobody ever claimed it’s easy :slight_smile:

Then again, i would only have myself to blame if a student leaves.

Anyway, back to the topic.

This might be a little confusing. If the input is a whole number—1, 2, 3, 4—why are we suddenly talking about perfect squares and floating-point numbers? Also, could focusing on perfect squares make the exercise more difficult? Aren’t most square root algorithms designed to work with any positive real number? I feel that simply specifying positive whole numbers would be more than enough.