Formatting complex numbers

[TLCFEM]

See https://stackblitz.com/edit/js-xt7ffy?devToolsHeight=33&file=index.js

It seems like formatting complex numbers in exponential mode is based on the magnitude, sqrt(re^2+im^2). This gives both real and imaginary parts if they are of similar magnitudes, otherwise one part would be hidden, such that '1.23456789+.0023456789i' gives 1.2e+0.

But the major motivation to use exponential format is to reveal significant figures. Such a behaviour does not meet this purpose.

Wondering if there are any recommendations? Or if formatting each part independently can be submitted as a feature request?

[josdejong]

Thanks for bringing this up. The code is indeed rounding re or im to the largest order of magnitude:

mathjs/src/type/complex/Complex.js

Lines 59 to 69 in 76c8c62

	// round either re or im when smaller than the configured precision
	const precision = isNumber(options) ? options : options ? options.precision : null
	if (precision !== null) {
	const epsilon = Math.pow(10, -precision)
	if (Math.abs(re / im) < epsilon) {
	re = 0
	}
	if (Math.abs(im / re) < epsilon) {
	im = 0
	}
	}

This was done because with complex calculations, you almost always have round-off errors involved, and it is really hard to read complex numbers when you have to check against re or im being "about zero", values that would be formatted like 1 + 5.551115123125783e-17i.

It makes sense to me to not apply that rounding to zero when using notation exponential or engineering. The rounding examples that you give are indeed giving wrong/misleading results. What do you think?

[TLCFEM]

Thanks for the reply. Rounding is indeed an issue. There is no doubt that 1 + 5.551115123125783e-17i is ugly, I presume we could all agree on that. There is a line between what is really small and what appears to be small. Unfortunately, this criterion changes from application to application and thus is not easy to determine.

What comes to my mind is, maybe it is possible to add a field related to ulp/epsilon, say, multiple of epsilon, or just a small threshold, which can be used to determine whether to treat the smaller of two as zero? So basically, Math.pow(10, -precision) could be an independent field?

[josdejong]

hmm. Yeah, it makes sense to make this epsilon configurable, instead of having it tied to precision. Maybe use the global configured epsilon? And maybe it should even be an option to decouple the formatting of re and im from each other, but I'm not sure if there are use cases for that (currently this is decoupled implicitly, when precision is not configured).

Checking if values are "about zero" or negligible small compared to an other value are tricky. See also this recent discussion #2838 started by @gwhitney.

[gwhitney]

Sorry what was wrong with Jos's initial suggestion to not do the rounding when notation is 'exponential' or 'engineering' mode (where the difference in magnitude should be obvious), but round in the ordinary notation with respect to precision (because after all, the smaller one is zero to the specified precision with respect to the first)? I mean, the precision parameter is specified by the client of the library, so if it is blurring small re or im parts too much, the client can just bump up the precision or switch to exponential or engineering notation.

[josdejong]

Thinking about it more, I think that not doing the rounding in case of 'exponential' or 'engineering' notation makes sense. What do you think @TLCFEM?

[josdejong]

Ok if there are no further inputs, let's plan for the following:

• Change format for complex numbers to not apply rounding in case of 'exponential' or 'engineering' notation
• I think we should mark this as a breaking change.

Anyone interested in implementing this new behavior?