consider making toString() not zero out small parts

[donhatch]

trafficstars

I notice that, e.g.

• Complex(1e-16, 1e-8).toString() is "1e-8i" (I expected "1e-16 + 1e-8i")
• Complex(1e-16, 1e-16).toString() is "0" (I expected "1e-16 + 1e-16i")

It looks like this behavior is intentional: if real or imaginary part is less than Complex.EPSILON (1e-15), toString() "helpfully" ignores it.

Is this really a good idea?

In my perception, it makes toString() into a dull and less-useful instrument. For example, I wanted to add the following test cases to complex.test.js, to confirm that expm1() works properly on small inputs; it turns out that it does, but that can't be easily confirmed with these test cases, due to toString's "helpful" zeroing behavior:

{
  set: "1e-9i",
  fn: "expm1",
  expect: "-5e-19 + 1e-9i",  // fails: comes out "1e-9i" instead
},
{
  set: "1e-20i",
  fn: "expm1",
  expect: "-5e-41 + 1e-20i",  // fails: comes out "0" instead
},
{
  set: "1e-20",
  fn: "expm1",
  expect: "1e-20",  // fails: comes out "0" instead
},

On a related note (which could be made into a separate Issue if there is interest), I'm not a fan of equals() using fuzzy equality either; I find its behavior to be unmemorable and essentially never useful to me, and, conversely, there doesn't seem to be an exact equality operator, which I would find useful. It may be too late to change equals() for reasons or backwards compatibility, but perhaps an exactEquals() could be added, at least?

[infusion]

Yes, this is a tradeoff we had to made. In most cases you have some process inaccuracies you don't want to be printed out. In cases where you really need to print out those small numbers, it is probably better to copy the toString() over in your code and overwrite the original function with

Complex.prototype.toString = function() { ... }