-
-
Notifications
You must be signed in to change notification settings - Fork 528
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
factor ignores complex conjugate #36833
Comments
From my understanding the problem comes from the declaration of the
Since no domain is assumed here in the default case this is passed on downwards and therefore complex is never assumed. |
@jlportner, |
I found it in the file |
I checked it and I found that the issue is with the default value only because whenever we were defining a variable without specifying any domain it was calling |
@jlportner I have created a PR, can you review it ? |
How about sage: y = SR.var("y", domain="complex")
sage: factor(y*conjugate(y))
y*conjugate(y) I'm not sure whether making |
This patch fixes sagemath#36833 by changing the default domain of SR.var() function to complex. By this way, every variable whose domain is not defined will be considered in complex plane, by default. The issue was with the default value only because whenever we were defining a variable without specifying any domain it was calling symbol() function with domain=None; Subsequently, it calls new_Expression_symbol() function with domain=None. In this code, I found that it was not giving any specific domain to the variable and so when we define a new variable using SR.var() function, it is passing the is_real() (Because it does not have any specific domain) test but giving the wrong answer on factor() function, if we assume that the variable is in complex plane by default which is correct according to the documentation. <!-- ^^^^^ Please provide a concise, informative and self-explanatory title. Don't put issue numbers in there, do this in the PR body below. For example, instead of "Fixes sagemath#1234" use "Introduce new method to calculate 1+1" --> <!-- Describe your changes here in detail --> <!-- Why is this change required? What problem does it solve? --> <!-- If this PR resolves an open issue, please link to it here. For example "Fixes sagemath#12345". --> <!-- If your change requires a documentation PR, please link it appropriately. --> ### 📝 Checklist <!-- Put an `x` in all the boxes that apply. --> <!-- If your change requires a documentation PR, please link it appropriately --> <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> <!-- Feel free to remove irrelevant items. --> - [x] The title is concise, informative, and self-explanatory. - [x] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [x] I have created tests covering the changes. <!-- List all open PRs that this PR logically depends on - sagemath#12345: short description why this is a dependency - sagemath#34567: ... --> <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> URL: sagemath#36841 Reported by: Ruchit Jagodara Reviewer(s): Dima Pasechnik, Ruchit Jagodara
Steps To Reproduce
Expected Behavior
The expected result for this would be to just return y * conjugate(y) as by documentation when declaring y as a variable of SR it is assumed that y is in the complex plain.
Actual Behavior
The factor function treats y as a real variable and thus returns the wrong result of y^2.
Additional Information
No response
Environment
Checklist
The text was updated successfully, but these errors were encountered: