## Intro

## Contents

[Note: metacall base article]

I am currently in the stage of searching for simple but valid examples of metacall validity (aka: usefulness) as interfacing concept and programming idiom.

And, I think I have found one. metacall + project Euler. The mathematical nature of some computational problems make them a great fit for the functional paradigm. For those of you who don’t know, “Project Euler is a series of challenging mathematical/computer programming problems…” (ProjectEuler.net). I have concluded I could use the simple and interesting solution for a problem from “Project Euler” to show metacall in action.

## Solution no. 1

It seems to me, that the problem no. 1, contains quite enough opportunities to play with it, in the context of an metacall usage example. Without “much ado about nothing”, I shall present my classical solution, without using metacall:

// MIT (c) DBJ.ORG // Basic particle for the solution // to projecteuler.net problem 1 // Return is a single number // that is a sum of natural numbers // in range [0 .. max] // Where each number is // multiplier of a input value div function sum_n ( max, div ) { var rez = 0 ; while ( max-- > div) if ( max % div== 0 ) rez += max ; return rez ; }

I have decided to solve a problem with one “building block” function, and one expression using it.

`sum_n()`

, above returns a single number, that is a sum of natural numbers in range `[div .. max]`

, where each number is multiplier of a value `div`

. In which case this expression :// // add results for input [0 .. 1000] // for divisors 3 and 5 // to compute problem [0 .. 1000] // for divisor 15 // var result = sum_n(1000,3) + sum_n(1000,5); // // Why not just [0 .. 1000] // for divisor 15 ? //

Gives the final result of the solution to the problem no. 1? No. The above is not a correct solution and you dear reader are sleeping on the job! Now … wake up and think:

`3 x 5 = 15`

. So? So in the final expression above, 15 is “calculated in” twice, for 3 and for 5. Here is the proper final expression that yields the correct result.// // a correct solution using our // "building block" function sum_n var result = sum_n(1000,3) + sum_n(1000,5) - sum_n(1000,3*5) ; // gives: 233168 //

## After solution comes optimization

Strep 1 to the “final” solution is basically solved. But. Beside algorithmically, optimizations are achieved on the level of the language and/or runtime environment. For example one could safely predict that running each `sum_n()`

call on a separate thread would speed up things. Or one could extend the solution so that more than two divisors are involved under one limiter :

// // extend the functionality to receive 3 divisors // using the same building block function sum_n var result = sum_n(1000,3) + sum_n(1000,5) + sum_n(1000,7) - sum_n(1000, 3*5*7) ; // // gives: 332679 //

Of course do not loose the fact that composable programming solutions are reusable and thus applicable to wide range of similar programs. Like this one is. We are composing the finals solution from building block function. This is very different to writing a single function or program for each variant of the same problem.

Here is the JSFiddle source so far.

function print (s) { return setTimeout(function () { document.body.innerHTML += "<li style='list-style: none'>"+s+"</li>" ; }, 1 ) ; }; // "building block" function function sum_n ( max, div ) { var rez = 0 ; while ( max-- > div) if ( max % div== 0 ) rez += max ; return rez ; } // https://projecteuler.net/problem=1 // 'standard' solution var result = sum_n(1000,3) + sum_n(1000,5) - sum_n(1000,3*5) ; // gives: 233168 print(result);

## Why not stop here?

**Reason 1: performance**

Looking at above, it is obvious that parallel processing might be crucial, in improving performance. For that to happen, an correct mechanism (not algorithm) is found, selected and implemented.

**Reason 2: change management**

Whoever has spent some time developing the code for a customer, knows it is obvious that, requirements do change suddenly and drastically and good programming solution must be *also* resilient to change, to make improvements possible and feasible.

Change to the program is an improvement only and only if it is both possible and feasible.

Never loose this very simple but often overlooked wisdom. If it is not satisfied your change is not an improvement. This is why architectural patterns like metacall are important. To make the inevitable changes achievable in a feasible manner. Not always, but most of the time.