Sage is not using very sophisticated methods for computing homology. If
anyone wants to implement something better, they are certainly welcome to.
I may try to look at the paper, but it may take me a while to get to it.
-- John
On Wednesday, November 13, 2019 at 4:48:18 PM UTC-8, Salvatore
Dear All,
I was looking into computing homology of a certain chain complex when I came
across this paper arXiv:1903.00783v1. Apparently he claims that he has an
algorithm to do so that is much faster than the one we currently have in
sage. Did I understand correctly the claim? If so, would it
I just set SAGE_CHECK=yes and tried to build Sage on several platforms: OS
X and a virtual machine running Ubuntu. Summary:
Failed on both:
- gap: looks like some sort of string-vs-bytes problem
(https://trac.sagemath.org/ticket/28728)
- cvxopt: fails with a Python 3 build, hangs (at least on
Its hard to make the installation foolproof and it is maybe not worth it if
I am the only one, but I would vote yes for this change. Or maybe a
warning on certain linux versions? I spent a day ensuring that it wasn't
something that I could figure out myself before I posted my question here.
On Wed, Nov 13, 2019 at 4:46 PM Mike Zabrocki wrote:
>
> The suppression of the system zlib and bzip2 worked and it compiled.
Thanks, and sorry it took so many iterations.
But it is also insane on CentOS side to provide very old zlib and
bzip2 - mind you, bzip2
version 1.0.6, the one required
The suppression of the system zlib and bzip2 worked and it compiled.
Thanks.
-Mike
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Dear Dima,
I'm trying to offer a tool for "engineering" problems, similar to (and
along the lines of) our taylor() and series() functions for symbolic
expressions. Therefore, few assumptions can be made. Accordingly, we can
accept some failures (as we accept failures of taylor() or series() as
On Wed, 13 Nov 2019, 15:26 Mike Zabrocki, wrote:
> Hmmm. This is better because matplotlib is compiling, but R is not
> compiling because of an old version of bzip2.
>
> I'm trying:
> ./configure --without-system-bzip2
>
you must also keep
--without-system-zlib
in ./configure options,
Hmmm. This is better because matplotlib is compiling, but R is not
compiling because of an old version of bzip2.
I'm trying:
./configure --without-system-bzip2
and then make.
-Mike
On Tuesday, 12 November 2019 22:35:57 UTC-5, Mike Zabrocki wrote:
>
> Hi Dima,
>
> It didn't fix the problem,
In the multivariate case a lot depends on input.
E.g., do you know something about zeros of your function?
E.g. do you have derivatives easily available?
If derivates are hard, you probably would like to avoid them all together,
using something known as Newton-Pade
approximation:
For the univariate case, to compare speed etc., you could also call FriCAS
and do something like
sage: fricas.pade(3,2, fricas.taylor(atan(x), x=0)).sage()
(4/9*x^3 + 5/3*x)/(x^2 + 5/3)
In fact, there is also Hermite-Padé in FriCAS, but I cannot remember the
details.
--
You received this
Le mardi 12 novembre 2019 20:42:16 UTC+1, rjf a écrit :
>
> Since Maxima is free and open source and gpl, why not just read the
> algorithm implemented there
> and rewrite it in Python?
>
That can be done. But I had other interest in mind:
- multivariate case (my solution of iterative
12 matches
Mail list logo
