Clearly mark all math-y exercises as such

[kytrinyx]

After talking to @loriking, @amaliacardenas (who are working on Exercism this summer) and @ashleygwilliams (who is on the Rust team at Mozilla and teaches Rust to people on a regular basis) I've realized that the best exercises on Exercism are centered around a story, and that they are not filled with jargon.

In particular, all of the math-specific exercises are problematic, because there are a lot of people who find math intimidating and foreign. Now, the math exercises are great--if you enjoy math--so I don't want to get rid of them entirely. Instead I would like to do two things in the config.json:

• mark each of these exercises clearly with the topic 'mathematics', and
• ensure that they are optional (core: false)

I've identified the following exercises as being math-y (list updated per comments below)

• all-your-base
• armstrong-numbers
• binary
• collatz-conjecture
• complex-numbers
• difference-of-squares
• hexadecimal
• largest-series-product
• nth-prime
• octal
• palindrome-products
• pascals-triangle
• perfect-numbers
• prime-factors
• pythagorean-triplet
• rational-numbers
• sieve
• sum-of-multiples
• trinary
• diffie-hellman
• affine-cipher

I've explicitly not included 'grains', since it has a story, even though we are doubling numbers. But I'm willing to be convinced that it should be marked with 'mathematics' as well. I'm more and more convinced that this one is more programm-y than math-y.

Are there other exercises that you would consider math-y?

I'm opening PRs with sample changes on the Rust, Erlang, Haskell, and C# tracks, as I often get good feedback and input when I submit PRs to them, and I figured it might help kick-start this discussion.

[iHiD]

@kytrinyx Thanks for this. I thing it's a wise thing to do.

I dislike mentoring Grain because I don't know how to explain the exponential operator to someone who doesn't know it. And it's something I've never used in the real world, so I feel unsure even why I'm explaining it. So I'd vote for Grains to have it too.

Two thoughts:

1. Should we have a rule that maths things should not be core?
2. Could we use the "maths" (or "math" if we must :)) tag in stead of mathematics - just because in the UI that will crop all the other tags off as there's limited space? I appreciate that's probably a big pain after you've scripted the PRs. Sorry.

[NobbZ]

Even though erlang has collatz-conjecture as a side quest currently, I thought about taking it into core, as it simple rules are in my opinion much better suited to show students how to (and that you actually can) use a recursive function for more than just two cases.

Collatz does expose this so much better than an arbitrary tree like data type or an artificial calculation I had to find in the pool of available exercises first.

Also some languages might have a stronmger background in a Mathworld, I think it would be bad for them if we forbid mathy exercises as core. For those languages non-mathy exercises might look contrived or introduce advanced concepts too early.

---

RE grains/exponantial operator: I consider it important that programmers of any language do know about the rule-of-two in CS. The ultimate answer to grains does not use 2^x (or equivalent), it uses a bitshift. It does not calculate the total by summing all the fields, but it takes MAX_UINT_64 (or equivalent). So this is a funcamental exercise which should come early, but this concepts might ultimatively hard to grasp for some (Some of my co-students managed to get their bachelor without having understood that numbers can have different bases) so its more like an exercise which should be unlocked by the harder ones... This exercise in particular is hard to align between the others.

[petertseng]

Okay, I think I am seeing it.

So, having to distinguish between exercises that might be solved using maths, but have a story to go with that, as opposed to exercises that are purely about maths.

I can see that this is why these following exercises are not in this category.

• while on the surface alphametics look to be about mathematical equations, solving it is more about the constraint solving.
  • https://github.com/exercism/problem-specifications/blob/master/exercises/alphametics/description.md
• while book-store and change require computing the total of some books or some set of coins, solving them is more about the optimisation problem
  • https://github.com/exercism/problem-specifications/blob/master/exercises/book-store/description.md
  • https://github.com/exercism/problem-specifications/blob/master/exercises/change/description.md
• while matrix and saddle-points deal with matrices, a mathematical concept, solving them doesn't really involve computation (saddle-points requires comparison, but I imagine it is possible to easily understand and deal with comparison)
  • https://github.com/exercism/problem-specifications/blob/master/exercises/matrix/description.md
  • https://github.com/exercism/problem-specifications/blob/master/exercises/saddle-points/description.md

What do you think about exercises dealing with bitwise representations?

• allergies and secret-handshake may be done with bitwise operators, but both have stories to go along with
  • https://github.com/exercism/problem-specifications/blob/master/exercises/allergies/description.md
  • https://github.com/exercism/problem-specifications/blob/master/exercises/secret-handshake/description.md
• variable-length-quantity deals exclusively with bitwise representations, and doesn't really have a supporting story
  • https://github.com/exercism/problem-specifications/blob/master/exercises/variable-length-quantity/description.md

