Complexity of chaining methods in javascript - javascript

I have a problem to determine the complexity of my algorithm because it use features of ES6 and of course they are chained methods. I already know some of basic complexity of those method for example the complexity of Array.prototype.map is O(n). But when we want to determine a complexity of an algorithm, how do we manage chained method ?
For example, consider we have a function which return for an array the sum of its positive numbers
let sumPositive = arr => arr.filter(i => i > 0).reduce((a, b) => a + b, 0);
console.log(sumPositive([1, 2, 3, -4])); // 6
console.log(sumPositive([1, 2, 3, 4])); // 10
Therefore, what is the complexity of that function ?
Another example is this algorithm which for a given string, return the counts of each character in the string
let charCount = str => str.split('').map(
(c,_,str) => str.filter(i => i===c)
).reduce((a, b) => a.hasOwnProperty(b[0]) ? a : ({...a, [b[0]]: b.length}), {});
console.log(charCount("hi")); // {"h": 1, "i": 1}
console.log(charCount("hello to you")); // {"h": 1, "e": 1, "l": 2, "o": 3, " ": 2, "t": 1, "y": 1, "u": 1}
So for this second I need to know especially its complexity because we are dealing with nested method like the filter which is being call inside a map
So any general method to determine the complexity of such algorithm are welcome.
Note: All the complexity in this question is the time-complexity not space
Thanks

Chaining methods is actually just for convenience. map() or filter() returns an array. Now you can first put a name on the array, like let result = arr.map(...) and then do other stuff on that result array, or you can directly do something on the array returned by map() (or filter()), like map().filter().<more chaining if you want>.
So, it's equivalent to a sequential execution. Consider this example,
let sumPositive = arr => arr.filter(i => i > 0)
.reduce((a, b) => a + b, 0);
let arr = [1, 2, 3, -4];
let filteredArray = arr.filter(i => i > 0); // O(n)
let reducedResult = filteredArray.reduce((a, b) => a + b, 0); // O(n)
console.log(sumPositive(arr)); // 6
console.log(reducedResult) // 6
Now you see filter() takes O(n) and then reduce() takes O(n), so you get O(n) + O(n) ==> O(n) as your final time complexity.
I hope you can similarly find complexity for the second example. If you need assistance, let me know in the comments.

#Ajay Dabas answered your question; I'm answering your question in the comments:
So could you give me an example of what I can do to improve the code or some useful links
Your first example isn't going to get any simpler, but you could decrease the time complexity of your second algorithm:
let charCount = str => str.split('')
.map((c,_,str) => str.filter(i => i===c))
.reduce((a, b) => a.hasOwnProperty(b[0]) ? a : ({...a, [b[0]]: b.length}), {});
You could do this by not using the filter() method. There's no need to do this if you maintain an index of all of the keys and their current counts.. and you're already doing that with reduce():
let charCount = str =>
return str.split('').reduce(
(acc, nextChar) => {
return {
...acc,
[nextChar]: (acc[nextChar] || 0) + 1
};
},
Object.create(null)
);
};
This should be O(n) - We only iterate the array twice. Notice how we do not need to filter() the results because all we need to do is take the existing count for that character in the accumulator and increment it by one.
The usage of Object.create(null) is to create a new object with a null prototype - that means we don't need to use hasOwnProperty().
You should keep in mind that just because something is O(n^2) does not mean there is a performance problem. Big O notation just describes how some code will behave as the input data increases. Only look to optimize code when you know it's a problem.

Related

I'm trying to find the difference between two arrays but my code isn't working for 0s any advice?

here is my code:
function arrayDiff(a, b) {
let newArr = a.concat(b);
let singleVals = newArr.filter(num =>{
if(!a.includes(num) || !b.includes(num))
return num;
})
return singleVals;
}
an example of a result I'm looking for would be
a = [-16,12,5,8]
b = [12,5,8]
result = [-16]
That test would work with my code at the moment, however with something like this
a = [-16,6,19,0,9]
b = [9,-16,6]
my result = [19] when it should be [19,0]
I assume it has something to do with 0 counted as false or something like that. But an explanation would help.
Thanks
You are returning a number in filter but filter likes to get a boolean.
So it evaluates all the values !== 0 to true and evaluate zero to false like you assumed.
When you return now for example 19 then it evaluates to true and it will be in your singleVals Array.
But if you return 0 it evaluates to false and it won't be in your singleVals Array
Here a list of the 6 falsey values if you convert any of those to a boolean it will return false
false
undefined
null
NaN
0
"" (empty string)
You have to return a boolean instead of a number in your filter function.
function arrayDiff(a, b) {
let newArr = a.concat(b);
let singleVals = newArr.filter( num =>{
// it is not including the number
if(!a.includes(num) || !b.includes(num)){
return true;
}else{
return false;
}
})
return singleVals
}
console.log(arrayDiff([3,2,1,0], [3,2,1,4,5])); // expected 0, 4, 5
console.log(arrayDiff([-16,6,19,0,9],[9,-16,6])); // expected 9, 19
More Informations
https://www.samanthaming.com/tidbits/19-2-ways-to-convert-to-boolean/
A more efficient alternative is to use Set in place of the newArr = a.concat(b), since Set never contains duplicates.
function arrayDiff(a, b) {
const uniques = new Set([...a, ...b]);
return Array.from(uniques.values())
.filter(
val => !a.includes(val) || !b.includes(val)
);
}
const a = [-16, 6, 19, 0, 9],
b = [9, -16, 6];
const singleVals = arrayDiff(a, b);
console.log('singleVals:', JSON.stringify(singleVals));
If running time matters...
You didn't ask about this directly, but a number of these solutions contain nested loops, which will blow up on you for larger input arrays. So, in case you want a suggestion that is more efficient in terms of time, I've added this one.
Nested loops are not desirable from an algorithmic efficiency perspective. If a has 10 items, and b has 8 items, and you're looping over every "b" for every "a", your running time will grow as the product of the size of those two arrays, quickly becoming very slow (O(n*m)). You're doing 8*10 = 80 steps to process 18 values. Imagine if it were 100 * 100, or 1000 * 1000...
Here's a solution that returns a result without nested loops, at the cost of creating two sets and an extra array for the results. From what I can see this is no more space than any of the other suggestions would take, and less time:
const a = [-16, 6, 19, 0, 9]
const b = [9, -16, 6]
function diff(a, b) {
// Set creation is O(n) time and space, where n is the length of array a
const aUniques = new Set(a)
// Set creation is O(m) time and space, where m is the length of array b
const bUniques = new Set(b)
// Final array is at worst space O(n + m), but usually much less
const allUniques = []
// A single loop, O(n) time
aUniques.forEach(value => {
// Set lookups are very fast, O(1).
if (!bUniques.has(value)){
allUniques.push(value)
}
})
// A single loop, O(m) time
bUniques.forEach(value => {
if (!aUniques.has(value)){
allUniques.push(value)
}
})
// Final runtime is O(n) + O(m) + O(n) + O(m), or O(2n +2m)
// This grows as O(n+m), which time-wise is much better than O(n*m).
return allUniques
}
console.log(diff(a, b))
Does this matter for small input arrays? No. But it's good to understand the implications of different approaches.
A nice, short article on "big O" notation, if it helps: https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/
You're right, it has to do with zeroes being falsy. Array.prototype.filter expects a function that returns a boolean, not a number.
function arrayDiff(a, b) {
let newArr = a.concat(b);
let singleVals = newArr.filter(num => {
let isMissing = !a.includes(num) || !b.includes(num)
return isMissing
})
return singleVals
}
console.log(arrayDiff([3,4,2,0],[1,2,3,4])); // expected 0, 1

