Skip to content
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

Complex number support #45

Open
davedelong opened this issue Jul 8, 2013 · 10 comments
Open

Complex number support #45

davedelong opened this issue Jul 8, 2013 · 10 comments

Comments

@davedelong
Copy link
Owner

I got an email asking for complex number support. It turns out <complex.h> is for complex numbers, and appears to have enough mathematical primitives to make implementing the functions relatively straight-forward.

However, parsing would be a royal pain.

@davedelong
Copy link
Owner Author

Actually, parsing would be easy. It'd just need a new left associative unary operator i with an extremely high precedence.

The problem (for now) would be subclassing NSNumber.

@davedelong
Copy link
Owner Author

Maybe using this? https://github.com/dankogai/swift-pons

@rmehta33
Copy link

rmehta33 commented Apr 5, 2019

Did this ever get implemented? Would be very very helpful

@davedelong
Copy link
Owner Author

@rmehta33 I have not implemented this. How are you thinking you'd use it?

@rmehta33
Copy link

rmehta33 commented Apr 9, 2019

Not sure what you're asking exactly, like in what scenario or in the code (ex. "(5+5i)*2")?
Sorry I haven't been able to respond quicker

@davedelong
Copy link
Owner Author

Sorry for being unclear.

What is the scenario you’re wanting to use this in? Why do you want this feature?

(While adding support for the syntax would be pretty straight-forward, making the math actually work would be quite involved)

@davedelong
Copy link
Owner Author

I realize that statement is also a reversal of the original issue description 😅

I believe that parsing would be “easy” by making i be a postfix unary operator to “complexify” its argument.

The work would be in that all the implementations of the evaluation functions currently are expecting real numbers, and I think I’d need to come up with either a new numeric type (instead of Double) and make all the functions use that, or somehow add overloads for every function to handle imaginary parameters.

@rmehta33
Copy link

rmehta33 commented Apr 9, 2019

I'm trying to build a calculator for an ios app (like I'm assuming most are using this library). I would use another library, although I can't find any math parser for ios that handles imaginary numbers. So, this feature would avoid me from having to build one from scratch.

Since you mentioned this library works off of Doubles, I did find an "extension" of sorts for imaginary numbers for Doubles in swift here -> https://github.com/gongzhang/swift-complex-number. Hopefully this would avoid having to reformat the code to accept a different type.

Anyhow, thanks for the responses!

EDIT: I looked further into the library, and I misread it as an extension of sorts. The best thing I could come up with is https://github.com/dankogai/swift-complex, a closer idea to what I was originally thinking the library above did. I tested it out and it should handle the basic operations (+, -, /, *).

@swainwri
Copy link

Continuing on with the complex number support. My App to plot 3d surfaces requires multiple solutions, as an example y = 5.0sqrt(1-xx/9-zz/16) describes an ellipsoid with axis dimensions 3,4,5. Is it possible for me to make a Customised Function returning the negative and positive solutions or would this have to supported from within your code? Another example the torus: y = sqrt(25- (10 - sqrt(xx+z*z))^2) would produce multiple solutions. Cube roots would return real and complex solution, such that my app could generate a Riemann surface.

@rmehta33
Copy link

@davedelong I thought a bit more about this. By creating an extension for a float imaginary number for type Double, and then, like you suggested overriding the Double operations in an extension, there should be minimal change in the code if any at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants