Write Higher Order Arrow Functions - Purpose of parseInt?

Write Higher Order Arrow Functions - Purpose of parseInt?


Tell us what’s happening:
I was stuck on this problem for a long time and decided to check the hint to understand the solution. However, I encountered that the solution uses parseInt on the “num” iterator. I don’t understand why parseInt or the remainder operator would be used. I thought that parseInt converts strings to integers? Why would it be used on an array in which every element is already an integer? Also, what does using the remainder operator accomplish in filtering for decimal places? Wouldn’t a number divided by itself always have no remainder?

Here is the solution:

Your code so far

const realNumberArray = [4, 5.6, -9.8, 3.14, 42, 6, 8.34, -2];
const squareList = (arr) => {
  "use strict";
  // change code below this line
  const squaredIntegers = arr.filter( (num) => num > 0 && num % parseInt(num) === 0 ).map( (num) => Math.pow(num, 2) );
  // change code above this line
  return squaredIntegers;

// test your code
const squaredIntegers = squareList(realNumberArray);

Your browser information:

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

Link to the challenge:


Welcome to the tier of programming where exactitude matters. The link goes to a heading with your exact answer. I google “mdn <javascript concept or function name>” all the time:


parseInt is just being used like Math.floor, your confusion exemplifies why that might be a bad idea. It potentially communicates something confusing to the reader.

// With parseInt
3.14 % parseInt(3.14) // equal to 3.14 % 3

// Without parseInt
3.14 % 3.14


Instead of parseInt(num), you can also use Math.floor(num). They both will do the same. If you debug using “console.log()”: console.log(Math.floor(2.6)) or console.log(parseInt(2.6))
They will give you the same value. However, parseInt takes a string, and will convert the number to a string before doing what is does. Math.floor on the other hand is made to work on numbers.


I feel like this is a bit of cargo cult programming copied from somewhere (someone trying to write a frac [exact opposite of floor] function) - there’s literally no difference in output between that and the much clearer n % 1 == 0

// This works fine:
function isInt(n) {
  return n % 1 === 0;
// This should return the decimal part of a number; 
// kinda fails most of the time because floating point:
function badFrac(n) {
  return n % 1;

// This returns exactly the same thing and fails
// in the same way. + because of JS, parseInt works
// but _really_ shouldn't be used for this
function otherBadFrac(n) {
  return n - parseInt(n);

// This returns exactly the same thing and fails
// in the same way
function andAnotherBadFrac(n) {
  return n - Math.floor(n);