## Problem Description

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6, and 9.

The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

## Simple Solution

The simplest solution is to iterate over all numbers up to the limit.

If any of these numbers are a multiple of one of the factors then it is included in the summation.

1 | `public static ulong SumFactorMultiplesBelowLimit(int limit, params int[] factors)` |

Timing the operation yields:

Minimum Elapsed: 00:00:00.0000114

Average Elapsed: 00:00:00.0000545

Maximum Elapsed: 00:00:00.0004331

Pretty quick, but that is most likely because the problem space is small.

If the limit is increased, or if more factors are introduced the number of operations performed is increased.

In big-o notation, this approach is $$ O(n * m) $$.

## Asynchronous Simple Solution

Note, this particular approach is not recommended for the problem as it is layed out in the description but is included to compare results and as a thought experiment.

This solution could possibly be viable if the number of factors used increased and there was a mechanism to reduce the amount of duplicated iterative work performed.

Another possible way to structure a solution to the problem is by giving each factor provided a thread to calculate the multiples up to the limit it has.

Once each thread has completed, the resulting multiples are compared for matching numbers that are used to generate a sum:

1 | `public static async Task<int> SimpleSumFactorMultiplesBelowLimitAsync(int limit, params int[] factors)` |

The iterative work for this solution was extracted to a helper method in order to parallelize it:

1 | `public static async Task<ICollection<int>> GetFactorMultiplesBelowLimitAsync(int limit, int factor)` |

This is not the prettiest solution by any stretch and yields slightly worse results than the Simple Solution:

Minimum Elapsed: 00:00:00.0000317

Average Elapsed: 00:00:00.0002025

Maximum Elapsed: 00:00:00.0017206

The results are not surprising because of how the work is performed.

There are two or more loops iterating over all of the numbers - duplicating the amount of operations and comparisons that must be done.

One possible improvement for this solution could be to have a single shared collection of possible numbers that would be updated to reduce the number of iterations that are performed by each thread instead of joining the results after they have all completed.

This could also introduce a race condition so a thread-safe data structure is recommended if this approach is taken.

Another possible improvement would be to start with the largest factor from the available factors so that the initial set of numbers is the smallest starting point that it could be to iterate over.

As stated before, this is not a recommended solution when the number of factors is small since the iterative work is duplicated.

The only redeeming factor of this approach is that the work is done on multiple threads so if two threads are available at the same time it may appear that the solution is the same as the Synchronous Simple Solution.

This can be seen in the `Minimum Elapsed Time`

measurement being comparable to the `Average Elapsed Time`

in the previous results.

## Simple LINQ Solution

The Simple Solution can be converted into a more fluent LINQ syntax - at the cost of some performance:

1 | `public static ulong SimpleLinqSumFactorMultiplesBelowLimit(int limit, params int[] factors)` |

The type cast is necessary to convert the `Sum()`

operation to the return type.

This could cause a little performance degradation but was not significant in the measurements.

This solution reads a little easier to read and possibly understand since it reads like a sentence.

The results of this solution are:

Minimum Elapsed: 00:00:00.0000574

Average Elapsed: 00:00:00.0001152

Maximum Elapsed: 00:00:00.0006285

As expected, this is slower than the simple solution but still fast.

The tradeoff could be worth it for the improved read-ability.

Surprisingly, this solution is actually slower than the asynchronous solution in some scenarios - seen by comparing the `Minimum Elapsed Time`

of the two results.

## Algorithmic Solution

The simple solution satisfies the criteria to generate an answer, but the performance can be improved by looking for an algorithmic solution instead of a brute-force solution.

Conveniently, the problem is asking for a solution to a **Finite Arithmetic Progression**, specifically an **Arithmetic Series** which has an algorithmic solution.

… a sequence of numbers such that the difference between the consecutive terms is constant.

… The sum of the members of a finite arithmetic progression is called anarithmetic series.

… [The] sum can be found quickly by taking the numbernof terms being added, multiplying by the sum of the first and last number in the progression, and dividing by 2:

The equation for solving this kind of problem is:

$$\begin{equation}

n(a_1+a_n)\over2

\end{equation}$$

In this equation:

- $$ n $$ is the number of terms being added.
- $$ a_1 $$ is the initial term.
- $$ a_n $$ is the last number in the progression.

Using the value 3 from the problem description’s example in this manner yields the following progression:

$$ 3 + 6 + 9 $$

The $$ n $$ in the algorithm can be solved for by taking the limit and dividing it by the starting term in the progression and discarding any remainder.

When substituting values into the equation it becomes the following:

$$\begin{eqnarray}

3(3 + 9)\over2

&=& 3(12)\over2

&=& 36\over2

&=& 18

\end{eqnarray}$$

With this algorithm, the sum for each specified multiple can be calculated.

Keep in mind that all shared multiples for all factors must be subtracted.

In the problem description this would be $$ 5 * 3 = 15 $$ if the limit was larger than the multiple (15 in this case).

## Synchronous Algorithmic Solution

A synchronous solution for this problem with only two factors could look something like this:

1 | `public static async Task<int> AlgorithmicSumFactorMultiplesBelowLimit(int limit, params int[] factors)` |

The `AlgorithmicSumFactorBelowLimit`

method looks like this:

1 | `private static int AlgorithmicSumFactorBelowLimit(int limit, int factor)` |

The limit is subtracted by one when calculating $$ n $$ so that factors that evenly divide the limit do not generate an off-by-one error.

The performance of this solution is:

Minimum Elapsed: 00:00:00.0000007

Average Elapsed: 00:00:00.0000011

Maximum Elapsed: 00:00:00.0000045

Initially, I had the algorithmic method asynchronous to share code but wanted to ensure there was not any skewing of results that may have occurred from using `.GetAwaiter().GetResult()`

.

Spoiler alert, the results were approximately the same in both - meaning there probably would not have been any perceptible difference in the results.

## Asynchronous Algorithmic Solution

1 | `public static async Task<int> AlgorithmicSumFactorMultiplesBelowLimitAsync(int limit, params int[] factors)` |

And updating the algorithm to be asynchronous as well:

1 | `private static async Task<int> AlgorithmicSumFactorBelowLimitAsync(int limit, int factor)` |

Measuring the performance of this solution generated:

Minimum Elapsed: 00:00:00.0000006

Average Elapsed: 00:00:00.0000010

Maximum Elapsed: 00:00:00.0000022

In this case the asynchronous solution impacts the performance results positively because each thread is able to contribute to solving the problem without duplicating any of the work.

Because each thread is able to do work in isolation, this solution will scale well even as the number of factors increases - as long as there are threads available to do the processing work.