[sage-devel] Enhancement of Kruskal Algorithmn

Hello guys, I would like implement an enhancement of kruskal algorithm as provided in this paper http://algo2.iti.kit.edu/documents/fkruskal.pdf. This Algorithm gives an expected complexity of O(E + Vlog(v)*log(E/V) where E is number of

Re: [sage-devel] Re: How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages

On 2019-03-08 19:18, Volker Braun wrote: * If is optional then add a #warning that it is recommended Yes, it's optional but the hard part is figuring out whether it's supported or not. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsub

Re: efficiency in creating multivariate polynomial rings [Re: [sage-devel] problem with scalar multiplication: polynomial and vector]

On 01.03.19 03:59, Travis Scrimshaw wrote:> IMO we do not want there to be too much of a distinction between > multivariate polynomial rings in 1 variable and univariate > polynomial rings. I would say the proper thing to do is to pass along > the underlying implementation as part of the MPoly func

[sage-devel] fix or not? [Re: efficiency in creating multivariate polynomial rings]

The question remains: Do we want the change proposed in https://trac.sagemath.org/ticket/27364 fixing the mentioned issue (but introducing a slowdown) or not? (I somehow tend to say "we want that", because the change obviously fixes a bug. (It seems natural that the MPoly functor returns a MPoly

Re: efficiency in creating multivariate polynomial rings [Re: [sage-devel] problem with scalar multiplication: polynomial and vector]

On 01.03.19 03:59, Travis Scrimshaw wrote:> IMO we do not want there to be too much of a distinction between > multivariate polynomial rings in 1 variable and univariate > polynomial rings. I would say the proper thing to do is to pass along > the underlying implementation as part of the MPoly func

Re: [sage-devel] Linux build fails on sagelib (and numpy?)

On Fri, Mar 8, 2019 at 5:29 PM Michael Orlitzky wrote: > > On 3/7/19 10:34 PM, Ike Stoddard wrote: > > Do you have/know a developer working on it? Shell or m4 or whatever to > > fold detection in? > > The authors of these packages ought to have canonical tests for > > existence/version that can be

[sage-devel] Re: How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages

You only need MACOSX_DEPLOYMENT_TARGET / -mmacosx-version-min when building binaries to run on older mac versions. Whoever distributes cysignals should decide which min sdk version they support. What is bound to go wrong is that somebody builds an application that includes your library with thei

Re: [sage-devel] Linux build fails on sagelib (and numpy?)

On 3/7/19 10:34 PM, Ike Stoddard wrote: > Do you have/know a developer working on it? Shell or m4 or whatever to > fold detection in? > The authors of these packages ought to have canonical tests for > existence/version that can be included. For C and C++ libraries, autoconf provides most of what

[sage-devel] HN discussion of Sage

There is a short HN discussion of Sage here, that is possibly of interest: https://news.ycombinator.com/item?id=19335269#19336424 -- Best Regards, William Stein CEO, SageMath, Inc. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscr

Re: [sage-devel] How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages

On Fri, Mar 8, 2019 at 2:00 PM Jeroen Demeyer wrote: > > On 2019-03-08 10:42, Jeroen Demeyer wrote: > > (*) For some reason, the analogous C header works > > regardless of MACOSX_DEPLOYMENT_TARGET. Unfortunately, this header is > > not compatible with C++, so I really need . > > I just realized t

Re: [sage-devel] How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages

On 2019-03-08 10:42, Jeroen Demeyer wrote: (*) For some reason, the analogous C header works regardless of MACOSX_DEPLOYMENT_TARGET. Unfortunately, this header is not compatible with C++, so I really need . I just realized that I tried this only with g++ on Linux. With clang++ on OS X, does

Re: [sage-devel] How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages

Fri 2019-03-08 11:21:09 UTC+1, Dima Pasechnik: > > I gather openblas has moved to 10.8 from 10.6, see > https://github.com/xianyi/OpenBLAS/issues/1580 > > Realistically, 10.9 is OK too, I don't think it's actually possible to > build current Sage on anything older than 10.11 or so... Current S

Re: [sage-devel] How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages

I gather openblas has moved to 10.8 from 10.6, see https://github.com/xianyi/OpenBLAS/issues/1580 Realistically, 10.9 is OK too, I don't think it's actually possible to build current Sage on anything older than 10.11 or so... On Fri, Mar 8, 2019 at 9:42 AM Jeroen Demeyer wrote: > > Hello, > > Wh

[sage-devel] How to deal with MACOSX_DEPLOYMENT_TARGET in Python packages

Hello, While working on cysignals, I encounted an issue with $MACOSX_DEPLOYMENT_TARGET. I have a fix, but I don't know if it's good. It's not specific to Sage, but it will affect Sage since cysignals is a Sage package. For cysignals, I'd really like to use MACOSX_DEPLOYMENT_TARGET >= 10.9 s