Explanation of .sort in JavaScript [duplicate]

How does the following code sort this array to be in numerical order?
var array=[25, 8, 7, 41]
array.sort(function(a,b){
return a - b
})
I know that if the result of the computation is...
Less than 0: "a" is sorted to be a lower index than "b".
Zero: "a" and "b" are considered equal, and no sorting is performed.
Greater than 0: "b" is sorted to be a lower index than "a".
Is the array sort callback function called many times during the course of the sort?
If so, I'd like to know which two numbers are passed into the function each time. I assumed it first took "25"(a) and "8"(b), followed by "7"(a) and "41"(b), so:
25(a) - 8(b) = 17 (greater than zero, so sort "b" to be a lower index than "a"): 8, 25
7(a) - 41(b) = -34 (less than zero, so sort "a" to be a lower index than "b": 7, 41
How are the two sets of numbers then sorted in relation to one another?
Please help a struggling newbie!
Is the array sort callback function called many times during the course of the sort?
Yes
If so, I'd like to know which two numbers are passed into the function each time
You could find out your self with:
array.sort((a,b) => {
console.log(`comparing ${a},${b}`);
return a > b ? 1
: a === b ? 0
: -1;
});
EDIT
This is the output I've got:
25,8
25,7
8,7
25,41
The JavaScript interpreter has some kind of sort algorithm implementation built into it. It calls the comparison function some number of times during the sorting operation. The number of times the comparison function gets called depends on the particular algorithm, the data to be sorted, and the order it is in prior to the sort.
Some sort algorithms perform poorly on already-sorted lists because it causes them to make far more comparisons than in the typical case. Others cope well with pre-sorted lists, but have other cases where they can be "tricked" into performing poorly.
There are many sorting algorithms in common use because no single algorithm is perfect for all purposes. The two most often used for generic sorting are Quicksort and merge sort. Quicksort is often the faster of the two, but merge sort has some nice properties that can make it a better overall choice. Merge sort is stable, while Quicksort is not. Both algorithms are parallelizable, but the way merge sort works makes a parallel implementation more efficient, all else being equal.
Your particular JavaScript interpreter may use one of those algorithms or something else entirely. The ECMAScript standard does not specify which algorithm a conforming implementation must use. It even explicitly disavows the need for stability.
Pairs of values are compared, one pair at a time. The pairs that are compared are an implementation detail--don't assume they will be the same on every browser. The callback can be anything (so you can sort strings or Roman numerals or anything else where you can come up with a function that returns 1,0,-1).
One thing to keep in mind with JavaScript's sort is that it is not guaranteed to be stable.
Deeply Knowledge
If the result is negative a is sorted before b.
If the result is positive b is sorted before a.
If the result is 0 no changes are done with the sort order of the two values.
NOTE:
This code is the view inside of the sort method step by step.
OUTPUT:
let arr = [90, 1, 20, 14, 3, 55];
var sortRes = [];
var copy = arr.slice(); //create duplicate array
var inc = 0; //inc meant increment
copy.sort((a, b) => {
sortRes[inc] = [ a, b, a-b ];
inc += 1;
return a - b;
});
var p = 0;
for (var i = 0; i < inc; i++) {
copy = arr.slice();
copy.sort((a, b) => {
p += 1;
if (p <= i ) {
return a - b;
}
else{
return false;
}
});
p = 0;
console.log(copy +' \t a: '+ sortRes[i][0] +' \tb: '+ sortRes[i][1] +'\tTotal: '+ sortRes[i][2]);
}
To help clarify the behavior of Array#sort and its comparator, consider this naive insertion sort taught in beginning programming courses:
const sort = arr => {
for (let i = 1; i < arr.length; i++) {
for (let j = i; j && arr[j-1] > arr[j]; j--) {
[arr[j], arr[j-1]] = [arr[j-1], arr[j]];
}
}
};
const array = [3, 0, 4, 5, 2, 2, 2, 1, 2, 2, 0];
sort(array);
console.log("" + array);
Ignoring the choice of insertion sort as the algorithm, focus on the hardcoded comparator: arr[j-1] > arr[j]. This has two problems relevant to the discussion:
The > operator is invoked on pairs of array elements but many things you might want to sort such as objects don't respond to > in a reasonable way (the same would be true if we used -).
Even if you are working with numbers, oftentimes you want some other arrangement than the ascending sort that's been baked-in here.
We can fix these problems by adding a comparefn argument which you're familiar with:
const sort = (arr, comparefn) => {
for (let i = 1; i < arr.length; i++) {
for (let j = i; j && comparefn(arr[j-1], arr[j]) > 0; j--) {
[arr[j], arr[j-1]] = [arr[j-1], arr[j]];
}
}
};
const array = [3, 0, 4, 5, 2, 2, 2, 1, 2, 2, 0];
sort(array, (a, b) => a - b);
console.log("" + array);
sort(array, (a, b) => b - a);
console.log("" + array);
const objArray = [{id: "c"}, {id: "a"}, {id: "d"}, {id: "b"}];
sort(objArray, (a, b) => a.id.localeCompare(b.id));
console.log(JSON.stringify(objArray, null, 2));
Now the naive sort routine is generalized. You can see exactly when this callback is invoked, answering your first set of concerns:
Is the array sort callback function called many times during the course of the sort? If so, I'd like to know which two numbers are passed into the function each time
Running the code below shows that, yes, the function is called many times and you can use console.log to see which numbers were passed in:
const sort = (arr, comparefn) => {
for (let i = 1; i < arr.length; i++) {
for (let j = i; j && comparefn(arr[j-1], arr[j]) > 0; j--) {
[arr[j], arr[j-1]] = [arr[j-1], arr[j]];
}
}
};
console.log("on our version:");
const array = [3, 0, 4, 5];
sort(array, (a, b) => console.log(a, b) || (a - b));
console.log("" + array);
console.log("on the builtin:");
console.log("" +
[3, 0, 4, 5].sort((a, b) => console.log(a, b) || (a - b))
);
You ask:
How are the two sets of numbers then sorted in relation to one another?
To be precise with terminology, a and b aren't sets of numbers--they're objects in the array (in your example, they're numbers).
The truth is, it doesn't matter how they're sorted because it's implementation-dependent. Had I used a different sort algorithm than insertion sort, the comparator would probably be invoked on different pairs of numbers, but at the end of the sort call, the invariant that matters to the JS programmer is that the result array is sorted according to the comparator, assuming the comparator returns values that adhere to the contract you stated (< 0 when a < b, 0 when a === b and > 0 when a > b).
In the same sense that I have the freedom to change my sort's implementation as long as I don't breach my specification, implementations of ECMAScript are free to choose the sort implementation within the confines of the language specification, so Array#sort will likely produce different comparator calls on different engines. One would not write code where the logic relies on some particular sequence of comparisons (nor should the comparator produce side effects in the first place).
For example, the V8 engine (at the time of writing) invokes Timsort when the array is larger than some precomputed number of elements and uses a binary insertion sort for small array chunks. However, it used to use quicksort which is unstable and would likely give a different sequence of arguments and calls to the comparator.
Since different sort implementations use the return value of the comparator function differently, this can lead to surprising behavior when the comparator doesn't adhere to the contract. See this thread for an example.
Is the array sort callback function called many times during the course of the sort?
Yes, that's exactly it. The callback is used to compare pairs of elements in the array as necessary to determine what order they should be in. That implementation of the comparison function is not atypical when dealing with a numeric sort. Details in the spec or on some other more readable sites.
Is the array sort callback function called many times during the course of the sort?
Since this is a comparison sort, given N items, the callback function should be invoked on average (N * Lg N) times for a fast sort like Quicksort. If the algorithm used is something like Bubble Sort, then the callback function will be invoked on average (N * N) times.
The minimum number of invocations for a comparison sort is (N-1) and that is only to detect an already sorted list (i.e. early out in Bubble Sort if no swaps occur).
Is the array sort callback function called many times during the course of the sort?
Yes
If so, I'd like to know which two numbers are passed into the function each time.
a: The first element for comparison.
b: The second element for comparison.
In the following example, a will be "2" and b will be "3" in the first iteration
How are the two sets of numbers then sorted in relation to one another?
Elements are sorted according to the return value of the compare function.
greater than 0: sort a after b
less than 0: sort a before b
equal to 0: keep original order of a and b
Here is an example
var arr = [3, 2, 1, 5, 4, 6, 7, 9, 8, 10];
console.log(arr.sort((a, b) => {
console.log(a - b, a, b);
//b-a if sorting in decending order
return a - b;
}));

This line of code finds the max element in an array, could someone please walk me through how this code accomplishes this using reduce? [duplicate]

Often I study some JavaScript interview questions, suddenly I saw a question about usage of reduce function for sorting an Array, I read about it in MDN and the usage of it in some medium articles, But sorting an Array is so Innovative:
const arr = [91,4,6,24,8,7,59,3,13,0,11,98,54,23,52,87,4];
I thought a lot, but I've no idea about how answer this question, how must be the reduce call back function? what is the initialValue of reduce function? And what are the accumulator and currentValue of call back function of reduce?
And at the end, does this way have some benefits than other sorting algorithms? Or Is it useful to improve other algorithms?
It makes no sense to use reduce here, however you could use a new array as an accumulator and do insertion sort with all elements:
array.reduce((sorted, el) => {
let index = 0;
while(index < sorted.length && el < sorted[index]) index++;
sorted.splice(index, 0, el);
return sorted;
}, []);
Here is the version without reduce:
array.sort((a, b) => a - b);
Now some general tips for writing reducers:
how must be the reduce call back function?
You either take an approach with an accumulator, then the reducer should apply a modification to the accumulator based on the current element and return it:
(acc, el) => acc
Or if accumulator and the elements have the sane type and are logically equal, you dont need to distinguish them:
(a, b) => a + b
what is the initialValue of reduce function?
You should ask yourself "What should reduce return when it is applied on an empty array?"
Now the most important: When to use reduce? (IMO)
If you want to boil down the values of an array into one single value or object.
Array.sort mutates the array where using Array.reduce encourages a pure function. You could clone the array before sorting.
I believe this question is designed to get you thinking differently by enforcing constraints. It tests your knowledge of how reduce works and as the answers show there are many ways to skin a cat. It'll show your personal flavour of js in solving this.
I chose to use Array.findIndex and Array.splice.
const sortingReducer = (accumulator, value) => {
const nextIndex = accumulator.findIndex(i => value < i );
const index = nextIndex > -1 ? nextIndex : accumulator.length;
accumulator.splice(index, 0, value);
return accumulator;
}
const input = [5,4,9,1];
const output = input.reduce(sortingReducer, []);
Testing with the sample input produces
arr.reduce(sortingReducer, [])
// (17) [0, 3, 4, 4, 6, 7, 8, 11, 13, 23, 24, 52, 54, 59, 87, 91, 98]
Here is an example of the sorting an array in descending order using reduce function.
what is the initialValue of reduce function
In this below function the initial value is the [] which is passed as thisArg in the reduce function.
array.reduce(function(acc,curr,currIndex,array){
//rest of the code here
},[]//this is initial value also known as thisArg)
So basically an empty array is passed and the elements will be be pushed to this array
The accumulator here is the empty array.
const arr = [91, 4, 6, 24, 8, 7, 59, 3, 13, 0, 11, 98, 54, 23, 52, 87, 4];
var m = arr.reduce(function(acc, cur) {
// this arrVar will have the initial array
let arrVar = arr;
// get the max element from the array using Math.max
// ... is spread operator
var getMaxElem = Math.max(...arrVar);
// in the accumulator we are pushing the max value
acc.push(getMaxElem);
// now need to remove the max value from the array, so that next time it
// shouldn't not be considered
// splice will return a new array
// now the arrVar is a new array and it does not contain the current
// max value
arrVar = arrVar.splice(arrVar.indexOf(getMaxElem), 1, '')
return acc;
}, []);
console.log(m)
Here's an (imo) more elegant version of Jonas W's insertion sort solution. The callback just builds a new array of all lower values, the new one and all higher values. Avoids using explicit loops or indices, so it's easier to see at a glance that it works correctly.
const insertValue = (arr, value) =>
[...arr.filter(n => n <= value), value, ...arr.filter(n => n > value)]
const testArr = [91, 4, 6, 24, 8, 7, 59, 3, 13, 0, 11, 98, 54, 23, 52, 87, 4]
console.log(testArr.reduce(insertValue, []))
reduce constraints yourself to online sorting algorithms, where each element in the array is seen once and you do not now in advance the length of your array (note that using closures you could give more information to the reducing function but this kinds of defeats the purpose of the question).
insertion sort is an obvious and easy example; I won't detail the implementation as the other answers are already very good in this regard. However you can mention a few optimizations that might probably seen as very positive to the interviewer:
Use binary search to find the insertion point can reduce the complexity of an insertion step from O(n) to O(log n). This is called binary insertion sort: the overall number of comparisons will go from O(n^2) to O(n log n). This won't be faster because the real cost is due to "splicing" the output array but if you had expensive comparisons (say, sorting long strings for instance) it could make a difference.
If you sort integer, you can use radix sort and implement a linear online sorting algorithm with reduce. This is quite trickier to implement, but very suited to a reduction.
You could use some functions for getting an array if not an array is supplied, a function which returns a sorted array by taking two parameters and a sort callback which includes the above by using another reduce method for getting a part result of a sorted array.
const
getArray = a => Array.isArray(a) ? a : [a],
order = (a, b) => a < b ? [a, b] : [b, a],
sort = (a, b) => getArray(a).reduce((r, v) => r.concat(order(r.pop(), v)), [b]),
array = [91, 4, 6, 24, 8, 7, 59, 3, 13, 0, 11, 98, 54, 23, 52, 87, 4];
console.log(array.reduce(sort));
.as-console-wrapper { max-height: 100% !important; top: 0; }
You can use an insertion sort:
let array = [91, 4, 6, 24, 8, 7, 59, 3, 13, 0, 11, 98, 54, 23, 52, 87, 4];
let countIfLess = (array,v)=> array.reduce((c,n)=>n<v?c+1:c,0);
let countIfEqual = (array,v)=> array.reduce((c,n)=>n==v?c+1:c,0);
console.log(
array.reduce(
(a,v,i,array)=>( a[countIfLess(array,v) + countIfEqual(a,v)]=v, a ),
new Array(array.length)
)
);
This will create the destination array once and then perform insertions into it at each step of the reduce without having to recreate the destination array.
There are more efficient ways of implementing countIfEqual but I chose to implement all the functions using reduce rather than other array functions.
A terrible sorting algorithm can be written in a one liner with ES6:
const sorter = (xs, x) => xs.slice(-1)[0] >= x ? [x, ...xs] : [...xs, x];
If the present element is larger or equal the last element of the previously sorted list it is appended to the end, otherwise to the beginning.
[3,4,1].reduce(sorter,[]).reduce(sorter,[])
//returns [1,3,4]
It takes several applications to its return to sort anything but the most simple arrays.
But it will eventually get there. That calls for a recursion!
const arr = [91,4,6,24,8,7,59,3,13,0,11,98,54,23,52,87,4];
const sorter2 =(as) => as.reduce(
(xs, x) => x >= xs.slice(-1)[0] ? [...xs, x]
: xs[0] < x ? sorter2([x, ...xs])
: [x, ...xs],
[],
);
const result = sorter2(arr);
console.log(result.join(', '));
When the present value is larger than the last value of already processed array it is appended. If it is smaller than the first element it is prepended. Only if it is neither before or after the the present value and the accumulated array are sorted again by a recursive call. The method should be equivalent to an insertion sort (please comment!).
Though, reduce is not ideally meant for the sorting. The following solution is just like a forEach or any loop function trying to be achieved with Array.reduce function.
var arr = [91,4,6,24,8,7,59,3,13,0,11,98,54,23,52,87,4];
arr = arr.reduce(function(acc,val){
if(acc.length) {
var temp = [];
while(acc[acc.length -1] > val) {
temp.push(acc.pop());
}
acc.push(val);
while(temp.length) {
acc.push(temp.pop());
}
} else {
acc.push(val);
}
return acc;
}, []);
console.log(arr);
Please note, you can use the native function Array.sort for sorting and can also have your own custom sort function where you can define your own sorting algorithm.

Main difference between map and reduce

I used both methods but I am quite confused regarding the usage of both methods.
Is anything that map can do but reduce can not and vice versa?
Note: I know how to use both methods I am questioning for main difference between these method and when we need to used.
Source
Both map and reduce have as input the array and a function you define. They are in some way complementary: map cannot return one single element for an array of multiple elements, while reduce will always return the accumulator you eventually changed.
map
Using map you iterate the elements, and for each element you return an element you want.
For example, if you have an array of numbers and want to get their squares, you can do this:
// A function which calculates the square
const square = x => x * x
// Use `map` to get the square of each number
console.log([1, 2, 3, 4, 5].map(square))
reduce
Using an array as an input, you can get one single element (let's say an Object, or a Number, or another Array) based on the callback function (the first argument) which gets the accumulator and current_element parameters:
const numbers = [1, 2, 3, 4, 5]
// Calculate the sum
console.log(numbers.reduce(function (acc, current) {
return acc + current
}, 0)) // < Start with 0
// Calculate the product
console.log(numbers.reduce(function (acc, current) {
return acc * current
}, 1)) // < Start with 1
Which one should you choose when you can do the same thing with both? Try to imagine how the code looks. For the example provided, you can compute the squares array like you mentioned, using reduce:
// Using reduce
[1, 2, 3, 4, 5].reduce(function (acc, current) {
acc.push(current*current);
return acc;
}, [])
// Using map
[1, 2, 3, 4, 5].map(x => x * x)
Now, looking at these, obviously the second implementation looks better and it's shorter. Usually you'd choose the cleaner solution, which in this case is map. Of course, you can do it with reduce, but in a nutshell, think which would be shorter and eventually that would be better.
I think this picture will answer you about the difference between those Higher Order Functions
Generally "map" means converting a series of inputs to an equal length series of outputs while "reduce" means converting a series of inputs into a smaller number of outputs.
What people mean by "map-reduce" is usually construed to mean "transform, possibly in parallel, combine serially".
When you "map", you're writing a function that transforms x with f(x) into some new value x1. When you "reduce" you're writing some function g(y) that takes array y and emits array y1.
They produce different results in terms of data structure.
The map() function returns a new array through passing a function over each element in the input array.
This is different to reduce() which takes an array and a function in the same way, but the function takes 2 inputs - an accumulator and a current value.
So reduce() could be used like map() if you always .concat onto the accumulator the next output from a function. However it is more commonly used to reduce the dimensions of an array so either taking a one dimensional and returning a single value or flattening a two dimensional array etc.
Let's take a look of these two one by one.
Map
Map takes a callback and run it against every element on the array but what's
makes it unique is it generate a new array based on your existing array.
var arr = [1, 2, 3];
var mapped = arr.map(function(elem) {
return elem * 10;
})
console.log(mapped); // it genrate new array
Reduce
Reduce method of the array object is used to reduce the array to one single value.
var arr = [1, 2, 3];
var sum = arr.reduce(function(sum, elem){
return sum + elem;
})
console.log(sum) // reduce the array to one single value
I think this question is a very good question and I can't disagree with the answers but I have the feeling we are missing the point entirely.
Thinking of map and reduce more abstractly can provide us with a LOT of very good insights.
This answer is divided in 3 parts:
Defining and deciding between map and reduce (7 minutes)
Using reduce intentionally (8 minutes)
Bridging map and reduce with transducers (5 minutes)
map or reduce
Common traits
map and reduce are implemented in a meaningful and consistent way on a wide range of objects which are not necessarily collections.
They return a value useful to the surrounding algorithm, and they only care about this value.
Their major role is conveying intent regarding transformation or preservation of structure.
Structure
By "structure" I mean a set of conceptual properties which characterise abstract objects, such as an unordered list or a 2D matrix, and their concretion in data structures.
Note that there can be a disconnect between the two:
an unordered list can be stored as an array, which has the concept of ordering carried by indexed keys;
a 2D matrix can be stored as a TypedArray, which lacks the concept of dimension (or nesting).
map
map is a strict structure-preserving transformation.
It is useful to implement it on other kinds of objects to grasp its semantic value:
class A {
constructor (value) {
this.value = value
}
map (f) {
return new A(f(this.value))
}
}
new A(5).map(x => x * 2); // A { value: 10 }
Objects implementing map can have all kinds of behaviours, but they always return the same kind of object you started with while transforming the values with the supplied callback.
Array.map returns an array of the same length and the same ordering as the original.
On the callback arity
Because it preserves structure, map is viewed as a safe operation, but not every callback is equal.
With a unary callback: map(x => f(x)), each value of the array is totally indifferent to the presence of other values.
Using the other two parameters on the other hand introduces coupling, which may not be true to the original structure.
Imagine removing or reordering the second item in the arrays bellow: doing it before or after the map would not yield the same result.
Coupling with array size:
[6, 3, 12].map((x, _, a) => x/a.length);
// [2, 1, 4]
Coupling with ordering:
['foo', 'bar', 'baz'].map((x, i) => [i, x]);
// [[0, 'foo'], [1, 'bar'], [2, 'baz']]
Coupling with one specific value:
[1, 5, 3].map((x, _, a) => x/Math.max(...a));
//[ 0.2, 1, 0.6]
Coupling with neighbours:
const smooth = (x, i, a) => {
const prev = a[i - 1] ?? x;
const next = a[i + 1] ?? x;
const average = (prev + x + next) / 3;
return Math.round((x + average) / 2);
};
[1, 10, 50, 35, 40, 1].map(smoothh);
// [ 3, 15, 41, 38, 33, 8 ] 
I recommend making it explicit on the call site whether or not these parameters are used.
const transfrom = (x, i) => x * i;
❌ array.map(transfrom);
⭕ array.map((x, i) => transfrom(x, i));
This has other benefits when you use variadic functions with map.
❌ ["1", "2", "3"].map(parseInt);
// [1, NaN, NaN]
⭕ ["1", "2", "3"].map(x => parseInt(x));
// [1, 2, 3]
reduce
reduce sets a value free from its surrounding structure.
Again, let's implement it on a simpler object:
class A {
constructor (value) {
this.value = value
}
reduce (f, init) {
return init !== undefined
? f(init, this.value)
: this.value
}
}
new A(5).reduce(); // 5
const concat = (a, b) => a.concat(b);
new A(5).reduce(concat, []); // [ 5 ]
Whether you leave the value alone or you put it back into something else, the output of reduce can be of any shape. It is literally the opposite of map.
Implications for arrays
Arrays can contain multiple or zero values, which gives rise to two, sometimes conflicting, requirements.
The need to combine
How can we return multiple values with no structure around them?
It is impossible. In order to return only one value, we have two options:
summarising the values into one value;
moving the values into a different structure.
Doesn't it make more sense now?
The need to initialise
What if there is no value to return?
If reduce returned a falsy value, there would be no way to know if the source array was empty or if it contained that falsy value, so unless we provide an initial value, reduce has to throw.
The true purpose of the reducer
You should be able to guess what the reducer f does in the following snippet:
[a].reduce(f);
[].reduce(f, a);
Nothing. It is not called.
It is the trivial case: a is the single value we want to return, so f is not needed.
This is by the way the reason why we didn't make the reducer mandatory in our class A earlier: because it contained only one value. It is mandatory on arrays because arrays can contain multiple values.
Since the reducer is only called when you have 2 or more values, saying its sole purpose is to combine them is only a stone throw away.
On transforming values
On arrays of variable lengths, expecting the reducer to transform the values is dangerous because, as we discovered, it may not be called.
I encourage you to map before you reduce when you need to both transform values and change shape.
It is a good idea to keep these two concerns separate for readability anyway.
When not to use reduce
Because reduce is this general-purpose tools for achieving structure transformation, I advise you to avoid it when you want an array back if there exists another more focussed method which does what you want.
Specifically, if you struggle with nested arrays in a map, think of flatMap or flat before reaching for reduce.
At the heart of reduce
a recursive binary operation
Implementing reduce on arrays introduces this feedback loop where the reducer's first argument is the return value of the previous iteration.
Needless to say it looks nothing like map's callback.
We could implement Array.reduce recursively like so:
const reduce = (f, acc, [current, ...rest]) =>
rest.length == 0
? f(acc, current)
: reduce(f, f(acc, current), rest)
This highlights the binary nature of the reducer f and how its return value becomes the new acc in the next iteration.
I let you convince yourself that the following is true:
reduce(f, a, [b, c, d])
// is equivalent to
f(f(f(a, b), c), d)
// or if you squint a little
((a ❋ b) ❋ c) ❋ d
This should seem familiar: you know arithmetic operations obey rules such as "associativity" or "commutativity". What I want to convey here is that the same kind of rules apply.
reduce may strip out the surrounding structure, values are still bound together in an algebraic structure for the time of the transformation.
the algebra of reducers
Algebraic structures are way out of the scope of this answer, so I will only touch on how they are relevant.
((a ❋ b) ❋ c) ❋ d
Looking at the expression above, it is self-evident that there is a constraint that ties all the values together : ❋ must know how to combine them the same way + must know how to combine 1 + 2 and just as importantly (1 + 2) + 3.
Weakest safe structure
One way to ensure this is to enforce that these values belong to a same set on which the reducer is an "internal" or "closed" binary operation, that is to say: combining any two values from this set with the reducer produces a value which belongs to the same set.
In abstract algebra this is called a magma. You can also look up semi-groups which are more talked about and are the same thing with associativity (no braces required), although reduce doesn't care.
Less safe
Living in a magma is not absolutely necessary : we can imagine a situation where ❋ can combine a and b but not c and b.
An example of this is function composition. One of the following functions returns a string, which constrains the order in which you can combine them:
const a = x => x * 2;
const b = x => x ** 2;
const c = x => x + ' !';
// (a ∘ b) ∘ c
const abc = x => c(b(a(x)));
abc(5); // "100 !"
// (a ∘ c) ∘ b
const acb = x => b(c(a(x)));
acb(5); // NaN
Like many binary operations, function composition can be used as a reducer.
Knowing if we are in a situation where reordering or removing elements from an array could make reduce break is kind of valuable.
So, magmas: not absolutely necessary, but very important.
what about the initial value
Say we want to prevent an exception from being thrown when the array is empty, by introducing an initial value:
array.reduce(f, init)
// which is really the same as doing
[init, ...array].reduce(f)
// or
((init ❋ a) ❋ b) ❋ c...
We now have an additional value. No problem.
"No problem"!? We said the purpose of the reducer was to combine the array values, but init is not a true value: it was forcefully introduced by ourselves, it should not affect the result of reduce.
The question is:
What init should we pick so that f(init, a) or init ❋ a returns a?
We want an initial value which acts as though it was not there. We want a neutral element (or "identity").
You can look up unital magmas or monoids (the same with associativity) which are swear words for magmas equipped with a neutral element.
Some neutral elements
You already know a bunch of neutral elements
numbers.reduce((a, b) => a + b, 0)
numbers.reduce((a, b) => a * b, 1)
booleans.reduce((a, b) => a && b, true)
strings.reduce((a, b) => a.concat(b), "")
arrays.reduce((a, b) => a.concat(b), [])
vec2s.reduce(([u,v], [x,y]) => [u+x,v+y], [0,0])
mat2s.reduce(dot, [[1,0],[0,1]])
You can repeat this pattern for many kinds of abstractions. Note that the neutral element and the computation don't need to be this trivial (extreme example).
Neutral element hardships
We have to accept the fact that some reductions are only possible for non-empty arrays and that adding poor initialisers don't fix the problem.
Some examples of reductions gone wrong:
Only partially neutral
numbers.reduce((a, b) => b - a, 0)
// does not work
numbers.reduce((a, b) => a - b, 0)
Subtracting 0 form b returns b, but subtracting b from 0 returns -b.
We say that only "right-identity" is true.
Not every non-commutative operation lack a symmetrical neutral element but it's a good sign.
Out of range
const min = (a, b) => a < b ? a : b;
// Do you really want to return Infinity?
numbers.reduce(min, Infinity)
Infinity is the only initial value which does not change the output of reduce for non-empty arrays, but it is unlikely that we would want it to actually appear in our program.
The neutral element is not some Joker value we add as a convenience. It has to be an allowed value, otherwise it doesn't accomplish anything.
Nonsensical
The reductions bellow rely on position, but adding an initialiser naturally shifts the first element to the second place, which requires messing with the index in the reducer to maintain the behaviour.
const first = (a, b, i) => !i ? b : a;
things.reduce(first, null);
const camelCase = (a, b, i) => a + (
!i ? b : b[0].toUpperCase() + b.slice(1)
);
words.reduce(camelCase, '');
It would have been a lot cleaner to embrace the fact the array can't be empty and simplify the definition of the reducers.
Moreover, the initials values are degenerate:
null is not the first element of an empty array.
an empty string is by no means a valid identifier.
There is no way to preserve the notion of "firstness" with an initial value.
conclusion
Algebraic structures can help us think of our programs in a more systematic way. Knowing which one we are dealing with can predict exactly what we can expect from reduce, so I can only advise you to look them up.
One step further
We have seen how map and reduce were so different structure-wise, but it is not as though they were two isolated things.
We can express map in terms of reduce, because it is always possible to rebuild the same structure we started with.
const map = f => (acc, x) =>
acc.concat(f(x))
;
const double = x => x * 2;
[1, 2, 3].reduce(map(double), []) // [2, 4, 6]
Pushing it a little further has led to neat tricks such as transducers.
I will not go into much detail about them, but I want you to notice a couple of things which will echo what we have said before.
Transducers
First let's see what problem we are trying to solve
[1, 2, 3, 4].filter(x => x % 2 == 0)
.map(x => x ** 2)
.reduce((a, b) => a + b)
// 20
We are iterating 3 times and creating 2 intermediary data structures. This code is declarative, but not efficient. Transducers attempt to reconcile the two.
First a little util for composing functions using reduce, because we are not going to use method chaining:
const composition = (f, g) => x => f(g(x));
const identity = x => x;
const compose = (...functions) =>
functions.reduce(composition, identity)
;
// compose(a, b, c) is the same as x => a(b(c(x)))
Now pay attention to the implementation of map and filter bellow. We are passing in this reducer function instead of concatenating directly.
const map = f => reducer => (acc, x) =>
reducer(acc, f(x))
;
const filter = f => reducer => (acc, x) =>
f(x) ? reducer(acc, x) : acc
;
look at this more specifically:
reducer => (acc, x) => [...]
after the callback function f is applied, we are left with a function which takes a reducer as input and returns a reducer.
These symmetrical functions is what we pass to compose:
const pipeline = compose(
filter(x => x % 2 == 0),
map(x => x ** 2)
);
Remember compose is implemented with reduce: our composition function defined earlier combines our symmetrical functions.
The output of this operation is a function of the same shape: something which expects a reducer and returns a reducer, which means
we have a magma. We can keep composing transformations as long as they have this shape.
we can consume this chain by applying the resulting function with a reducer, which will return a reducer that we can use with reduce
I let you expand the whole thing if you need convincing. If you do so you will notice that transformations will conveniently be applied left to right, which is the opposite direction of compose.
Alright, lets use this weirdo:
const add = (a, b) => a + b;
const reducer = pipeline(add);
const identity = 0;
[1, 2, 3, 4].reduce(reducer, identity); // 20
We have composed operations as diverse as map, filter and reduce into a single reduce, iterating only once with no intermediary data-structure.
This is no small achievement! And it is not a scheme you can come up with by deciding between map and reduce merely on the basis of the conciseness of the syntax.
Also notice that we have full control over the initial value and the final reducer. We used 0 and add, but we could have used [] and concat (more realistically push performance-wise) or any other data-structure for which we can implement a concat-like operation.
To understand the difference between map, filter and reduce, remember this:
All three methods are applied on array so anytime you want to make any operation on an array, you will be using these methods.
All three follow functional approaches and therefore the original array remains the same. Original array doesn't change instead a new array/value is returned.
Map returns a new array with the equal no. of elements as there are in the original array. Therefore, if the original array has 5 elements, the returned array will also have 5 elements. This method is used whenever we want to make some change on every individual element of an array. You can remember that every element of ann array is being mapped to some new value in output array, therefore the name map
For eg,
var originalArr = [1,2,3,4]
//[1,2,3,4]
var squaredArr = originalArr.map(function(elem){
return Math.pow(elem,2);
});
//[1,4,9,16]
Filter returns a new array with equal/less number of elements than the original array. It returns those elements in the array which have passed some condition. This method is used when we want to apply a filter on the original array therefore the name filter. For eg,
var originalArr = [1,2,3,4]
//[1,2,3,4]
var evenArr = originalArr.filter(function(elem){
return elem%2==0;
})
//[2,4]
Reduce returns a single value, unlike a map/filter. Therefore, whenever we want to run an operation on all elements of an array but want a single output using all elements, we use reduce. You can remember an array's output is reduced to a single value therefore the name reduce. For eg,
var originalArr = [1,2,3,4]
//[1,2,3,4]
var sum = originalArr.reduce(function(total,elem){
return total+elem;
},0)
//10
The map function executes a given function on each element but reduce executes a function which reduces the array to a single value. I'll give an example of both:
// map function
var arr = [1, 2, 3, 4];
var mappedArr = arr.map((element) => { // [10, 20, 30, 40]
return element * 10;
})
// reduce function
var arr2 = [1, 2, 3, 4]
var sumOfArr2 = arr2.reduce((total, element) => { // 10
return total + element;
})
It is true that reduce reduces an array to a single value, but since we can pass an object as initialValue, we can build upon it and end up with a more complex object than what we started with, such as this example where we group items by some criteria. Therefore the term 'reduce' can be slightly misleading as to the capabilities of reduce and thinking of it as necessarily reducing information can be wrong since it could also add information.
let a = [1, 2, 3, 4, 5, 6, 7, 8, 9]
let b = a.reduce((prev, curr) => {
if (!prev["divisibleBy2"]) {
prev["divisibleBy2"] = []
}
if (curr % 2 === 0) {
prev["divisibleBy2"].push(curr)
}
if (!prev["divisibleBy3"]) {
prev["divisibleBy3"] = []
}
if (curr % 3 === 0) {
prev["divisibleBy3"].push(curr)
}
if (!prev["divisibleBy5"]) {
prev["divisibleBy5"] = []
}
if (curr % 5 === 0) {
prev["divisibleBy5"].push(curr)
}
return prev
}, {})
console.log(b)

Iterating through a function call

After years of writing loops in C++ the tedious way
for(int i=0; i<N; ++i) {
...
}
it becomes quite nice to use iterators
for(it i=v.begin(); i<v.end(); ++i) {
...
}
and ultimately moving to range iterators
for(auto i:v) {
...
}
In JavaScript also the for can be used, in a style nearly identical
(minus the type declaration and the pre/post increment operator) to
the first one above.
Still, in all of these the for is there. The D3.js
library demonstrates an alternative. One can iterate over an array by writing
d3.select("body")
.selectAll("p")
.data([4, 8, 15, 16, 23, 42])
.enter().append("p")
.text(function(d) { return "I’m number " + d + "!"; });
Here the enter mutates to a for loop. The documentation
explains nicely the client-side view of joins. What I am missing is a
standalone example of the (functional programming?) style of
converting a function call to an iteration.
No doubt this is not unique to D3.js. This is just where I encountered the idiom.
Can you suggest a few lines of standalone JavaScript code that
demonstrate iteration through a function call?
There are at least a couple of built-in functions that come to my mind.
map()
This one is very obvious.
[1, 2, 3]
.map(someNumber => someNumber * someNumber)
.map((powered, index) => index + "::" + powered);
// --> [ "1::1", "2::4", "3::9" ]
Chains well, right? Takes some input and produces the result consisting of elements calculated by applying a function element-wise.
Recommendation: try to use with pure functions whenever possible (produce the same results for same inputs, don't mutate the original collection if possible, nor produce any side effects).
forEach()
This function iterates through all elements of an array too, and applies a function, without returning anything back. Therefore, it can only end a chain of calls, but cannot be used for further chaining.
[1, 2, 3, 4]
.forEach(number => console.info(number));
Recommendation: forEach() is useful when we want to write some code that will result in a side effect per entry in the collection being iterated.
filter()
Filter function uses a predicate is used to sift the wheat from the chaff. The predicate is defining a criteria for the items you want to deal with on the next "stage".
[null, undefined, 0, 1, 2, 3, NaN, "", "You get the idea"]
.filter(Boolean)
.map(filteredElement => filteredElement + "!")
// --> [ "1!", "2!", "3!", "You get the idea!" ]
Recommendation: try to use with pure functions whenever possible. I.e. don't do anything else in filter other than things immediately related to filtration logic itself.
Object.keys() and Object.entries()
These two functions are helpful when we need to iterate over object's keys or key-value pairs, rather than an array's elements.
const targetObject = { a: 1, b: 2, c: 3 };
Object
.keys(targetObject)
.map(key => key + "=" + targetObject[key])
// --> [ "a=1", "b=2", "c=3" ]
same result can be achieved like this
Object
.entries({ a: 1, b: 2, c: 3 })
.map((key, value) => key + "=" + value)
// --> [ "a=1", "b=2", "c=3" ]
Recommendation: you may want to use Object.hasOwnProperty(...) when using working with Object.keys(...). See the documentation for details.
find()
The one is almost trivial. Let's us search for an item that matches a predicate. The search is "left-to-right", and it stops whenever the first "match" is found.
[1, 5, 10, 15]
.find(number >= 7)
// --> 10
findIndex() function can be used when we're looking for a position of an element that matches a predicate.
some() and every()
These functions check whether
a) there is at least one element matching a predicate; or
b) each and every element is matching a predicate.
const arrayOfNumbers = [2, 4, 6, 8, 10];
arrayOfNumbers.every(number => number % 2 === 0); // --> true
arrayOfNumbers.every(number => number % 2 === 1); // --> false
arrayOfNumbers.some(number => number > 1); // --> true
arrayOfNumbers.some(number => number <= 1); // --> false
reduce() and `reduceRight()`
The last one to mention in this quick review is the function that takes a list of things and aggregates it into a single result.
[-1, 0, 1, 2, 3]
.filter(value => value >= 0) // [0, 1, 2, 3]
.map(value => value + 1) // [1, 2, 3, 4]
.reduce((subTotal, currentValue) => subTotal + currentValue, 5);
// --> 15
Recommendation: try to use with pure functions whenever possible.
Universally applicable note on performance. In my benchmarks (don't have them on hand), a hand-written for loop was always faster than forEach, map, and other iterating functions. I do still prefer the functions unless the performance is being severely affected. There two main reasons for that: 1) easier to avoid off-by-one-errors; 2) the code is more readable, since each single function defines an independent step in the data processing flow, thus making code simpler and more maintainable.
I hope, this is an okay overview of some built-in chain-able JavaScript functions. More are described here. Take a look at concat(), sort(), fill(), join(), slice(), reverse() -- I frequently use them too.
If you need something like first() or last(), you will not find them in native functions. Either write your own ones, or use third-party libraries (e.g. lodash, rambda.js).
Here is an example implementation of Array.prototype.forEach:
function foreach(array, cb) {
for (var i = 0; i < array.length; ++i)
cb(array[i], i, array);
}
foreach([2,8,739,9,0], (n, i) =>
console.log("number: %s\nindex: %s\n", n, i));
surely I don't have to spoonfeed you do I?
function array_iterator(array) {
var i = 0;
function next() {
return array[i++];
}
function head() {
return array[i];
}
function tail() {
return array[array.length-1];
}
function more() {
return i < array.length;
}
function done() {
return !more();
}
function reset() {
i = 0;
}
return { next, head, tail, done, more, reset };
}
var nums = [3,34,4];
var iter = array_iterator(nums);
while (iter.more()) {
console.log(iter.next());
}

Categories

Resources