Smallest Common Multiple - can't pass last test

Smallest Common Multiple - can't pass last test
0

#1

Tell us what’s happening:
All tests passing except the last one ([23, 18]). But! It works fine in JavaScript online testers elsewhere.

Your code so far




function smallestCommons(arr) {
let result;
let max;
let min;
arr[0]>arr[1] ? (min=arr[1], max=arr[0]) : (min=arr[0], max=arr[1]);
let range=[];

// Creating Array of all sequential numbers in the given range
for (let i=min; i<=max; i++){
    range.push(i);
}

let n=max;
let check=false;
   
while (check===false) {
    if (range.every(elem => n%elem===0)){
        check=true;
        result=n;
        }
    n++;

// Condition to prevent infinite loop. Test is not passing with or without this part of code
    if (n>100000000){
        console.log("Emergency stop");
        break;
    }           
        
}
console.log(result);
return result;
}


smallestCommons([1, 5]);

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0.

Link to the challenge:
https://learn.freecodecamp.org/javascript-algorithms-and-data-structures/intermediate-algorithm-scripting/smallest-common-multiple/


#2

In the test case of smallestCommons([1, 5]), your every function evaluates the following code 200 times before returning the answer 60.

n % elem === 0

In the test case of smallestCommons([23, 18]), your every function evaluates that same code above 36,340,788 times. That is a lot of comparisons and ends up taking longer than the FCC test engine allows. I do not know the exact amount of time it allows (maybe less than a fraction of a second?), but if a script takes too long, then there is a built-in infinite loop protector which will stop the code from continuing. In your case, it is not an infinite loop, but the test engine believes it is, so your code stops at some point, which ends up not returning the correct answer.

All of the FCC challenges have been designed so an efficient algorithm can avoid the infinite loop protection from kicking in. You need to rethink your algorithm, because you are making too many comparisons.


#3

FWIW the FCC source code has loopTimeout set to 1000, whether or not it’s changed in production idk


#4

That is interesting, because when I test the OP’s code on the FCC site, it only makes it about 100ms before the code stops.


#5

Here’s where I saw it

Comments in the code seem to suggest that a value of 1000 corresponds to 100ms

That seems odd to me but I guess that’s how it works


#6

Thank you! Now I got what the problem is and can work it.