Oh, sorry. I did get confused. I didn't see you had "SDMP-Core2"
written in your benchmark table. I hadn't realised you were quoting
sdmp times.
Bill.
On 14 May, 21:19, Francesco Biscani wrote:
> Hi Bill,
>
> On Fri, May 14, 2010 at 3:28 PM, Bill Hart
> wrote:
> > If I make a couple of simplif
Actually I wasn't allocating them in slabs. I had my threadsafe
version of the flint integer format turned on. The other version
allocates mpz's in slabs, but was broken. So.
having now fixed that. I do get the time down to about 2.1s on
sage.math. However, that's not noticeably faster th
Hi folks,
This rc comes out earlier than expected, mainly because the issues
reported with Sage 4.4.2.alpha0 were promptly resolved. Thanks to
Wilfried Huss and Georg S. Weber. This rc built and pass all doctests
on sage.math, bsd.math, rosemary.math, and the Linux machines on
Skynet. Note that Sa
2010/5/14 François Bissey :
> We had a long standing problem in both Gentoo and Mandriva
> with the following test
> sage -t -force_lib "devel/sage/sage/combinat/iet/strata.py"
> which is failing for us using the system python shipped with our
> distributions.
> As it turns out it is because the py
Hello everybody !!
I ran into an interesting graph construction, which happened to be...
easy as soon as one knew how to build a sum-free set ( a sum-free set
is a subset S of [1..n] such that no a,b in S are such that (a+b) \in
S ).
The problem being to find, given a integer n, a largest sum-fre
> The point is to avoid the python overhead in calling the add/delete
> functions. So yes, you would need to write your calls to the cython
> add/delete functions in Cython.
A simple example in the notebook:
%cython
from sage.graphs.base.c_graph cimport CGraph
from sage.all import graphs
G = gra
On 5/14/10 2:31 PM, Ryan Hinton wrote:
On May 14, 1:54 pm, Jason Grout wrote:
Are you adding/deleting things using the python functions, or are you
using the Cython interface to the underlying CGraph structure? If you
are using python, you can probably speed up these operations by 100x or so.
On 05/14/10 03:01 PM, Harald Schilly wrote:
I found a table by NIST comparing sage with other software packages.
It's probably interesting for what they are looking for and I think
some entries are missing (feedback link at the bottom). Maybe worth
checking this out for the future of sage develop
Hi Bill,
On Fri, May 14, 2010 at 3:28 PM, Bill Hart wrote:
> If I make a couple of simplifications, namely assume that the output
> fits into two limbs, and that none of the polynomials has length >
> 2^32 - 1, etc, I get pretty good times, certainly better than reported
> in Francesco's paper. I
On May 14, 9:54 am, Bill Hart wrote:
> On the other hand, I am unable to replicate the very sparse benchmark
> unless I assume the result will fit in 2 limbs and allocate all the
> output mpz's in advance, etc. Then I can basically replicate it. If I
> use my generic no assumptions code it takes a
On May 14, 1:54 pm, Jason Grout wrote:
> Are you adding/deleting things using the python functions, or are you
> using the Cython interface to the underlying CGraph structure? If you
> are using python, you can probably speed up these operations by 100x or so.
My code is straight Python. To us
Quick reply inline below.
On May 12, 6:06 pm, Nathann Cohen wrote:
> > These discuss (among other things) various approaches to the extra
> > constraints of the BipartiteGraph class. In particular, we agreed
> > that add_edge() can raise an exception in cases like this where an
> > algorithm vi
Just in case, because I do not know enough the C backends to give you
a useful answer (watch out for Robert Miller !) :
Did you try to specify to use a Dense backend, if your graph is not
too large ?
Nathann
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe f
Would the following be what you want?
sage: R1. = Zp(5,prec=20)[]
sage: R2 = Qp(5,prec=40)
sage: R2(1)+a
(1 + O(5^20))*a + (1 + O(5^40))
This results when one changes the merge method (and makes fraction
field functor and completion functor commute).
Cheers,
Simon
--
To post to this group, sen
On 5/14/10 9:32 AM, Fredrik Johansson wrote:
On Fri, May 14, 2010 at 4:01 PM, Harald Schilly
mailto:harald.schi...@gmail.com>> wrote:
I found a table by NIST comparing sage with other software packages.
It's probably interesting for what they are looking for and I think
some entries
On 14 Mai, 19:02, kcrisman wrote:
> It does seem a little out of date. A lot of those functions are
> included either via Maxima, mpmath, or Pynac (and probably also Pari,
> GSL, etc.) For instance, I believe we now have the psi functions.
Yes. According to that list, the functions of Sage form
Hi Robert!
On 14 Mai, 18:34, Robert Bradshaw
wrote:
> > 1. Do you agree this is a bug?
>
> The p-adic fields are of capped precision, not set precision, but each
> element remembers its own actual precision, so this is why the
> coercion goes in that direction, and I don't think its a bug.
W
On 5/14/10 12:48 PM, Ryan Hinton wrote:
I am running some Monte Carlo simulations where I construct and pull
apart graphs. If I can get them to run faster, I can get my results
faster or with higher precision/confidence.
I can give details if desired, but most of the processor time is spent
in
I am running some Monte Carlo simulations where I construct and pull
apart graphs. If I can get them to run faster, I can get my results
faster or with higher precision/confidence.
I can give details if desired, but most of the processor time is spent
in adding/deleting edges and vertices and ite
On May 14, 2010, at 7:01 AM, Harald Schilly wrote:
I found a table by NIST comparing sage with other software packages.
It's probably interesting for what they are looking for and I think
some entries are missing (feedback link at the bottom).
E.g. we compute zeta(s) for s complex, but not for
On May 14, 10:01 am, Harald Schilly wrote:
> I found a table by NIST comparing sage with other software packages.
> It's probably interesting for what they are looking for and I think
> some entries are missing (feedback link at the bottom). Maybe worth
> checking this out for the future of sage
On the other hand, I am unable to replicate the very sparse benchmark
unless I assume the result will fit in 2 limbs and allocate all the
output mpz's in advance, etc. Then I can basically replicate it. If I
use my generic no assumptions code it takes about 3s. I don't think I
can improve that much
On May 14, 2010, at 6:18 AM, Simon King wrote:
Hi!
I thought that when considering inexact fields (p-adic or real), a
coercion map should always be from higher precision to lower
precision.
For reals, this holds true:
sage: F1 = RealField(prec=20)
sage: F2 = RealField(prec=40)
sage: F1.has_
With a bit of fiddling I can get the Fateman benchmark down to 53.5s
on sage.math (2.66 GHz Core2/penryn) making no assumptions about the
size of the output coefficients. I've checked that at least the output
poly has the right length and coeffs of the right size.
Adjusting for the clock speed, th
On May 14, 4:32 pm, Fredrik Johansson
wrote:
> It would be nice to have something like this for Sage (including information
> about which library implements what, how generally etc), and not just for
> special functions.
Yeahr, exactly. A good start is the "constructions" manual (maybe
should be
On Fri, May 14, 2010 at 4:01 PM, Harald Schilly wrote:
> I found a table by NIST comparing sage with other software packages.
> It's probably interesting for what they are looking for and I think
> some entries are missing (feedback link at the bottom). Maybe worth
> checking this out for the futu
I found a table by NIST comparing sage with other software packages.
It's probably interesting for what they are looking for and I think
some entries are missing (feedback link at the bottom). Maybe worth
checking this out for the future of sage development or building our
own table like that?
tab
Thanks all for the very interesting comments and links to publications
and CAS's.
I've implemented the algorithm using flint2's fmpz (multiprecision)
integer type for coefficients and at this stage for 62 bit integers
for exponents, only. (However it should be trivial to lift this
restriction.)
I
Hi!
I thought that when considering inexact fields (p-adic or real), a
coercion map should always be from higher precision to lower
precision.
For reals, this holds true:
sage: F1 = RealField(prec=20)
sage: F2 = RealField(prec=40)
sage: F1.has_coerce_map_from(F2)
True
sage: F2.has_coerc
Hi,
On Fri, May 14, 2010 at 7:04 PM, François Bissey wrote:
> Hi,
>
> While sorting dependencies for sage on gentoo we discovered that
> zope-testbrowser is included in sagenb but we cannot find it being
> used or called anywhere in sage (not just the notebook).
> Are we missing something or shou
We had a long standing problem in both Gentoo and Mandriva
with the following test
sage -t -force_lib "devel/sage/sage/combinat/iet/strata.py"
which is failing for us using the system python shipped with our
distributions.
As it turns out it is because the python shipped in our system includes
the
Hi,
While sorting dependencies for sage on gentoo we discovered that
zope-testbrowser is included in sagenb but we cannot find it being
used or called anywhere in sage (not just the notebook).
Are we missing something or should it be removed.
Francois
--
To post to this group, send an email to
On 14 mei, 09:58, jvkersch wrote:
> Meanwhile, I will also collect
> the resources that people have posted in this thread, on a Wiki page
> or so.
See http://wiki.sagemath.org/tensorcalc
Thanks for all the interesting pointers!
All the best,
Joris
--
To post to this group, send an email to
Hi Martin,
On 13 mei, 12:52, Martin Rubey
wrote:
> Waldek just pointed me to a package by Seiler:
>
> http://axiom-wiki.newsynthesis.org/JetBundles
This looks like an interesting package. While I was doing my PhD
thesis I read many of W. Seiler's papers, and I was always intruiged
by the compu
> By the way, there is now a package for the chromium browser, and it runs
> sage nicely, including jmol applets.
Correction: editing text blocks has some glitches.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel
I think my previous reply to this message got eaten, so I'm sending it
again.
On 11 mei, 23:32, William Stein wrote:
> > (...) should
> > I start with a module over the Symbolic Ring, or is another ring more
> > appropriate?
>
> Have you got anywhere reading the Sage developers guide?
>
> http://
36 matches
Mail list logo