In addition, I'm obligated to ask about those exercises that do have a story... but solving them does end up involving maths in whole or in part. As follows:

• affine cipher specifically relates each ciphertext letter to each plaintext letter by a mathematical relation (there are other cipher exercises: atbash, rail-fence, rotational, simple, but I did not think them heavy enough on maths)
  • https://github.com/exercism/problem-specifications/blob/master/exercises/affine-cipher/description.md
• The two latter steps done in diffie-hellman involve implementing a mathematical formula given in the description
  • https://github.com/exercism/problem-specifications/blob/master/exercises/diffie-hellman/description.md
• both luhn and isbn-verifier are in the same category of checksumming a number in some way:
  • https://github.com/exercism/problem-specifications/blob/master/exercises/isbn-verifier/description.md
  • https://github.com/exercism/problem-specifications/blob/master/exercises/luhn/description.md

As long as a line can consistently be drawn, then we can know what to do with those.

[ErikSchierboom]

In general, I like the idea. Part of the reason why I like exercism so much over e.g. project euler is that the latter has as its main focus mathematics, where programming is just a tool to have the mathematics execute efficiently. In exercism, the reverse should be true: mathematics should just be a tool to solve a problem, not the main focus.

Personally, I feel like exercises that use bit manipulation don't necessarily belong to the mathematics category, it is more computer science than math I feel.

The affine-cipher exercise's README is I think enough evidence of being "mathy," as is the diffie-hellman exercise IMHO.

For some reason, I don't believe luhn and isbn-verifier fall into the math category, but I am not able to articulate why I have that feeling.

[kytrinyx]

I dislike mentoring Grain because I don't know how to explain the exponential operator to someone who doesn't know it.

Interesting. I like Grains, and I think it's more computer-science-y than math-y (for the reasons that NobbZ describe)

Should we have a rule that maths things should not be core?

I don't want to make it a rule, because some languages are very math heavy, so they should be free to do so if it makes sense, but I would like to recommend to avoid it in general.

Could we use the "maths" (or "math" if we must :)) tag in stead of mathematics

Sure, I used mathematics because it was already present in the Rust track topics. We decided to go with American English spelling when this came up for the website, so I'll go with math.

Even though erlang has collatz-conjecture as a side quest currently, I thought about taking it into core, as it simple rules are in my opinion much better suited to show students how to (and that you actually can) use a recursive function for more than just two cases.

I'd love to see if we can come up with a story-like exercise that gives you the same recursive challenge/benefit, but doesn't involve lots of math jargon.

So, having to distinguish between exercises that might be solved using maths, but have a story to go with that, as opposed to exercises that are purely about maths.

@petertseng Yes! Thank you for articulating that. sum of squares is about math, but Grains can be solved using math. Alphametics is a great example--it has the shape of basic arithmetic, but it's not really about math at all.

while matrix and saddle-points deal with matrices, a mathematical concept, solving them doesn't really involve computation

Yeah, I agree. I didn't include them because they don't have big, intimidating math-y explanations. People can think about it in terms of nested arrays or nested loops.

What do you think about exercises dealing with bitwise representations?

I think these could be labeled as bitwise or bits or something. I think they're not math-y and very crucial to programming.

variable-length-quantity deals exclusively with bitwise representations

We could potentially add more story to it, I think, but I believe it's fundamentally a decent exercise.

affine cipher specifically relates each ciphertext letter to each plaintext letter by a mathematical relation (there are other cipher exercises: atbash, rail-fence, rotational, simple, but I did not think them heavy enough on maths)

I think you're right that affine cipher should be marked as math.
(I think we should probably have a cipher or crypto or something tag as well, for all of the cipher ones).

diffie-hellman involve implementing a mathematical formula

Yepp. Definitely math!

luhn and isbn-verifier are in the same category of checksumming

I'm with Erik on this one; I think checksums are a more computer-specific thing that should be fine. We may need to add more friendly explanations to them if people still find them intimidating, though.

[kytrinyx]

To summarize this:

• I added diffie-hellman and affine-cipher to the list of math-y exercises.
• I didn't add grains (still open to discussion, but feel surprisingly strongly about this one)
• I will change to use math instead of mathematics
• I will submit PRs to all the tracks

[petertseng]

Discussion on this topic has moved to #4186

What is your desired level of maintenance for this after these PRs are merged? The current operation is a one-time sweep that brings the state of the world to a desired state, but various operations in the future could cause the world to get out of that state.

Suppose that a contributor now adds the affine-cipher to a track that didn't have it. Who or what (if anything) will tell that contributor that math should be one of its topics?

[rpottsoh]

Perhaps comments should be added to all the testdata files that have been identified as mathy. Seems like we need to establish a policy for identifying new exercises as mathy going forward.

[kytrinyx]

Yes, we'll need a way to ensure that exercises get their canonical topics. I'll think on it.

[petertseng]

