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

Fix for mpc precision inconsistency issue #179 #181

Merged
merged 2 commits into from Jan 25, 2018

Conversation

Projects
None yet
3 participants
@vinklein
Copy link
Contributor

commented Jan 25, 2018

Fix for issue #179

  • .real and .imag mpfr now return the same precision as their mpc
  • add doctests for these cases.
gmpy2_mpc_misc.c : Fix issue #179
- .real and .imag now return the same precision as their mpc

- add doctests for these cases.
@videlec

This comment has been minimized.

Copy link
Contributor

commented Jan 25, 2018

Could you also test

  • different precision for real and imag
  • reconstruction
>>> x = gmpy2.mpc("1.3142123+4.3e-1001j", precision=(70,37))
>>> gmpy2.mpc(x.real, x.imag) == x
True
@vinklein

This comment has been minimized.

Copy link
Contributor Author

commented Jan 25, 2018

This one

>>> gmpy2.mpc(x.real, x.imag) == x
True

don't work, it return False because gmpy2.mpc(..) take the default precision if no precision is specified in parameter.

I don't have a clear opinion if it's a suitable behaviour or not. Any point of view on it ?

@videlec

This comment has been minimized.

Copy link
Contributor

commented Jan 25, 2018

This one

>>> gmpy2.mpc(x.real, x.imag) == x
True

don't work it return False because gmpy2.mpc(..) take the default precision if no precision is specified in > parameter.

That's a pity! In this very specific case the input has a very well defined precision that would better be used. But let's keep it for another PR.

@vinklein

This comment has been minimized.

Copy link
Contributor Author

commented Jan 25, 2018

On the other hand if you do something like gmpy2.get_context().real_prec = 100 you don't want it to be ignored if you do an gmpy.mpc() call without precision parameter.

@casevh

This comment has been minimized.

Copy link
Collaborator

commented Jan 25, 2018

@vinklein

This comment has been minimized.

Copy link
Contributor Author

commented Jan 25, 2018

It doesn't work either.

>>> x = mpc("1.3142123+4.3e-1001j", precision=(70,37))
>>> mpc(x.real, x.imag, precision=1) == x
False

Is this a new issue ?

@casevh

This comment has been minimized.

Copy link
Collaborator

commented Jan 25, 2018

It would be a new issue. I will merge this PR and create a new issue for maintaining precision of exact input.

@casevh casevh merged commit 337b2d0 into aleaxit:master Jan 25, 2018

@vinklein vinklein deleted the vinklein:fix_issue_179 branch Jan 26, 2018

vbraun added a commit to vbraun/sage that referenced this pull request Feb 1, 2018

Trac #22928: Conversion between gmpy2 and sage objects
The library `gmpy2` supports conversions by the use of special methods.
In order to allow conversion of Sage objects into gmpy2 objects, we
implement the following methods
- `__mpz__` on Sage Integer
- `__mpq__` on Sage Rational
- `__mpfr__` on relevant Sage real numbers
   - `RealNumber` (`sage.rings.real_mpfr`)
   - `RealDoubleElement` (`sage.rings.real_double`)
- `__mpc__` on relevant Sage complex numbers
   - `ComplexDoubleElement` (`sage.rings.complex_double`)
   - `MPComplexNumber` (`sage.rings.complex_mpc`)
   - `ComplexNumber` (`sage.rings.complex_number`)

Conversly, we make Sage integer, rational, real and complex constructors
accept gmpy2 arguments.

Upstream issues:
- aleaxit/gmpy#180
- aleaxit/gmpy#181

URL: https://trac.sagemath.org/22928
Reported by: vklein
Ticket author(s): Vincent Klein
Reviewer(s): Jeroen Demeyer, Vincent Delecroix

@vinklein vinklein referenced this pull request Feb 22, 2018

Closed

Next release ? #186

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.