-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for arbitrary precision complex number operations #694
Comments
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 |
@josdejong But the actual implementation of |
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. |
Created an issue for this over at Complex.js project rawify/Complex.js#4 . |
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 . |
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 |
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! |
@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 = { which you can substitute on initialization with: Fraction.op = { And the same of course for Complex. Robert |
@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 |
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. |
Should you need egging on, I have plenty of eggs! |
? |
What's the current status of this issue? BigComplex would come in handy in #1741. |
This issue is waiting for someone willing to invest the time to implement it I believe. |
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. |
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):
|
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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:
you get the following output:
My questions are:
PS: Such functionality is available in other languages, as a 3rd party library. See for example http://mpmath.org/ for the Python language.
The text was updated successfully, but these errors were encountered: