Support for BigNumber Complex operations with arbitrary precision

[valera-rozuvan]

First of all - I want to thank the author for this awesome library! 👍 @josdejong

Now on to business. For a project of mine, I need the ability to perform arbitrary precision operations on complex numbers. I have searched far and wide for such a library in JavaScript world, but I can't find one.

mathjs also doesn't extend arbitrary precision arithmetic to the complex plain. See this JsFiddle example that illustrates my point. Basically, when you do:

math.config({number: 'BigNumber'});

var real_answer = math.eval('2.00000000000000000001 + 3.000000000000000000000002');
var complex_answer = math.eval('2.00000000000000000001 + 3.000000000000000000000002i');

$('#output').append(math.format(real_answer, {precision: 30}) + '<br />');
$('#output').append(math.format(complex_answer, {precision: 30}));

you get the following output:

5.000000000000000000010002
2 + 3i

My questions are:

1. Does mathjs project plan in the future to add arbitrary precision arithmetic for complex numbers?
2. Is mathjs project interested in this feature? If I work on this, and submit a pull request, will it be accepted?
3. Maybe I missed it... Is there an arbitrary precision complex number JS library out there somewhere?

PS: Such functionality is available in other languages, as a 3rd party library. See for example http://mpmath.org/ for the Python language.

[josdejong]

Yes we definitely have plans to add support for BigNumbers and Factions to both Units and Complex numbers.

In the case of complex numbers this will require coordination with @infusion who has created the complex.js library.

My idea for this is roughly: in the Unit and Complex classes, create static methods add, subtract, multiply, divide, etc. on the prototype, and replace all usages of operators +, -, *, / with calls to these static methods will simply do function add(a,b) {return a + b}. This abstraction allows us to replace these methods with the functions add, subtract, etc. from math.js which support numbers, BigNumbers, and Fractions and voila :)

[valera-rozuvan]

@josdejong But the actual implementation of abs(), sqrt(), etc. functions (arbitrary precision version of these functions) will have to happen on the side of Complex.js, right?

[josdejong]

Complex.js should provide a base implementation of all basic arithmetic functions that it uses internally (just for numbers), and should allow overriding them with a function that support types like BigNumbers.

[valera-rozuvan]

Created an issue for this over at Complex.js project rawify/Complex.js#4 .

[valera-rozuvan]

For the actual implementation, we can use the following paper for reference: "Implementing complex elementary functions using exception handling" [Hull, Fairgrieve, Tang; 1994]. A Postscript version is available at ftp://www.cs.toronto.edu/na/reports/cmplx-elem-fcns.ps.gz .

[infusion]

Good evening,

we had this topic quite a few times now and I'm totally in favor for it. The very last time, it was the discussion about arbitrary large fractions/rational numbers. I think we should think more carefully about the whole type system, before we go to work. We have math.js as a wrapper for decimal.js, fraction.js and complex.js and implementing much higher logic on top of these. The question is, should we build two new classes, as 1:1 translations of fraction.js and complex.js using the api of decimal.js or should we create more abstract types, with a dynamic underlaying structure, like I did with polynomial.js.

Personally, I would prefer code duplication and creating an infinity Complex and Fraction type, instead of changing the actual projects, as I spent quite some time on them to have them optimized the way they are now. From the math.js perspective, it would be still the same: being the dispatcher between data types and applying higher rules to the underlaying API's. Maybe a clever build system could reduce the actual code size, which is shipped.

Another question is, is decimal.js needed as direct math.js dependency or could we rely completely on infinity complex numbers, which uses a dependency for number representation.

(sorry, I'm brainstorming a bit...) What about keeping fraction.js & complex.js the dependency of math.js as it is and shipping two class files with each project, one relying on decimal.js and the original file. However, the more npm'ish-way would be to create a completely different project, like big-fraction.js and big-complex.js or something similar.

Actually, it goes even further, what I started working on is a linear algebra library, which can be based on different types, like building a ℂ^{4x4} or ℚ^{3x3}. Even such things should be thought of, when we talk about the type system. We can buy time with a quick and dirty 10min replacement of all elementary operations by API calls in complex.js and fraction.js (unit test coverage is quite extensive to do something like that) but for the long term, we should discuss a cleaner solution.

Robert

[valera-rozuvan]

So what's the plan? How do we proceed forward? What can I help with?

I am very interested for this feature to be implemented as soon as possible!

[infusion]

@josdejong, what you think about duplicating the source of fraction.js and complex.js inside their actual source tree for math.js and replacing every atomic operation with a configurable operator system there? By doing it this way, you can provide the operator-system. We can make it also the new default-behavior of the classes, but I'd like to retain the originals.

What about a configuration like this:

Fraction.op = {
'add': (a, b) => a + b,
'sub': (a, b) => a - b,
...
};

which you can substitute on initialization with:

Fraction.op = {
'add': (a, b) => a.add(b),
'sub': (a, b) => a.sub(b),
...
};

And the same of course for Complex.

Robert

[josdejong]

@infusion that's exactly what I meant :D (#694 (comment))

The libraries like complex.js and fraction.js should know nothing about each other nor math.js. They should be standalone and glued together by math.js by replacing these simple arithmetic operations with higher level ones.

I expect no performance penalty as JS engines should inline these simple functions like 'add': (a, b) => a + b, and it gives a lot flexibility in this regard.

[cakenggt]

I would like to add that I am also looking forward to this feature, as it will make deep zooms on the mandelbrot set possible in Javascript with your libraries.

[hsmyers]

Should you need egging on, I have plenty of eggs!

[josdejong]

?

[cshaa]

What's the current status of this issue? BigComplex would come in handy in #1741.

[harrysarson]

This issue is waiting for someone willing to invest the time to implement it I believe.

[harrysarson]

It looks like a fundamental adaptation to the way math.js interacts with numeric values would be nessessary though so this is not a small feature to implement.

[josdejong]

It's indeed not trivial but very well doable. Similar to the solution used in Unit, which also supports multiple numeric types. It boils down to what is discussed before #694 (comment):

Complex.js should provide a base implementation of all basic arithmetic functions that it uses internally (just for numbers), and should allow overriding them with a function that support types like BigNumbers.

[gwhitney]

Just wanted to note that template types as per the Pocomath proof-of-concept would be another way to provide this same functionality.

[gwhitney]

Yes, that's a bit of a quandary. It would be very nice to reuse the excellent effort and organization that went into Complex.js, but I am a bit unclear how to make Complex.js independent of the sort of JavaScript entity being used to represent the real and imaginary parts...

[josdejong]

It boils down to replacing all operators like + - * / in Complex.js that operate on the values (.re and .im) and replace them with functions add, subtract, multiply, divide, etc. These functions must be injected via a factory function like say createComplex({ add, subtract, multiply, divide }). That would allow you to use an alternative numeric type. It's basically the same as how Unit right now works, supporting multiple numeric types.

This adds a layer of complexity and abstraction to the library though, and requires quite a refactoring, so I can understand it if Robert doesn't want to go that way with Complex.js.

[gwhitney]

Or I guess if everything in sight becomes TypeScript then it has to become Complex<T> where T is the type of the components. But maybe then you can assume that the type T carries the operations, so that rather than injection, the implementations write z.re.multiply(z.im)?

[gwhitney]

Oh, I guess that's not really how mathjs is designed right now, the operations for types are not put on the types but are global functions. So I guess if that design pattern carries over to a TypeScript version, it will both have to be a generic Complex<T> and have an operation injection step...

[josdejong]

Yes good point, a solution based on a numeric class with methods like .add, .multiply, etc instead of the native operators is also an option.