Taking too much memory? Weird integer behavior? Why does it break?

JavaScript
1

Hi all-- I’m working through Project Euler #5, and I have a program that successfully finds the solution for an n of everything up to 17-- and then at 17 or larger it fails. I’m wondering if this is a sign that I’m somehow overloading a variable once the numbers get too big?

Here’s my solution so far:

function smallestMult(n) {
  var num = n, div = n;

  while (div !== 1) {
    if (Number.isInteger(num/div)) {
      console.log(num, div)
      div--;
    } else {
      num++;
      div = n;
    }
  if (div == 1) {
    console.log(num);
  }
  }
}

smallestMult(9);

It passes for the small numbers just fine, but not the big ones— help me understand why not?
Thanks!

2

Hi, that’s a hell of a coincedence, I am working on exact same problem right now literally.
I will post code when finish.

That’s what i would think.

I’ve never used this one. Using % operator for division check.

3

Thanks-- I’m fine finding a different solution. I’m just more interested to know why this solution doesn’t work.

4

Sorry, I didn’t mean to give direct answer, I mean I’ll post it to get feedback.
For now I have problem with logic >>> my results are smaller numbers than expected behaviour.

5

It works if you have the resources, and the time :slight_smile: Ya, it is pretty inefficient.

I would definitely approach this from a different angle. I’ll give you a hint. I think already know the biggest number it could be, right? That would be every number from 1 to n multiplied together. So perhaps use that to your advantage. And then what is the second biggest number it could be?

1 Like
8

Yup, as you guessed, it’s too inefficient. Euler problems are designed to make the direct, brute force solution too slow. For this one, you’ll probably want to do some research on Wikipedia into LCM and GCD.

9

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.