Find the difference between the square of the sum and the sum of the squares of the first N natural numbers.
The square of the sum of the first ten natural numbers is (1 + 2 + ... + 10)² = 55² = 3025.
The sum of the squares of the first ten natural numbers is 1² + 2² + ... + 10² = 385.
Hence the difference between the square of the sum of the first ten natural numbers and the sum of the squares of the first ten natural numbers is 3025 - 385 = 2640.
For installation and learning resources, refer to the exercism help page.
For running the tests provided, you will need the Minitest gem. Open a terminal window and run the following command to install minitest:
gem install minitest
If you would like color output, you can require 'minitest/pride' in
the test file, or note the alternative instruction, below, for running
the test file.
Run the tests from the exercise directory using the following command:
ruby difference_of_squares_test.rb
To include color from the command line:
ruby -r minitest/pride difference_of_squares_test.rb
Problem 6 at Project Euler http://projecteuler.net/problem=6
It's possible to submit an incomplete solution so you can see how others have completed the exercise.
require 'minitest/autorun'
require_relative 'difference_of_squares'
# Common test data version: 1.1.0 7a1108b
class DifferenceOfSquaresTest < Minitest::Test
def test_square_of_sum_1
# skip
assert_equal 1, Squares.new(1).square_of_sum
end
def test_square_of_sum_5
skip
assert_equal 225, Squares.new(5).square_of_sum
end
def test_square_of_sum_100
skip
assert_equal 25_502_500, Squares.new(100).square_of_sum
end
def test_sum_of_squares_1
skip
assert_equal 1, Squares.new(1).sum_of_squares
end
def test_sum_of_squares_5
skip
assert_equal 55, Squares.new(5).sum_of_squares
end
def test_sum_of_squares_100
skip
assert_equal 338_350, Squares.new(100).sum_of_squares
end
def test_difference_of_squares_1
skip
assert_equal 0, Squares.new(1).difference
end
def test_difference_of_squares_5
skip
assert_equal 170, Squares.new(5).difference
end
def test_difference_of_squares_100
skip
assert_equal 25_164_150, Squares.new(100).difference
end
# Problems in exercism evolve over time, as we find better ways to ask
# questions.
# The version number refers to the version of the problem you solved,
# not your solution.
#
# Define a constant named VERSION inside of the top level BookKeeping
# module, which may be placed near the end of your file.
#
# In your file, it will look like this:
#
# module BookKeeping
# VERSION = 1 # Where the version number matches the one in the test.
# end
#
# If you are curious, read more about constants on RubyDoc:
# http://ruby-doc.org/docs/ruby-doc-bundle/UsersGuide/rg/constants.html
def test_bookkeeping
skip
assert_equal 4, BookKeeping::VERSION
end
endclass Squares
def initialize(number)
@number = number
end
def square_of_sums
sum = 0
(0..@number).each do |num|
sum += num
end
sum * sum
end
def sum_of_squares
sum = 0
(0..@number).each do |num|
temp = num * num
sum += temp
end
sum
end
def difference
self.square_of_sums - self.sum_of_squares
end
endA huge amount can be learned from reading other people’s code. This is why we wanted to give exercism users the option of making their solutions public.
Here are some questions to help you reflect on this solution and learn the most from it.
Community comments
Whenever you have a loop that is modifying a variable in each iteration of the loop, consider a functional programming approach. It will usually result in less code setting up and returning variables, which makes the code that actually does the intersting stuff stand out more.
Any time you are taking every element of an array and want to produce another array with modified variables, you can use map. And any time you have an array and want to use each value in the array to construct a single result at the end, you want reduce.
Also, you can almost always call methods on an object from other methods on that object without self
Thanks for commenting!
When you mention functional programming, are you suggesting that I create a method for iterating over the the arrays, and calling that method within #square_of_sums and #sum_of_squares?
Thanks for the nitpick, this is so helpful!
You don't have to create a method, but you could if you wanted. Ruby's block syntax is helpful, and you're already using it correctly with .each :)
To explain the difference, let's imagine you have a short array of integers, and you want to create a new array with all those integers incremented by one. You might do it like this: def add_one_to_array(old_array) new_array = []
old_array.each do |element| new_array<< element+1 end new_array end
That will work just fine. And because you've probably written tons of loops just like that one, it feels intuitive. But I would argue you can make the code much clearer, while doing the same thing, and reducing the chance of bugs sneaking in. Here's how: def add_one_to_array(old_array) old_array.map do |element| element + 1 end end
When you call .each on an Enumerable (the module that handles all sorts of stuff regarding working with arrays and other collections), all .each does is do whatever is in the block (everything inside the do...end in each method is a block) you passed it. thats why the block code in the first example has to actually do the heavy lifting of pushing data into the new_array variable.
The .map method on Enumerable does a bit more for you: it uses the return value of the block you pass to it, and collects all the return values from running the block with each element, turning that into a new array. You don't have to bother creating a variable and assigning it into an empty array, explitly updating the array, or even returning the array (because the return value of .map is the array that results).
It also tells everyone reading the code something very important: the code that follows takes some code and uses it to transform one array into another. With .each, it could do anything, so you have to carefully read the code to ensure it doesn't do something weird.
There's a whole bunch of helpful methods defined on Enumerable, and the docs are quite helpful. They all do different things, but the idea is similar: they all work on a collection of some sort, and each one can be thought of as a single, specialized, powerful tool. Go read through them and fool around with a couple.
Right, makes perfect sense. Thanks you for your input!