London | 26-ITP-Jan | Angela McLeary | Sprint 1 | Sprint 1

[AngelaMcLeary]

Learners, PR Template

Self checklist

• I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
• My changes meet the requirements of the task
• I have tested my changes
• My changes follow the style guide

Changelist

This PR is about fixing median.js, Implementing dedupe.js, max.js, sum.js and refactoring include.js.

[cjyuan]

Decimal numbers in most programming languages (including JS) are internally represented in "floating point number" format. Floating point arithmetic is not exact. For example, the result of 46.5678 - 46 === 0.5678 is false because 46.5678 - 46 only yield a value that is very close to 0.5678. Even changing the order in which the program add/subtract numbers can yield different values.

So the following could happen

  expect( 1.2 + 0.6 + 0.005 ).toEqual( 1.805 );                // This fail
  expect( 1.2 + 0.6 + 0.005 ).toEqual( 1.8049999999999997 );   // This pass
  expect( 0.005 + 0.6 + 1.2 ).toEqual( 1.8049999999999997 );   // This fail

  console.log(1.2 + 0.6 + 0.005 == 1.805);  // false
  console.log(1.2 + 0.6 + 0.005 == 0.005 + 0.6 + 1.2); // false

Can you find a more appropriate way to test a value (that involves decimal number calculations) for equality?

Suggestion: Look up

• Checking equality in floating point arithmetic in JavaScript
• Checking equality in floating point arithmetic with Jest

[AngelaMcLeary]

Hi @cjyuan, Thank you for your feedback. I understand now why decimal values need special handling. toBeCloseTo() is a better choice because it checks that the result is close enough within a small margin, which avoids issues caused by floating‑point rounding.

[cjyuan]

Note: The default value of the second parameter of toBeCloseTo() is only 2
See: https://jestjs.io/docs/expect#tobeclosetonumber-numdigits

For the default value 2, the test criterion is Math.abs(expected - received) < 0.005, which may not be precise enough in some applications.

[cjyuan]

Other changes are good. Just one issue left.

[cjyuan]

This test can verify the function can return a different array.

However, there is a chance that, even though result has incorrect elements (for example, [1, 1, 1]),
the test on line 29 could still pass. Can you figure out why, and then improve the test accordingly?

[AngelaMcLeary]

Hi @cjyuan, Thanks for your feedback. I have done some research and understand that this only checks value equality, so it could still pass even if the function returns the same array or mutates it. Added checks to make sure a new array is returned and the original input isn't changed. I have added additional test.

[cjyuan]

Changes look good. Well done.

[illicitonion]

Closing PR because the January ITP run has finished. Feel free to re-open if you're still working on it.