Not a library, built-in js

@@Poylol i don't think you know what a library is, just because it's imported automatically doesn't mean it isn't a library

@kyaki101 my bad I did not know if you were referring to the Math library, which yes, is a library; or the reduce method, which is a pure feature of js

@@Poylol no no, I mean that even if there isn’t a prefix like Math.something, doesn’t mean it’s no a library, like if you do fetch in js, you’re still using a library

@kyaki101 from my understanding, the prototype methods are part of es6 and other past versions and as equally as other features like promises and classes they are features of the language. But I may be wrong and if I am TIL something new

build-in function is mostly better than plain code in languages like js, python.

The reduce function has been shown to be less performant than other loops such as Array.forEach, and standard for. Generally if performance is a big key, it should be avoided. It's actually pretty rare (arguably non-existent) for Array.reduce to be the best solution.

No. It tries to pass 999999 arguments to a function. But passing so many arguments is simply not supported in JS (i.e. even if you wrote something like myFunc(1, 2, 3, <imagine rest of arguments here>, 999997, 999998, 999999) it wouldn't work)

Is initializing with first element good as well?

What are you talking about? It's simply going down the list and taking the max of the current max and the next head of the list. The first number when compared against the second create the accumulator so if you have negatives only there then it'll pick the least negative to start.

@@me-low-keynot if the list is empty

I can tell you didn't try it out. that's equivalent to: arr.reduce((accumulator, current, index, array) => Math.max(accumulator, current, index, array)) and it doesn't work

It slower :( unless you have this O(n) sorting algorithm that I made but will never show anyone because I’m planning to sell it Google, for millions.

@@deadchannel8431 you are right. In my defence, performance was not an object lol

What makes you think that a max function would need to be recursive?

Does a function call really have that much of an effect on the performance? converting it into a for loop probably have more of an effect than that also instead of doing .reduce((a, b) => Math.max(a, b)), just (edit: below doesn't actually work, nvm) doing .reduce(Math.max) also removes a function call (I think) and is more readable

@@sepdronseptadron The interpreter needs to do 'more' work for a function call than a simple branching statement. The interpreter will have to execute more instruction just to setup the function call than to compare two variables as in ternary operator. However with modern CPU which can execute instructions with clock cycles in GHz range, as you said, I guess it does not really have much effect. However I ran a benchmark with 100 million integer array. The results are Math.max: 1.033s ternary: 838.819ms In terms of absolute time its meaningless, but in terms of time percentage, calling Math.max is 23% slower than ternary operator.

@@StarnikBayley oh dam, didn't know it was as much as 20% also have you tried a normal for loop and what about using TypedArray? I'll benchmark and update

@@sepdronseptadron there you go Math.max: 1.050s ternary: 840.984ms classic for loop:ternary: 172.282ms classic for loop:Math.max: 227.239ms In a classic for loop, where all the overhead of array.prototype methods are eliminated, Math.max is 30% slower than ternary operator. Yeah, in theory typed array may be faster but when JS engines like v8 are heavily optimized, I am not quite sure. I am not seeing any performance improvement with Int32Array for this particular scenario.

@@StarnikBayley Got about the same results what surprised me a through is that for of is about the same speed as reduce I wanna do a bit more tests and see which one's faster I wanna try if using multiple "accumulators" will make a difference

what? no it doesn't?