Proposal: Adding an "Intermediate Overflow" test case (Difference of Squares)

Programming Rust
1

Hi everyone,

I’d like to propose adding a specific, ignored test case to the Difference of Squares exercise to help students explore the concept of intermediate overflow.

The Problem

Many students implement sum_of_squares using the closed-form formula:
n * (n + 1) * (2n + 1) / 6

While this is mathematically optimal O(1), a standard u32 implementation in Rust will fail for n = 1290 due to intermediate overflow:

  • The final result for n = 1290 is 716,395,265 (fits easily in u32).
  • The intermediate product n(n+1)(2n+1) is 4,298,595,390.
  • The limit for u32::MAX is 4,294,967,295.

Even though the final answer fits in the return type, the calculation crashes in debug or wraps in release before the division by 6 occurs.

Proposed Test Case

I suggest adding this as a “bonus” test that is ignored by default. This ensures it doesn’t block the student from passing the exercise on the solution runner but serves as a great teaching moment for local development and mentorship.

#[test]
#[ignore]
/// This test checks for intermediate overflow. 
/// Even if the final result fits in a u32, the product of n * (n+1) * (2n+1) 
/// might exceed u32::MAX during calculation.
fn sum_of_squares_1290() {
    assert_eq!(716_395_265, squares::sum_of_squares(1290));
}

Why add this?

  1. Learning Opportunity: It encourages students to think about type promotion (as u64) or checked/saturating arithmetic.
  2. Mentorship: It provides a concrete entry point for mentors to discuss how Rust handles integer overflow in different build profiles.
  3. Real-world Robustness: It highlights that “mathematically correct” code can still be “computationally fragile.”

I’m happy to prepare a PR if the maintainers agree this adds value to the track’s pedagogical goals!

Best regards,
Jegors

2

Would this be Rust specific or would it make sense to move this into the problem spec?

3

Yeah, I think this belongs in problem specs. Most languages have fixed-width integer types.

4

For what it’s worth, I don’t think this needs to be added to the probspecs repo. I feel like this goes slightly beyond the goal of the exercise. Almost any exercise is too simple from a real world standpoint, but that’s also partly what makes them exercises where you can focus without all the production code safety guarantees one needs.

3 Likes
5

I’m with Erik here.

I’d also like to point out that Python, Ruby, JavaScript, C#, Haskell, EMACS Lisp, Erlang, Raku, Perl, Julia, Scala, Tcl, Nim, OCaml, Prolog, go(via module), and PHP (via module) all have built-in int types of arbitrary length.

And many more languages have commonly used outside libs (C, C++) that support arbitrary-length integers.

So it feels as though this is a test case that should be track-specific for those tracks where numeric type choices and overflow is core to programming considerations and general fluency, but not necessarily problem-specs.

2 Likes
6

I tend to agree with Erik.

While this topic may be relevant in some areas, it’s not entirely appropriate for general tasks like this one. Perhaps this subject could be interesting as a separate concept/exercise for some language tracks.

3 Likes