>From the point of view of packaging Sage for distributions, having Sage
able to use GMP rather than MPIR is a win, since it means packaging Sage
would not require adding MPIR to the distribution (adding MPIR is one of
the blockers for packaging a more recent Sage in Debian).
-Tim Abbo
On Tue, Apr 21, 2009 at 9:38 AM, dmharvey wrote:
>
> Hi folks,
>
> I have made a basic spkg for GMP 4.3.0:
>
> http://sage.math.washington.edu/home/dmharvey/gmp-4.3.0.spkg
>
> I've only tested on a linux opteron system. It builds fine; there are
> various doctest failures that look related to non
You are always going to be welcome. I always feel like a Johnny come
lately with regard to Sage, even though I started contributing to Sage
with my qsieve about 2.5 years ago. In contrast, you were there, right
in the guts of the thing, right from the start! Your contribution has
always been, and
On Wed, Apr 22, 2009 at 6:22 AM, David Harvey wrote:
>
> Oh look, I've been involved in Sage since mid-2006. This is the first
> major strategic decision with which I've disagreed so strongly, and
> the first time I've felt truly unwelcome on this list. It's quite
> depressing.
>
> I sincerely be
2009/4/22 David Harvey :
>
> Oh look, I've been involved in Sage since mid-2006. This is the first
> major strategic decision with which I've disagreed so strongly, and
> the first time I've felt truly unwelcome on this list. It's quite
> depressing.
>
Of course you are not unwelcome on this list
Oh look, I've been involved in Sage since mid-2006. This is the first
major strategic decision with which I've disagreed so strongly, and
the first time I've felt truly unwelcome on this list. It's quite
depressing.
I sincerely believe the costs of the fork to the community outweigh
the benefits.
2009/4/22 Georg S. Weber :
>
> I have on my to-do-list for a long time now the task to introduce
> canonical choices for e.g. P1List and for bases of modular symbol
> spaces. It would help a lot when interfacing with C libraries that do
> certain calculations very fast, e.g. the set of Heilbronn
Hi all,
On 22 Apr., 06:45, William Stein wrote:
> 2009/4/21 David Harvey :
>
>
>
> > On Apr 21, 2:31 pm, Bill Hart wrote:
>
> >> In some cases it would be less work to just contribute features
> >> directly to MPIR to bring the current code up to par.
>
> > I think you are underestimating how m
I apologise if this seemed rude. I should have made the point more
subtly. I'm just trying to deal with it in an open way. David has
taken clear exception to the use of MPIR in Sage by default, and some
of his points are valid for the time being.
But I want to be clear that MPIR is not going
> Seriously, it looks for all the world to me that you are intentionally
> trying to kick MPIR while it is down, knowing full well that a
> comparison is unfair at this point. I expect that by October/November
> this year we will match GMP feature for feature, and that will be
> regardless of whet
On 22 Apr, 02:02, David Harvey wrote:
> Can someone show me a benchmark where MPIR is faster than GMP? I tried
> a few basic things and couldn't find any. Someone who knows the MPIR
> codebase better than me should be able to find something.
Are you aware that our MPIRbench score on K8 is hig
On 22 Apr, 01:58, David Harvey wrote:
> I am talking about the mpn-level interface, which is relevant for a
> lot of the things I work on.
If it helps, we have made a commitment to implementing the full public
GMP interface in MPIR, including the mpn level.
As GMP developers now have an open
On 22 Apr, 01:57, David Harvey wrote:
> And whatever happened to "not reinventing the wheel"? I suppose that's
> a Sage motto but not an MPIR one?
The same argument applied to FLINT and zn_poly leads to curious
conclusions.
So which are you arguing MPIR should do.
1) Try and reuse as much c
On 21 Apr, 22:40, David Harvey wrote:
> Already it's impossible to
> install the gmp-4.3 spkg without breaking all those doctests. Over
> time, it's inevitable that the APIs of the two packages will diverge,
> unless the projects can come to some kind of agreement. I can't see
> how this can
On 21 Apr, 17:38, dmharvey wrote:
> Recently Sage switched from GMP to the MPIR fork. I make no secret of
> the fact that I disagree with this decision, although I did initially
> support MPIR. I hope that Sage can figure out some way to incorporate
> the improvements in GMP 4.3.0 (as competin
2009/4/21 David Harvey :
>
>
> On Apr 21, 2:31 pm, Bill Hart wrote:
>
>> In some cases it would be less work to just contribute features
>> directly to MPIR to bring the current code up to par.
>
> I think you are underestimating how much work it is to design, write
> and debug these things.
>
>
On Apr 21, 8:41 pm, mabshoff wrote:
> GMP-ECM 6.2.2 should be in the next Sage release. Is this fix that you
> put in thet ecm-gmp.spkg already upstream?
No I don't think so. I believe Paul Zimmermann is aware of the issue,
but you might want to ping him about it.
I don't recommend using the
On Apr 21, 8:31 pm, Craig Citro wrote:
> I also would like to see both a gmp and mpir spkg available. Even if
> someone never wanted to use gmp (for whatever reasons, be they
> licensing or other), I think it would be good to have both easily
> available -- for consistency checks, benchmarking,
On Apr 21, 8:06 pm, Robert Bradshaw
wrote:
> The only doctests that break are the xgcd ones, right? This has been
> an issue before, and so I think perhaps the doctests should be improved.
Also some doctests related to modular symbols. I don't know enough
about this area to tell whether it's
On Apr 21, 2:31 pm, Bill Hart wrote:
> In some cases it would be less work to just contribute features
> directly to MPIR to bring the current code up to par.
I think you are underestimating how much work it is to design, write
and debug these things.
And whatever happened to "not reinventing
On Apr 21, 9:38 am, dmharvey wrote:
> Hi folks,
Hi David,
> To try it out, you will need to remove SAGE_ROOT/spkg/standard/gmp-
> mpir*.spkg and replace it with the above file, before starting the
> build. (I'm not sure if you can install it into an existing sage
> build.) You will also nee
>> I wish all forks could be as amicable as the Pyrex/Cython one, but
>> understandably that is rarely the case. I support the reasons behind
>> MPIR, but I think it's a very good thing to provide a GMP spkg for
>> Sage--it gives users the choice.
>
> But Robert, that choice is illusory. Already i
On Apr 21, 2009, at 2:40 PM, David Harvey wrote:
> On Apr 21, 3:08 pm, Robert Bradshaw
> wrote:
>
>> I wish all forks could be as amicable as the Pyrex/Cython one, but
>> understandably that is rarely the case. I support the reasons behind
>> MPIR, but I think it's a very good thing to provide a
On Apr 21, 3:08 pm, Robert Bradshaw
wrote:
> I wish all forks could be as amicable as the Pyrex/Cython one, but
> understandably that is rarely the case. I support the reasons behind
> MPIR, but I think it's a very good thing to provide a GMP spkg for
> Sage--it gives users the choice.
B
On Apr 21, 2009, at 9:50 AM, William Stein wrote:
> On Tue, Apr 21, 2009 at 9:38 AM, dmharvey
> wrote:
>>
>> Hi folks,
>>
>> I have made a basic spkg for GMP 4.3.0:
>>
>> http://sage.math.washington.edu/home/dmharvey/gmp-4.3.0.spkg
[...]
>> Recently Sage switched from GMP to the MPIR fork. I
On Tue, Apr 21, 2009 at 9:38 AM, dmharvey wrote:
>
> Hi folks,
>
> I have made a basic spkg for GMP 4.3.0:
>
> http://sage.math.washington.edu/home/dmharvey/gmp-4.3.0.spkg
>
> I've only tested on a linux opteron system. It builds fine; there are
> various doctest failures that look related to non
26 matches
Mail list logo
