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 interac
On Sep 18, 7:10 pm, Thierry Dumont 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. Above it was sugge
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 the
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 t
On Sep 9, 9:17 pm, Robert Bradshaw
wrote:
> On Thu, Sep 9, 2010 at 11:44 AM, KvS wrote:
> > On Sep 9, 5:27 pm, Robert Bradshaw
> > wrote:
> >> On Wed, Sep 8, 2010 at 6:39 PM, KvS wrote:
> >> > Thanks all, however I am not very successful so far :(.
>
> >> > I tried both options mentioned before
On Thu, Sep 9, 2010 at 11:44 AM, KvS wrote:
> On Sep 9, 5:27 pm, Robert Bradshaw
> wrote:
>> On Wed, Sep 8, 2010 at 6: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
On Sep 9, 5:27 pm, Robert Bradshaw
wrote:
> On Wed, Sep 8, 2010 at 6: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
On Sep 9, 5:27 pm, Robert Bradshaw
wrote:
> On Wed, Sep 8, 2010 at 6: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
On Thu, Sep 9, 2010 at 9:46 AM, Jason Grout 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 standard find_root
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 Wed, Sep 8, 2010 at 6: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;
What do you me
On Thu, Sep 9, 2010 at 2:02 AM, maldun wrote:
> On Sep 8, 6:19 pm, KvS 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 ge
On Sep 8, 6:19 pm, KvS 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 ways to speed it
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 t
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
i
On Wed, Sep 8, 2010 at 3:03 PM, Greg Marks 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 something like
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
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
sage
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 Grout 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
On 9/8/10 2:15 PM, Simon King wrote:
Hi Jason!
On 8 Sep., 20:57, Jason Grout 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"? Th
Hi Jason!
On 8 Sep., 20:57, Jason Grout 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.
Cheers,
Simon
--
On 9/8/10 1:46 PM, Simon King wrote:
Hi Kees!
On 8 Sep., 18:19, KvS 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 afraid that doubles won't h
Hi Kees!
On 8 Sep., 18:19, KvS 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 afraid that doubles won't have enough precision to avoid
On Dec 23, 1:53 am, 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
>
>
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
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 :
>
> Hi,
>
> as a followup on the "Arbitrary precision in cython" thread, I'd like to
> mention that one can directly use mpfr's implementation
On Mon, Dec 22, 2008 at 3:37 PM, John Cremona wrote:
>
> 2008/12/22 William Stein :
>>
>> On Mon, Dec 22, 2008 at 1:51 PM, M. Yurko wrote:
>>>
>>> First, about my issues with PARI's precision. I just tested the
>>> following:
>>> -pari(-10).eint1().n(150)
>>> and got 2492.22897624187775411641609
2008/12/22 William Stein :
>
> On Mon, Dec 22, 2008 at 1:51 PM, M. Yurko 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 the 14th decimal p
On Mon, Dec 22, 2008 at 1:51 PM, M. Yurko 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 the 14th decimal place. As Stein said, Its quite
> like
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
On Dec 22, 2008, at 8:28 AM, M. Yurko wrote:
> When I timed these functions over 1 through 700 at 53 bits of
> precision, the python one took 5.46 sec., the double precision cython
> one took only .02 sec., and the arbitrary precision one took 6.77 sec.
> After looking at the .c file that cython
2008/12/22 William Stein :
>
> On Mon, Dec 22, 2008 at 9:57 AM, John Cremona wrote:
>>
>> 2008/12/22 M. Yurko :
>>>
>>> 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 accu
On Mon, Dec 22, 2008 at 9:57 AM, John Cremona wrote:
>
> 2008/12/22 M. Yurko :
>>
>> 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 di
2008/12/22 M. Yurko :
>
> 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 to compare a
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 to compare a
few a acceleration ideas for the
On Mon, Dec 22, 2008 at 8:40 AM, John Cremona 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 exponential integral t
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 :
>
> Alright, below is the original python implementation of the function:
>
> def python(x,bits):
>i = 1
>sum_c
Alright, below is the original python implementation of the function:
def python(x,bits):
i = 1
sum_current = RealNumber(x,min_prec=bits)
sum_last = 0
term = sum_current
add_term = (ln(x)+euler_gamma).n(bits)
while sum_current != sum_last:
i+=1
term = term*
Hello,
On Mon, Dec 22, 2008 at 6:10 AM, M. Yurko 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 directly.
Well, I
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 directly.
On Dec 22, 1:44 am, "William Stein" wrote:
> On Sun, Dec 21, 2008 at 1:44
On Sun, Dec 21, 2008 at 1:44 PM, M. Yurko 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 that is mil
41 matches
Mail list logo
