Opened 4 years ago
Last modified 4 years ago
#24489 new task
modernize complex_mpfr
Reported by: | vdelecroix | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-8.2 |
Component: | basic arithmetic | Keywords: | |
Cc: | mmezzarobba, jpflori | Merged in: | |
Authors: | Vincent Delecroix | Reviewers: | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #24483, #24457 | Stopgaps: |
Description (last modified by )
Similarly to #24457 for real numbers we perform some cleaning for complex numbers in view of #17713/#24457.
step 1
- #24483: move
sage.rings.complex_field
tosage.rings.complex_mpfr
- change the string representation from
Complex Field with XX bits of precision
toComplex Floating-point Field with XX bits of precision
- (possibly) get rid of the factory
ComplexField
by making the classComplexField_class
inherits fromUniqueRepresentation
- rename
CompleNumber
/ComplexField
intoComplexFloatingPoint
/ComplexFloatingPointField
- remove the attribute
_prec
ofComplexNumber
(ampfr_t
carries its precision that can be obtained withmpfr_get_prec
) - deprecate
is_ComplexNumber(x)
/is_ComplexField(x)
in favor ofisinstance(x, ComplexFloatingPoint)
/isinstance(x, ComplexFloatingPointField)
- actually initialize the
mpfr_t
pointers in__cinit__
as it is the case for real floating point numbers inreal_mpfr.pyx
- clarify the behavior of rounding (currently there is a global (sic) variable taking care of it)
- Deprecate
CC
in favor ofCFF
see also task ticket #17713
Change History (14)
comment:1 Changed 4 years ago by
- Description modified (diff)
comment:2 Changed 4 years ago by
- Description modified (diff)
comment:3 Changed 4 years ago by
- Description modified (diff)
comment:4 follow-up: ↓ 5 Changed 4 years ago by
comment:5 in reply to: ↑ 4 ; follow-ups: ↓ 6 ↓ 10 Changed 4 years ago by
- Cc mmezzarobba added
Replying to jdemeyer:
If you are going to do serious refactoring, here is a different proposal: deprecate
complex_mpfr
altogether and usecomplex_mpc
instead as the default complex floating point field.
+1. I wanted to do that at some point but Marc Mezzarobba claimed that the mpfr version was faster and hence still needed. I will be more than happy to recycle this ticket in order to do this!
Though the branch in #24483 is still useful to liberate the module sage.rings.complex_field
needed for #24456.
comment:6 in reply to: ↑ 5 Changed 4 years ago by
+1. I wanted to do that at some point but Marc Mezzarobba claimed that the mpfr version was faster and hence still needed.
Please keep in mind #24353 which will almost certainly change timings. Unfortunately, that ticket is current stalled because it breaks MPFI. If there is a proper release of MPC, maybe I'll try to patch MPFI in Sage.
comment:7 Changed 4 years ago by
- Description modified (diff)
comment:8 Changed 4 years ago by
- Description modified (diff)
comment:9 Changed 4 years ago by
- Dependencies changed from #24483 to #24483, #24457
- Description modified (diff)
- Type changed from enhancement to task
comment:10 in reply to: ↑ 5 Changed 4 years ago by
Replying to vdelecroix:
Replying to jdemeyer:
+1. I wanted to do that at some point but Marc Mezzarobba claimed that the mpfr version was faster and hence still needed. I will be more than happy to recycle this ticket in order to do this!
My bad: it was JP Flori.
comment:11 Changed 4 years ago by
- Cc jpflori added
comment:12 follow-ups: ↓ 13 ↓ 14 Changed 4 years ago by
Yes it used to be the case, and Paul Zimmerman improved MPC but my last souvenir is that for basic operations Sage's complex_mpfr was still faster than complex_mpc surely because it does not handle special cases (NaN, infinities, and i don't know what) gracefully.
Things can have changed but there is only one way to knwom: benchmark both implementations, and I don't think I have any time for this.
On a side note, I would think it is a very good idea to get rid of complex_mpfr if we can.
comment:13 in reply to: ↑ 12 Changed 4 years ago by
Replying to jpflori:
because it does not handle special cases (NaN, infinities, and i don't know what) gracefully.
Certainly not because of that reason. First of all, checking for a special value is really trivial compared to dealing with Python objects. You need to work with least ~100 bits of precision to have a sensible benchmark because otherwise you are only benchmarking the Python overhead anyway.
comment:14 in reply to: ↑ 12 Changed 4 years ago by
Replying to jpflori:
my last souvenir is that for basic operations Sage's complex_mpfr was still faster than complex_mpc
Of course it's always going to be faster. But that's not the point. If you really want speed, use CDF
.
The thing that we should focus on is the correctness. With MPC, you are guaranteed that the answer that you receive is as good as it can be. With MPFR complex numbers, we are using some arbitrary formulas and we hope that everything works. On the one hand, we use an arbitrary-precision library but we cannot say whether the many bits that you get are actually meaningful.
If you are going to do serious refactoring, here is a different proposal: deprecate
complex_mpfr
altogether and usecomplex_mpc
instead as the default complex floating point field.