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
21 matches
Mail list logo
