Moving generic instructions from Python addendum to overall problem specification

The reasoning came from looking at the original discussion from when the exercise was first implemented and it looks like it was always designed as a perfect square exercise. These is a specific point about all the tests being perfect squares and all the expected output being whole numbers, so I thought it may be helpful to mention.

Looks like the author intended to implement a more generalized exercise, but I don’t know if this ever got anywhere.

Also, as far as I’m aware, there isn’t a distinction in terms of the actual math, between perfect and non-perfect squares. However, perfect squares are easier to use to explain the concept since most people can do napkin math and work with whole numbers easier than with floating point numbers. I feel that this would fall into the lying-to-children type of simplification.

True, the usual algorithms make no distinction about the type of the input. But that’s exactly why imposing an extra restriction would artificially increase the difficulty—people would get confused about how to create an algorithm that works with perfect squares. It makes the problem sound more difficult than it really is, and we already know that it’s a difficult problem for most.

I would also like to point out that a major issue is the inclusion of those wiki links regarding root calculation methods. Everyone will likely freeze if they’re presented with an endless list of incomprehensible math. It’s like throwing someone into the middle of the ocean and expecting them to find their way to shore.

I believe we’d get more value from the exercise if the focus is on implementing a specific algorithm.

My view is that the specifications should state that only an integer approximation to the square root is required in the result, and leave it to the students to determine whether they only wish to handle perfect square inputs which is sufficient for the tests.

Hmm. I chose to implement Heron’s Method with a log base 2 initial estimate using the bit_length() builtin, but there are also several simple integer algorithms on the Wikipedia page for Integer square root and I think we should be happy for students to consider the linear and binary search algorithms which may be easier to understand.

Okay so how about changing the bit about perfect squares to this:

And instead of relying on the wiki links, we can also add an explanation of a couple of algorithms, or links to such explanations. The wiki links can stay as a sort of ‘learn more’ section for the ones that are curious.

Sounds good. Explain a few algorithms and let the students pick, just like binary search is explained.

Okay then, I’m glad we have reached an agreement.

@xanni - Would you like to draft a new description?
You can use my suggestion as a base (in case we all agree that works) and add the paragraph about different algorithms, as well as take care of the links in the ‘learn more’ section.

OK, I’ve tried to incorporate the latest suggestions and also make it a little more concise:

1 Like

I’ve added a couple of comments.

I think this is a great overall change. Thanks everyone for weighing in on a complex discussion.

I think maybe we need to just come up a little further from the details in this bit:

- As input you’ll be given a positive whole number, i.e. 1, 2, 3, 4…
- You also only need to output a positive whole number.

Why is this? Is it because we’re approximating/rounding etc? I think we should expound the “why” here a little bit (or in the story).

1 Like

Thanks everyone for the great discussion and for getting to a consensus.

4 Likes

Thanks for your patience and willingness to move this forward.

And thank you to everyone who got involved.

3 Likes