Discussion on this topic has moved to #4186

It sounds like there may be a justifiable case for having a track-independent list of topics to be associated with each exercise.

Of course, tracks will may want to add their own track-specific topics; that is fine.

One may also wonder whether tracks may want to remove a track-independent topic. I have not yet thought of a exercise/topic/track triplet where removal is desired.

But track maintainers would have to be aware of such a thing, otherwise they will get confused about where their topics are coming from.

[rachelhornung]

I don't know, but isn't a little force sometimes helpful? If you can always avoid math, you'll never get comfortable with it. I would have avoided many of the text formatting exercises. But that doesn't help me learn new concepts...
So, I agree that consistent math tagging would be helpful. But I wouldn't really want to see all math moved out of the core exercises.

[ashleygwilliams]

Re math exercises: I think it really depends on the goals of exercism. When I teach Rust, I have plenty to teach and very very little time. I can teach all the Rust syntax and concepts I would need to without touching on Math at all. In fact, I spend all of my days as a language and dev tools developer not doing any explicit math at all. Sometimes I bring math in, because it is fun and often useful, but it's completely orthogonal to the primary things I need to do as a professional research engineer and language developer. If I can get away with no math as a research engineer, I don't think someone who is trying to learn a language for the first time should be confronted with any math.

There's lots of stuff that folks should learn, but as the old adage goes, "do one thing well". I'm not convinced that exercism should be a math learning platform, certainly or at least not until it becomes a great programming learning platform first. As a result, I strongly would encourage us to remove math from the core exercises.

Regardless of what exercism does as a platform, for the Rust team, it's clear that us using the Rust track as a learning platform in our core sponsored education programs will be dependent on it focusing on Rust concepts and syntax and avoiding any additional subject (math included).

(I've already discussed this a bunch with @kytrinyx but I really wanted to reply to "isn't a little force sometimes helpful" - as someone with a lot of experience teaching folks from a large variety of backgrounds, I can say very confidently that no, it doesn't, at least not in this specific instance.)

[petertseng]

It looks like my comments have transcended the math topic. I will take my comments else where. Thank you.

[kytrinyx]

isn't a little force sometimes helpful

It is, yes, and for concepts like munging strings or bitwise operations I would definitely consider it relevant to Exercism. Math, on the other hand (as @ashleygwilliams so elegantly describes above) is orthogonal to the goal of fluency in the basics of a programming language.

I'd like to keep it available for the folks who enjoy the deep dive, or for folks who want to challenge themselves, but it really isn't aligned to Exercism's goals to keep them in the core.

[rachelhornung]

I get what you are saying and I agree that exercism shouldn't be about learning maths.

My take on it is rather, that a lot of the "math-heavy" exercises, don't really need a fancy formula to be solved. Rather, you have to be able to translate the problem statement into code. You kind of want to get past the paraphrasing, no matter which domain the description stems from.
So my question really is, is math that much more intimidating than other descriptions?

Sorry, I did not want to spam the issue. But I'm personally curious on your opinion.

[kytrinyx]

@rachelhornung My impression is that a lot of jargon-y exercises are intimidating, no matter the domain. For most of them, I'd love to find a way to rephrase them so that they're not full of jargon, as that can help reduce the intimidation. For the math ones, the first step is just to get them out of the way (they're apparently very intimidating, especially when the readme is full of formula-looking stuff).

Here's a great example of rephrasing to be a lot more approachable:
#4155

Another way to make some of these more approachable would be to add a story around them. This isn't Exercism-related, but I did this with some concurrency exercises:
http://whipperstacker.com/2015/10/05/3-trivial-concurrency-exercises-for-the-confused-newbie-gopher/

[macta]

Isn't sum-of-multiples more about iteration - and the math (which is very little) is just an easy way to tell that you've iterated correctly?

I think you need to be careful about throwing the baby out with the bathwater.

If the complaint is more about getting stuck on a locked/core exercise because its too maths'y - you could rephrase the jargon a bit - but also provide a way in exercism to have several compatible exercises "unlock a level" - so if I don't like "sum-of-multiples" is there some other iteration like problem that takes my fancy instead.

It seems to that the bonus idea could go a bit further in this direction somehow.

[kytrinyx]

Isn't sum-of-multiples more about iteration - and the math (which is very little) is just an easy way to tell that you've iterated correctly?

That's a fair point. I think if we could rephrase it to be less jargon-y, I'd be happier to leave off the "math" label, and leave it in core.

[kytrinyx]

The remaining open PRs are stuck because of unrelated failing builds. I'm going to leave it to the maintainers to merge when the builds are sorted out, and call this "closed".

The list of "math-y" exercises is not set in stone—I will keep pondering this, especially the exercises that are somewhere on the edge (or sound math-y but aren't really, like sum of multiples). Thanks for the discussions, everyone.