Smallest Common Multiple Inconsistency

Tell us what’s happening:
I have written an algorithm that works for all of the checks except the last one. My only theory is that I’ve written it inefficiently so that when it handles larger numbers (like the ones involved in the last check) it behaves erratically because when it runs for the last one, every time I get a different answer. I’ve looked for similar troubles but I can’t find it.

Your code so far


function smallestCommons(arr) {
  // Duplicate and sort arr into newArray
  let newArray = arr.sort(function(a, b) { return a - b; });
  let a = newArray[0];
  let b = newArray[1];
  let numArray = [];
  // Add all numbers in the range of a and b to an array
  for (var i = a; i <= b; i++) { numArray.push(i); }
  // Initialize the multiple variable
  let multiple;

  // Find smallest common multiple of a and b
  for (var i = 1; i < b; i++) {
    let mult = i * b;
    if (mult % a == 0) {
      multiple = mult;
      break;
    }
  }

  // check scm for compatibility with all numbers in range array
  // validate counts the number of nums in numArray that multiple divides evenly
  let validate = 0;
  do {
    // for every number in the numArray, check if the multiple divides it out evenly
    for (var i = 0; i < numArray.length; i++) {
      // if the multiple 
      if (multiple % numArray[i] === 0) {
        // affirm that numArray[i] divides evenly
        validate++;
      } else {
        // restart the validate count and increase multiple by the original scm
        validate = 0;
        if (a > 1) {
          multiple += a;
        } else {
          multiple += a*b;
        }
        // break out of the for loop
        break;
      }
    }
  // while the number of nums validated isn't all of numArray
  } while(validate != numArray.length)

  console.log(multiple);
  return multiple;
}


smallestCommons([23, 18]);

Your browser information:

User Agent is: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36.

Link to the challenge:

you are correct, it is for the inefficiency- it is triggering the infinite loop protection because it is taking too long and so it is being stopped premature