Should MPC (for arithmetic of complex numbers) be a standard Sage package?

2 views
Skip to first unread message

Dr. David Kirkby

unread,
Jun 19, 2010, 10:51:04 AM6/19/10
to sage-...@googlegroups.com
The following ticket

http://trac.sagemath.org/sage_trac/ticket/4446

is a long-standing ticket to add the MPC library for the arithmetic of complex
numbers with arbitrarily high precision as a *standard* item. (It can't easily
be made optional - at least not in its current form).

It has been open for 20 months, and seems to me we need to resolve what happens
with this. Having looked at this a bit, these are my conclusions of the current
state of this ticket. They include some comments from Paul Zimmermann, and MPC
developer.

* MPC is a C library for the arithmetic of complex numbers with arbitrarily
high precision and correct rounding of the result.
* A trac ticket #4446 has been open for 20 months to add MPC to Sage, with
43 comments on it.
* Although personally I don't know much about how this overlaps with other
components in Sage, a number of Sage developers have put a lot of effort into
ticket #4446, so there must be interest in this being in Sage
* The upstream developers have also put a lot of effort into getting this
in to Sage.
* I personally believe the MPC library code should be of high quality as it
is produced by a team of developers who in my personal opinion care about
quality. (You know I've been a bit critical of some code in Sage, but I'm
impressed with how the MPFR / MPC team work).
* The MPC library is LGPL v 2.1+
* The license on one of the patches attached to the ticket #4446 is
ambiguous, saying just "GPL", with nothing about version number(s), but I
suspect that would be easy to resolve.
* Both Linux on x86 and Solaris 10 on SPARC are primary platforms for MPC,
but OS X is a secondary platform.
* FreeBSD on x86 is a platform where a Sage port is in progress. FreeBSD is
a primary platform for MPC,
* OpenSolaris on x64, is a platform where a Sage port is in progress. This
is not listed as even a tertiary platform for MPC, though in practice MPC passed
all 57 tests for me on OpenSolaris x64 using gcc 4.4.4. (This was using Sage
4.4.4.alpha1, which uses MPIR 1.2.2 and MPFR 2.4.2.)
* Solaris 10 on x86, is a platform where a Sage port is in progress. This
is a tertiary platform for MPC, but with a report of all MPC library tests passing.

(Paul Zinnerman has remarked these primary, seconday, tertiary are categories
used by GCC, not MPC. In practice, it seems the MPC library is likely to work
with all current Sage build platforms and any that are being actively worked on).

* The Sage package initially presented for review (mpc-0.8.2svn793.spkg)
failed to even build the test suite on Solaris or OpenSolaris, but a revised
edition of the Sage package passes all tests on Ubuntu 10.04 64-bit, Solaris 10
(SPARC) 32-bit and OpenSolaris (x64) 64-bit. The initial problem was a mistake
in the packaging for Sage, rather than the MPC library.
* The package present for review is based on an SVN snapshot. Paul
Zimmermann, an MPC developer, has said this minimal changes from the stable 0.82
release. Those changes were made to address a performance issue noted by Sage
developers.
* The Sage package is not currently "optional", but would need to be
"standard". (There may or may not be ways of making it "optional", but William's
comments on the trac ticket tended to suggest it could not be.)
* The current package has not been tested much in Sage, and Yann who
submitted the package does not have much more time to spend on it, so will not
be asking William for accounts to test on other platforms.
* Jason Grout has agreed to maintain this for two years.
* A lot of work has been done on this ticket over a period of 20 months, so
it would be a shame if that is wasted.
* The MPC developers would appreciate a lot if the Sage developers could
tell them right now if they believe MPC will never become a standard package, so
they don't spend more time on ticket #4446.
* Jason has said he believes there was a vote to include this, subject to
some issues being resolved.
* I personally suspect after this length of time, people will lose patience
if a decision is not made soon.

My own opinion is that this looks good, although there is a severe lack of
evidence to show the Sage integration works on all platforms. I've yet to see
any evidence the Sage integration even works on OS X (I don't have a build on
bsd.math to check this quickly myself).

However, I've made no secret of the fact I'm not a mathematician, so it needs
some others to look at this.


Dave

William Stein

unread,
Jun 19, 2010, 10:57:09 AM6/19/10
to sage-...@googlegroups.com
On Sat, Jun 19, 2010 at 7:51 AM, Dr. David Kirkby
<david....@onetel.net> wrote:
> The following ticket
>
> http://trac.sagemath.org/sage_trac/ticket/4446
>
> is a long-standing ticket to add the MPC library for the arithmetic of
> complex numbers with arbitrarily high precision as a *standard* item. (It
> can't easily be made optional - at least not in its current form).
>
> It has been open for 20 months, and seems to me we need to resolve what
> happens with this. Having looked at this a bit, these are my conclusions of
> the current state of this ticket. They include some comments from Paul
> Zimmermann, and MPC developer.
>
>    * MPC is a C library for the arithmetic of complex numbers with
> arbitrarily high precision and correct rounding of the result.
>    * A trac ticket #4446 has been open for 20 months to add MPC to Sage,
> with 43 comments on it.
>    * Although personally I don't know much about how this overlaps with
> other components in Sage, a number of Sage developers have put a lot of
> effort into ticket #4446, so there must be interest in this being in Sage
>    * The upstream developers have also put a lot of effort into getting this
> in to Sage.
>    * I personally believe the MPC library code should be of high quality as
> it is produced by a team of developers who in my personal opinion care about
> quality. (You know I've been a bit critical of some code in Sage, but I'm
> impressed with how the MPFR / MPC team work).

I'm curious -- have you actually looked at the code? Just curious.
I haven't looked either.

A while ago I tried out the proposed MPC package for Sage, and it was
much slower than the multiprecision complex code that we already had
in Sage. I wonder if these performance issues have been addressed?

-- William


--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

Dr. David Kirkby

unread,
Jun 19, 2010, 11:35:42 AM6/19/10
to sage-...@googlegroups.com
On 06/19/10 03:57 PM, William Stein wrote:
> On Sat, Jun 19, 2010 at 7:51 AM, Dr. David Kirkby
>> * I personally believe the MPC library code should be of high quality as
>> it is produced by a team of developers who in my personal opinion care about
>> quality. (You know I've been a bit critical of some code in Sage, but I'm
>> impressed with how the MPFR / MPC team work).
>
> I'm curious -- have you actually looked at the code? Just curious.
> I haven't looked either.

Yes.

I've seen easier C code to read. I think the nature of the fact all the calls
are to mpfr makes it inherently difficult to read unless you know mpfr well,
though some more comments would not go amiss.

The build system is clean. The library is well documented. It's clearly been
tested on lots of platforms.

There is a test suite of 57 items. I know from previous experience the test
suite of MPFR (which shares at least some of the same developers), has tended to
find real bugs - it was one of those tests which discovered the memset bug in
Solaris 10. The test suite has also found compiler bugs in the past.

So overall I would have more confidence in MPC than lots of other code I see.

> A while ago I tried out the proposed MPC package for Sage, and it was
> much slower than the multiprecision complex code that we already had
> in Sage. I wonder if these performance issues have been addressed?
>
> -- William

It would appear the issue have been addressed. You would be in a better position
that me to determine if those issues are fully resolved. The last two entries in
the NEWS file are both related to performance.

Dave

Reply all
Reply to author
Forward
0 new messages