On 9/19/10 7:09 AM, KvS wrote:
Alright, many thanks for the clear and extensive answer Thierry.
Bottomline is thus that I'll have to live with it.
On a sidenote, I must admit it surprises me. I'm only an amateur
programmer, let alone that I know anything about the subtleties of how
cpus
On Sep 18, 7:10 pm, Thierry Dumont tdum...@math.univ-lyon1.fr wrote:
Le 18/09/2010 16:31, KvS a �crit :
Hi again,
I hope you don't mind me bumping this thread one more time. I started
experimenting with trying a few things for fast arbitrary precision
computations using Cython.
Hi again,
I hope you don't mind me bumping this thread one more time. I started
experimenting with trying a few things for fast arbitrary precision
computations using Cython. Above it was suggested to use MPFR
directly, so without the RealNumber wrapper, as the fastest way. Here
is a bit of code
Le 18/09/2010 16:31, KvS a écrit :
Hi again,
I hope you don't mind me bumping this thread one more time. I started
experimenting with trying a few things for fast arbitrary precision
computations using Cython. Above it was suggested to use MPFR
directly, so without the RealNumber wrapper, as
On Sep 8, 6:19 pm, KvS keesvansch...@gmail.com wrote:
Dear all,
I am trying to implement a recursive algorithm that is rather complex,
in the sense that it uses a high number of variables and (elementary)
computations. The output in Sage looks fine but it gets quite slow, so
I am thinking of
On Wed, Sep 8, 2010 at 6:39 PM, KvS keesvansch...@gmail.com wrote:
Thanks all, however I am not very successful so far :(.
I tried both options mentioned before:
- only optimize the loops in Cython and keep using symbolic
expressions/infinite precision, but this is unfortunately rather
On 9/9/10 11:27 AM, Robert Bradshaw wrote:
This should be much faster than symbolic (if I
understand you right, calling find_root and integrate) but have higher
precision than using raw doubles.
I believe the standard find_root uses scipy, which is limited to double
precision.
Jason
--
To
On Thu, Sep 9, 2010 at 9:46 AM, Jason Grout jason-s...@creativetrax.com wrote:
On 9/9/10 11:27 AM, Robert Bradshaw wrote:
This should be much faster than symbolic (if I
understand you right, calling find_root and integrate) but have higher
precision than using raw doubles.
I believe the
On Sep 9, 5:27 pm, Robert Bradshaw rober...@math.washington.edu
wrote:
On Wed, Sep 8, 2010 at 6:39 PM, KvS keesvansch...@gmail.com wrote:
Thanks all, however I am not very successful so far :(.
I tried both options mentioned before:
- only optimize the loops in Cython and keep using
On Sep 9, 5:27 pm, Robert Bradshaw rober...@math.washington.edu
wrote:
On Wed, Sep 8, 2010 at 6:39 PM, KvS keesvansch...@gmail.com wrote:
Thanks all, however I am not very successful so far :(.
I tried both options mentioned before:
- only optimize the loops in Cython and keep using
On Thu, Sep 9, 2010 at 11:44 AM, KvS keesvansch...@gmail.com wrote:
On Sep 9, 5:27 pm, Robert Bradshaw rober...@math.washington.edu
wrote:
On Wed, Sep 8, 2010 at 6:39 PM, KvS keesvansch...@gmail.com wrote:
Thanks all, however I am not very successful so far :(.
I tried both options
On Sep 9, 9:17 pm, Robert Bradshaw rober...@math.washington.edu
wrote:
On Thu, Sep 9, 2010 at 11:44 AM, KvS keesvansch...@gmail.com wrote:
On Sep 9, 5:27 pm, Robert Bradshaw rober...@math.washington.edu
wrote:
On Wed, Sep 8, 2010 at 6:39 PM, KvS keesvansch...@gmail.com wrote:
Thanks all,
On 9/8/10 1:46 PM, Simon King wrote:
Hi Kees!
On 8 Sep., 18:19, KvSkeesvansch...@gmail.com wrote:
...
I am thinking of ways to speed it up. Given that it is mainly a lot of
looping and a lot of elementary computations, I would guess
translating it to Cython could help a lot.
However I am
Hi Jason!
On 8 Sep., 20:57, Jason Grout jason-s...@creativetrax.com wrote:
Actually, for a while now, for i in range(...) is translated into fast
C intelligently. In fact, I believe it's the recommended syntax now,
instead of 0=i...
Even if you do *not* cdefine cdef int i? That's new to me.
On 9/8/10 2:15 PM, Simon King wrote:
Hi Jason!
On 8 Sep., 20:57, Jason Groutjason-s...@creativetrax.com wrote:
Actually, for a while now, for i in range(...) is translated into fast
C intelligently. In fact, I believe it's the recommended syntax now,
instead of 0=i...
Even if you do *not*
On 9/8/10 2:22 PM, Jason Grout wrote:
On 9/8/10 2:15 PM, Simon King wrote:
Hi Jason!
On 8 Sep., 20:57, Jason Groutjason-s...@creativetrax.com wrote:
Actually, for a while now, for i in range(...) is translated into fast
C intelligently. In fact, I believe it's the recommended syntax now,
Thanks a lot for the hints so far, I will go and try them out. I'd
still also be very interested if somebody could shed some more light
on my original questions!
Thanks, Kees
--
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to
It sounds like a C program using MPFR (http://www.mpfr.org)
would do what you want. As MPFR is built into SAGE, you might
perhaps find it more convenient to invoke MPFR within SAGE.
Sincerely,
Greg Marks
| Greg Marks
On Wed, Sep 8, 2010 at 3:03 PM, Greg Marks gtma...@gmail.com wrote:
It sounds like a C program using MPFR (http://www.mpfr.org)
would do what you want. As MPFR is built into SAGE, you might
perhaps find it more convenient to invoke MPFR within SAGE.
This is what I would recommend. You can do
Thanks all, however I am not very successful so far :(.
I tried both options mentioned before:
- only optimize the loops in Cython and keep using symbolic
expressions/infinite precision, but this is unfortunately rather
slow;
- fully optimize in Cython by turning to doubles everywhere, although
On 9/8/10 8:39 PM, KvS wrote:
Thanks all, however I am not very successful so far :(.
I tried both options mentioned before:
- only optimize the loops in Cython and keep using symbolic
expressions/infinite precision, but this is unfortunately rather
slow;
- fully optimize in Cython by turning
Thanks Paul, that is very helpful; it means that all the discussion
of conversion to and from pari is redundant.
John
2008/12/23 Paul Zimmermann paul.zimmerm...@loria.fr:
Hi,
as a followup on the Arbitrary precision in cython thread, I'd like to
mention that one can directly use
Paul Zimmermann wrote:
Hi,
as a followup on the Arbitrary precision in cython thread, I'd like to
mention that one can directly use mpfr's implementation from within Sage:
sage: RealField(150)(10).eint()
2492.2289762418777591384401439985248489896471
It only works for real
Hello,
On Mon, Dec 22, 2008 at 6:10 AM, M. Yurko myu...@gmail.com wrote:
Thanks for your help. I tried your first and last suggestions, but
they yielded code that was slower than the original python
implementation. However, I'll take a look at sage.rings.real_mpfr and
try to use mpfr
That looks very like the exponential integral you are computing. If
so, you can use Sage's function Ei() which calls scipy's
special.exp1().
John Cremona
2008/12/22 M. Yurko myu...@gmail.com:
Alright, below is the original python implementation of the function:
def python(x,bits):
i =
On Mon, Dec 22, 2008 at 8:40 AM, John Cremona john.crem...@gmail.com wrote:
That looks very like the exponential integral you are computing. If
so, you can use Sage's function Ei() which calls scipy's
special.exp1().
Watch out, since scipy is double precision only.
Pari has a real-only
2008/12/22 M. Yurko myu...@gmail.com:
It is the exponential integral, but I want greater than double
precision. I tried PARI, and it reports the number in arbitrary
precision, but it is only seems to be accurate to double precision as
all digits after are completely wrong. Also, I'm trying
On Mon, Dec 22, 2008 at 9:57 AM, John Cremona john.crem...@gmail.com wrote:
2008/12/22 M. Yurko myu...@gmail.com:
It is the exponential integral, but I want greater than double
precision. I tried PARI, and it reports the number in arbitrary
precision, but it is only seems to be accurate to
2008/12/22 William Stein wst...@gmail.com:
On Mon, Dec 22, 2008 at 9:57 AM, John Cremona john.crem...@gmail.com wrote:
2008/12/22 M. Yurko myu...@gmail.com:
It is the exponential integral, but I want greater than double
precision. I tried PARI, and it reports the number in arbitrary
First, about my issues with PARI's precision. I just tested the
following:
-pari(-10).eint1().n(150)
and got 2492.2289762418777541164160993503173813223839 which is
inaccurate after the 14th decimal place. As Stein said, Its quite
likely that I didn't call PARI correctly, as this is the first time
2008/12/22 William Stein wst...@gmail.com:
On Mon, Dec 22, 2008 at 1:51 PM, M. Yurko myu...@gmail.com wrote:
First, about my issues with PARI's precision. I just tested the
following:
-pari(-10).eint1().n(150)
and got 2492.2289762418777541164160993503173813223839 which is
inaccurate after
On Mon, Dec 22, 2008 at 3:37 PM, John Cremona john.crem...@gmail.com wrote:
2008/12/22 William Stein wst...@gmail.com:
On Mon, Dec 22, 2008 at 1:51 PM, M. Yurko myu...@gmail.com wrote:
First, about my issues with PARI's precision. I just tested the
following:
-pari(-10).eint1().n(150)
On Sun, Dec 21, 2008 at 1:44 PM, M. Yurko myu...@gmail.com wrote:
I have recently been experimenting with converting some simple python
functions that I have made into cython. I have been quite impressed by
how simple it is for the massive speed increases that I have seen.
However, one thing
33 matches
Mail list logo
