Hello

I noticed that the smallestElement which was found with reduce function is equal to 0 which is not correct, because the notSortedArr does not contains 0.

The smallest element in this array is 1.

The bug is caused because of the initial value given to the reduced function.

I rewrote the 2 declarations using Math.min and Math.max which are more concise and fewer locs.

Best of luck!
Yavorski

Codecov Report

Merging #224 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@ Coverage Diff @@
## master #224 +/- ##
=====================================
 Coverage 100% 100% 
=====================================
 Files 143 143 
 Lines 2554 2554 
 Branches 422 422 
=====================================
 Hits 2554 2554

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5d12638...aef8f8a. Read the comment docs.

https://www.google.com.ua/search?client=ms-android-lenovo&ei=R8PBW9LmJISfsAHgzI3IDA&ins=false&q=array+starts+from&oq=array+starts+from&gs_l=mobile-gws-wiz-serp.3..0i203j0i22i30l4.2540.8958..9152...2.0..1.124.3835.34j9......0....1.......5..0j46j35i39j46i39j0i67j0i131j0i10j0i10i203.4mq7JgaAmBs ... array starts from 1???..

0 is wrong there indeed but why would you put 1 instead?

The correct starting values for the reduce way of calculating extrema are Infinity for the minimum and -Infinity for the maximum.

@lazarljubenovic not putting 1 at all, this is just the answer in this particular case with this specific array in mind. See diff for more details.

@yavorski , good catch. Thank you for PR.