Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On Thu, 13 Feb 2014, Jori Mantysalo wrote: Here is an example where mpfr-gamma and pari-gamma give different results: Duh, forget this one: pari-gamma gives Inf. -- Jori Mäntysalo -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
Here is an example where mpfr-gamma and pari-gamma give different results: x=1 for i in range(1,400): x=x*1.101 if gamma(ComplexField(prec=1000)(x))-gamma(x) <> 0: print x outputs 4.71129468628944e16 -- Jori Mäntysalo -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] arcsec(float(.1)) throws error
2014-02-13 0:38 UTC+01:00, William Stein : > On Wed, Feb 12, 2014 at 2:50 PM, Jason Grout > wrote: >> David Smith just pointed this out: arcsec(float(.1)) throws an error that >> doesn't make much sense. Yes, it's outside of the domain, but it should >> probably deal with this by returning NaN or something rather than a type >> error. This came up when David was trying to plot arcsec. >> >> On a related note, maybe we should have some sort of error that can be >> thrown for values outside of domains? Plot could catch an out-of-domain >> error and break the drawing there, so you wouldn't end up with something >> like http://sagecell.sagemath.org/?q=llweji >> > > What about ValueError? > >http://docs.python.org/2/library/exceptions.html#exceptions.ValueError > +1 On the other hand, it would be very nice and meaningful to have sage: arcsec.domain() (-infty; -1] u [1; +infty) That kind of information can then be used by call to plot. Vincent -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Numerical Methods in Sage
Hi there, As far as I know there is no arbitrary precision within scipy/numpy. On the other hand scipy/numpy is shipped with Sage and if you do for example sage: m = matrix(RDF, [[2,0],[1,0]]) the matrix m is (in the backend) a numpy matrix stored under m._numpy_matrix. Sadly you can not access this attribute because it is at C level (Cython). You may have a look at sage/matrix/matrix_double_dense.pyx The first thing to do would be to do the list of existing softwares and libraries for numerical things (knowing that ATLAS, numpy/scipy are already there) and start implementing interfaces. As far as I know, there is one nice numerical thing in Sage : root finding of polynomials. The code is in sage/rings/polynomials/real_roots.pyx and sage/rings/polynomial/complex_roots.pyx Best, Vincent 2014-02-13 2:31 UTC+01:00, ref...@uncg.edu : > Oh, FEM brings me back to my master's days. Programming the FEM can > sometimes be painful. Perhaps I'm not the best one to ask about this, but > you can use implement in python using Numpy and Scipy...and then run it in > Sage. > > On Wednesday, February 12, 2014 6:52:37 PM UTC-5, Chris Gorman wrote: >> >> kcrisman and Rick, >> >> I guess that I am wondering if there is a group that is devoted to >> contributing to the numerical aspects of Sage and, if so, what they are >> focusing on. I know that I would be interested in helping implement is FEM >> >> and arbitrary-precision numerical integration. I would also like to work >> on >> the linear algebra, but I do not know whether it would be better to focus >> >> on numpy or scipy at that point. I guess I just want to help improve >> Sage's >> numerical capabilities. >> >> Chris >> >> >> >> On Wednesday, February 12, 2014 11:20:33 AM UTC-8, ref...@uncg.edu wrote: >>> >>> Chris, >>> >>> I'm not sure what you are looking for. But, I'm planning on submitting >>> some personal algorithms to sage. Sometimes I had to make some >>> improvements to built-in functions to suit my purpose. For example, >>> numerical integration built into sage is not arbitrary precision...which >>> I >>> had to make arbitrary for my algorithm because of the highly oscillatory >>> >>> nature of the function I was integrating. >>> >>> Rick >>> >>> On Wednesday, February 12, 2014 11:26:50 AM UTC-5, Chris Gorman wrote: Does anyone have know who is working on improving the numerical methods in Sage? I am beginning my graduate program in numerical analysis and would like to use Sage for my work and research. >>> > > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Coercion problem ?
Salut Aladin !
Words currently do not fit well with category... (for example they do
not inherit from parent). But there is #12224 that I hope to finish at
Sage days 57. By the way do you plan to come ?
For your problem, a stupid strategy of the conversion mechanism in
Sage from X to Y is to ask for X an element x (via an_element()) and
then try Y(x). It makes many things annoying ! On the other hand,
there is no real specifications for "x in X" and I guess that until we
fix it we should avoid it.
Best,
Vincent
2014-02-13 7:53 UTC+01:00, David Roe :
>> sage: W([1,2]) in ZZ
>> ---
>> NotImplementedError Traceback (most recent call
>> last)
>> in ()
>> > 1 W([Integer(1),Integer(2)]) in ZZ
>> [...]
>>
>> NotImplementedError: please implement _an_element_ for Words over {1, 2,
>> 3, 4}
>>
>> It is easy to fix by adding the _an_element_ method to W by doing:
>>
>> sage: W._an_element_ = lambda : W()
>> sage: W([1,2]) in ZZ
>> False
>>
>
> _an_element_ should return an element of W, rather than None. Other than
> that, I'm not sure whether W is deficient coercion-wise in any other way;
> should there be coercions from anywhere?
> David
>
> --
> 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 sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Coercion problem ?
> sage: W([1,2]) in ZZ
> ---
> NotImplementedError Traceback (most recent call last)
> in ()
> > 1 W([Integer(1),Integer(2)]) in ZZ
> [...]
>
> NotImplementedError: please implement _an_element_ for Words over {1, 2,
> 3, 4}
>
> It is easy to fix by adding the _an_element_ method to W by doing:
>
> sage: W._an_element_ = lambda : W()
> sage: W([1,2]) in ZZ
> False
>
_an_element_ should return an element of W, rather than None. Other than
that, I'm not sure whether W is deficient coercion-wise in any other way;
should there be coercions from anywhere?
David
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Unable to open account on Sage Trac Server
Onto it! On Thursday, February 13, 2014 9:43:04 AM UTC+5:30, kcrisman wrote: > > Dear Amit, > > Your email was received, but unfortunately there are not tons of people > creating accounts and it has not been responded to yet. Unfortunately, I > can't do it now either :-( but I hope someone will soon and do have time to > send a quick "bump" about it! > > Best, > - kcrisman > > On Wednesday, February 12, 2014 10:39:15 PM UTC-5, Amit Jamadagni wrote: >> >> Hello, >> >> Hello, >> I have setup sage and have gone through some of the issues. I have >> also gone through the Developer Guide ( >> http://www.sagemath.org/doc/developer/index.html) but there seems to be >> requirement of creating a account by sending in the details to the >> specified google group. But I still did not get any reply or notification >> regarding the same. Could you please provide some further information on >> this so that I can start working on the same. Thanks. >> >> Amit. >> > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Unable to open account on Sage Trac Server
Dear Amit, Your email was received, but unfortunately there are not tons of people creating accounts and it has not been responded to yet. Unfortunately, I can't do it now either :-( but I hope someone will soon and do have time to send a quick "bump" about it! Best, - kcrisman On Wednesday, February 12, 2014 10:39:15 PM UTC-5, Amit Jamadagni wrote: > > Hello, > > Hello, > I have setup sage and have gone through some of the issues. I have > also gone through the Developer Guide ( > http://www.sagemath.org/doc/developer/index.html) but there seems to be > requirement of creating a account by sending in the details to the > specified google group. But I still did not get any reply or notification > regarding the same. Could you please provide some further information on > this so that I can start working on the same. Thanks. > > Amit. > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Unable to open account on Sage Trac Server
Hello, Hello, I have setup sage and have gone through some of the issues. I have also gone through the Developer Guide ( http://www.sagemath.org/doc/developer/index.html) but there seems to be requirement of creating a account by sending in the details to the specified google group. But I still did not get any reply or notification regarding the same. Could you please provide some further information on this so that I can start working on the same. Thanks. Amit. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: trac update
On Tue, Feb 11, 2014 at 4:28 PM, Travis Scrimshaw wrote: > Hey Andrew, >I inputed the wrong branch on http://trac.sagemath.org/ticket/15668and > then trac would not load the page. I worked around this by uploading a > branch with the typo, but the issue with trac is still there. > Ok, this should now be fixed: https://github.com/sagemath/sage_trac_plugin/commit/63512d425dc75734e1e171c53a8e6dab66a48859 . -- Andrew -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Coercion problem ?
Hello everyone,
here is a bug that is maybe related to coercion system to Integers in sage:
sage: W = Words(4)
sage: W([1,2])
word: 12
sage: W([1,2]) in QQ
False
sage: W([1,2]) in ZZ
---
NotImplementedError Traceback (most recent call last)
in ()
> 1 W([Integer(1),Integer(2)]) in ZZ
[...]
NotImplementedError: please implement _an_element_ for Words over {1, 2, 3,
4}
It is easy to fix by adding the _an_element_ method to W by doing:
sage: W._an_element_ = lambda : W()
sage: W([1,2]) in ZZ
False
but maybe is it hiding a more tricky problem behind ?
Aladin
PS: this post is in the continuity of a topic I originally opened on
sage-support:
https://groups.google.com/forum/#!topic/sage-support/uvKWkq7wDVM
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Numerical Methods in Sage
Oh, FEM brings me back to my master's days. Programming the FEM can sometimes be painful. Perhaps I'm not the best one to ask about this, but you can use implement in python using Numpy and Scipy...and then run it in Sage. On Wednesday, February 12, 2014 6:52:37 PM UTC-5, Chris Gorman wrote: > > kcrisman and Rick, > > I guess that I am wondering if there is a group that is devoted to > contributing to the numerical aspects of Sage and, if so, what they are > focusing on. I know that I would be interested in helping implement is FEM > and arbitrary-precision numerical integration. I would also like to work on > the linear algebra, but I do not know whether it would be better to focus > on numpy or scipy at that point. I guess I just want to help improve Sage's > numerical capabilities. > > Chris > > > > On Wednesday, February 12, 2014 11:20:33 AM UTC-8, ref...@uncg.edu wrote: >> >> Chris, >> >> I'm not sure what you are looking for. But, I'm planning on submitting >> some personal algorithms to sage. Sometimes I had to make some >> improvements to built-in functions to suit my purpose. For example, >> numerical integration built into sage is not arbitrary precision...which I >> had to make arbitrary for my algorithm because of the highly oscillatory >> nature of the function I was integrating. >> >> Rick >> >> On Wednesday, February 12, 2014 11:26:50 AM UTC-5, Chris Gorman wrote: >>> >>> Does anyone have know who is working on improving the numerical methods >>> in Sage? I am beginning my graduate program in numerical analysis and would >>> like to use Sage for my work and research. >>> >> -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Numerical Methods in Sage
kcrisman and Rick, I guess that I am wondering if there is a group that is devoted to contributing to the numerical aspects of Sage and, if so, what they are focusing on. I know that I would be interested in helping implement is FEM and arbitrary-precision numerical integration. I would also like to work on the linear algebra, but I do not know whether it would be better to focus on numpy or scipy at that point. I guess I just want to help improve Sage's numerical capabilities. Chris On Wednesday, February 12, 2014 11:20:33 AM UTC-8, ref...@uncg.edu wrote: > > Chris, > > I'm not sure what you are looking for. But, I'm planning on submitting > some personal algorithms to sage. Sometimes I had to make some > improvements to built-in functions to suit my purpose. For example, > numerical integration built into sage is not arbitrary precision...which I > had to make arbitrary for my algorithm because of the highly oscillatory > nature of the function I was integrating. > > Rick > > On Wednesday, February 12, 2014 11:26:50 AM UTC-5, Chris Gorman wrote: >> >> Does anyone have know who is working on improving the numerical methods >> in Sage? I am beginning my graduate program in numerical analysis and would >> like to use Sage for my work and research. >> > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] arcsec(float(.1)) throws error
On Wed, Feb 12, 2014 at 2:50 PM, Jason Grout wrote: > David Smith just pointed this out: arcsec(float(.1)) throws an error that > doesn't make much sense. Yes, it's outside of the domain, but it should > probably deal with this by returning NaN or something rather than a type > error. This came up when David was trying to plot arcsec. > > On a related note, maybe we should have some sort of error that can be > thrown for values outside of domains? Plot could catch an out-of-domain > error and break the drawing there, so you wouldn't end up with something > like http://sagecell.sagemath.org/?q=llweji > What about ValueError? http://docs.python.org/2/library/exceptions.html#exceptions.ValueError > Thanks, > > Jason > > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] arcsec(float(.1)) throws error
David Smith just pointed this out: arcsec(float(.1)) throws an error that doesn't make much sense. Yes, it's outside of the domain, but it should probably deal with this by returning NaN or something rather than a type error. This came up when David was trying to plot arcsec. On a related note, maybe we should have some sort of error that can be thrown for values outside of domains? Plot could catch an out-of-domain error and break the drawing there, so you wouldn't end up with something like http://sagecell.sagemath.org/?q=llweji Thanks, Jason -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On Wed, Feb 12, 2014 at 9:20 PM, Zimmermann Paul wrote: >Dear Jori, > >> And reason is of course clear, as Fredrik Johansson wrote "If you cache >> Bernoulli numbers, - -". > > in fact there is another reason: the MPFR code computes the Bernoulli numbers > exactly, as integers B(2n)*(2n+1)!, whereas Pari/GP computes a floating-point > approximation. For 1000-bit precision with input pi^2, and the parameters of > Pari/GP, this requires computing Bernoulli numbers of 3800 bits. > > We should compute floating-point approximations of the Bernoulli numbers in > MPFR too, but this will require redoing the error analysis, which is non > trivial. You could also compute Bernoulli numbers exactly, but use a fast numerical algorithm for this. Arb computes and stores Bernoulli numbers exactly, and evaluating Gamma(x) the first time (which includes the time to generate Bernoulli numbers) is about as fast time as evaluating it repeatedly in Pari (i.e. with Bernoulli numbers cached). Fredrik -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On 2014-02-12 19:36, ref...@uncg.edu wrote: Thank you for responses. It seems that the best solution would be to use pari in the way that Dr. Stein said earlier. MPFR does have one important advantage: it has a *guaranteed* error bound. With PARI, you never really know how precise the answer is. So in principle, I would prefer MPFR for this reason. Or should you discuss it first here and then submit a ticket? I guess both are ok. Posting to sage-devel does give the question much more visibility. And it this case, it pointed out a good general question (which library do we prefer to compute special functions and which criteria matter?) On the other hand, for simple small bugs, directly posting to Trac might be better. Jeroen. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
Dear Jori, > And reason is of course clear, as Fredrik Johansson wrote "If you cache > Bernoulli numbers, - -". in fact there is another reason: the MPFR code computes the Bernoulli numbers exactly, as integers B(2n)*(2n+1)!, whereas Pari/GP computes a floating-point approximation. For 1000-bit precision with input pi^2, and the parameters of Pari/GP, this requires computing Bernoulli numbers of 3800 bits. We should compute floating-point approximations of the Bernoulli numbers in MPFR too, but this will require redoing the error analysis, which is non trivial. Paul -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On Wed, Feb 12, 2014 at 12:12 PM, Jori Mantysalo wrote: > On Wed, 12 Feb 2014, William Stein wrote: > >> 1. It is *NOT* true.Sage just directly calls the PARI C library, >> which is always loaded on startup of Sage. > > > OK, good (or bad, which way one wants it to be...). > > >> It's pretty likely that when the line of code in question was written >> (prob in 2005 or 2006) this speed difference wasn't the case. > > > Maybe somebody has just tested this once for given precision? This used > about 1,5 seconds CPU time every time: > > gamma(RealField(prec=1)(3.14159)) > > And this one only about 0,1 seconds, except that for first time it took 10,7 > seconds: > > gamma(ComplexField(prec=1)(3.14159)) > > And reason is of course clear, as Fredrik Johansson wrote "If you cache > Bernoulli numbers, - -". You have just made a very, very good point. -- William > > > -- > Jori Mäntysalo > > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On Wed, 12 Feb 2014, William Stein wrote: 1. It is *NOT* true.Sage just directly calls the PARI C library, which is always loaded on startup of Sage. OK, good (or bad, which way one wants it to be...). It's pretty likely that when the line of code in question was written (prob in 2005 or 2006) this speed difference wasn't the case. Maybe somebody has just tested this once for given precision? This used about 1,5 seconds CPU time every time: gamma(RealField(prec=1)(3.14159)) And this one only about 0,1 seconds, except that for first time it took 10,7 seconds: gamma(ComplexField(prec=1)(3.14159)) And reason is of course clear, as Fredrik Johansson wrote "If you cache Bernoulli numbers, - -". -- Jori Mäntysalo -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Numerical Methods in Sage
Chris, I'm not sure what you are looking for. But, I'm planning on submitting some personal algorithms to sage. Sometimes I had to make some improvements to built-in functions to suit my purpose. For example, numerical integration built into sage is not arbitrary precision...which I had to make arbitrary for my algorithm because of the highly oscillatory nature of the function I was integrating. Rick On Wednesday, February 12, 2014 11:26:50 AM UTC-5, Chris Gorman wrote: > > Does anyone have know who is working on improving the numerical methods in > Sage? I am beginning my graduate program in numerical analysis and would > like to use Sage for my work and research. > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Numerical Methods in Sage
And welcome to Sage! On Wednesday, February 12, 2014 2:09:23 PM UTC-5, kcrisman wrote: > > Does anyone have know who is working on improving the numerical methods in >> Sage? I am beginning my graduate program in numerical analysis and would >> like to use Sage for my work and research. >> > > Can you be more specific? There has been a lot of work getting Sage to > use mpmath for evaluating special functions, for example, and GSL numerical > integration is available, and some folks have done work related to Sage > with FEM... so it would really depend on what you need. > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Numerical Methods in Sage
> > Does anyone have know who is working on improving the numerical methods in > Sage? I am beginning my graduate program in numerical analysis and would > like to use Sage for my work and research. > Can you be more specific? There has been a lot of work getting Sage to use mpmath for evaluating special functions, for example, and GSL numerical integration is available, and some folks have done work related to Sage with FEM... so it would really depend on what you need. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On Wed, Feb 12, 2014 at 7:20 PM, Zimmermann Paul wrote: >William, > > thank you for putting me in cc. > >> From: William Stein >> Date: Wed, 12 Feb 2014 06:01:29 -0800 >> >> On Wed, Feb 12, 2014 at 4:55 AM, wrote: >> > Ah, I see what you mean. If that's the case then I understand. How does >> > one find out if this is true? >> >> 1. It is *NOT* true.Sage just directly calls the PARI C library, >> which is always loaded on startup of Sage. >> >> 2. Thanks for clarifying your original question. It's surprising that >> MPFR is a full *order of magnitude* slower than PARI at computing >> gamma on real input.It's pretty likely that when the line of code >> in question was written (prob in 2005 or 2006) this speed difference >> wasn't the case. I've cc'd Paul Zimmerman (author of MPFR) in case he >> has any comments about this: >> >> a = RealField(1000)(pi^2) >> b = ComplexField(1000)(pi^2) >> >> %timeit a.gamma() # SLOW -- uses mpfr -- "mpfr_gamma(x.value, >> self.value, (self._parent).rnd)" >> %timeit b.gamma() # FAST -- uses pari -- >> "sage.libs.pari.all.pari.complex(self.real()._pari_(), >> self.imag()._pari_())" >> >> Maybe we should switch to PARI for this.At the least, you could add >> >>a.gamma(algorithm='pari') >> >> and at some point make that the default... >> >> -- William > > indeed mpfr_gamma is slow for input pi^2 at 1000 bits. I've investigated a bit > and with the following patch (with respect to the svn version of MPFR) I can > gain about 60%, i.e., the time decreases from about 2.9s on my computer to > about 1.8s for 1000 computations of gamma(pi^2) at 1000 bits. This is still > slower than Pari (which takes 506 us per loop). > > We could still save some time by caching the Bernoulli numbers (which take > 0.8s in the above 1.8s), but that would still be slower than Pari. Maybe the > algorithm used by Pari is better... Tuning of the Stirling series is discussed briefly in my paper http://arxiv.org/abs/1310.3741 If you cache Bernoulli numbers, it becomes much faster to use a smaller argument reduction z -> z+k. My code uses k ~= 0.27*p where p is the precision in bits. Fredrik -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: Issue With Implementation of Gamma Function
Thank you for responses. It seems that the best solution would be to use pari in the way that Dr. Stein said earlier. Again, I'm new to the development process and would like to contribute to sage. Should I submit a ticket and write my own patch and submit it now? I'm not sure how development should follow. Should I have submitted a ticket and not even posted this question in sage-devel? Or should you discuss it first here and then submit a ticket? Thanks, Rick On Tuesday, February 11, 2014 9:57:04 PM UTC-5, ref...@uncg.edu wrote: > > Dear All, > > I was developing an algorithm that depended on the calculation of the > gamma function. I noticed that the algorithm was surprisingly slow. Upon > investigation, I realized that the issue lies with the gamma function. To > illustrate: > > sage: RR = RealField(1000) > sage: CC = ComplexField(1000) > sage: %timeit RR(-3.52).gamma() > 100 loops, best of 3: 3.58 ms per loop > sage: %timeit CC(-3.52).gamma() > 1000 loops, best of 3: 538 us per loop > > This surprised me. I figured it was because of the high precision, but > the next example shows it isn't. > > sage: RR > Real Field with 53 bits of precision > sage: CC > Complex Field with 53 bits of precision > sage: %timeit RR(-3.52).gamma() > 1 loops, best of 3: 136 us per loop > sage: %timeit CC(-3.52).gamma() > 1 loops, best of 3: 77.9 us per loop > > After some investigation, the reason lies in the fact that version RR > version gamma uses mpfr directly to compute gamma. On the other hand, the > CC version of gamma uses pari to compute the gamma function. Is there a > reason for this that I'm not seeing? > > I'm new to development, so I'm not sure if I should have posted this > question here. Should I have submitted a ticket first? > > Thanks, > > Rick > > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
William,
thank you for putting me in cc.
> From: William Stein
> Date: Wed, 12 Feb 2014 06:01:29 -0800
>
> On Wed, Feb 12, 2014 at 4:55 AM, wrote:
> > Ah, I see what you mean. If that's the case then I understand. How does
> > one find out if this is true?
>
> 1. It is *NOT* true.Sage just directly calls the PARI C library,
> which is always loaded on startup of Sage.
>
> 2. Thanks for clarifying your original question. It's surprising that
> MPFR is a full *order of magnitude* slower than PARI at computing
> gamma on real input.It's pretty likely that when the line of code
> in question was written (prob in 2005 or 2006) this speed difference
> wasn't the case. I've cc'd Paul Zimmerman (author of MPFR) in case he
> has any comments about this:
>
> a = RealField(1000)(pi^2)
> b = ComplexField(1000)(pi^2)
>
> %timeit a.gamma() # SLOW -- uses mpfr -- "mpfr_gamma(x.value,
> self.value, (self._parent).rnd)"
> %timeit b.gamma() # FAST -- uses pari --
> "sage.libs.pari.all.pari.complex(self.real()._pari_(),
> self.imag()._pari_())"
>
> Maybe we should switch to PARI for this.At the least, you could add
>
>a.gamma(algorithm='pari')
>
> and at some point make that the default...
>
> -- William
indeed mpfr_gamma is slow for input pi^2 at 1000 bits. I've investigated a bit
and with the following patch (with respect to the svn version of MPFR) I can
gain about 60%, i.e., the time decreases from about 2.9s on my computer to
about 1.8s for 1000 computations of gamma(pi^2) at 1000 bits. This is still
slower than Pari (which takes 506 us per loop).
We could still save some time by caching the Bernoulli numbers (which take
0.8s in the above 1.8s), but that would still be slower than Pari. Maybe the
algorithm used by Pari is better...
Best regards,
Paul
tarte% svn diff src/lngamma.c src/gamma.c
Index: src/lngamma.c
===
--- src/lngamma.c (revision 8920)
+++ src/lngamma.c (working copy)
@@ -437,10 +437,13 @@
with respect to z0, and k = n, we get 1/(Pi*e)^(2n) ~ 2^(-w), i.e.,
k ~ w*log(2)/2/log(Pi*e) ~ 0.1616 * w.
However, since the series is more expensive to compute, the optimal
- value seems to be k ~ 4.5 * w experimentally. */
+ value seems to be k ~ 4.5 * w experimentally.
+ Note added February 12, 2014: for a target precision of 1000 bits,
+ gamma(pi^2) with k = 4.5*w gives m=55 and k=4639 which is about 60%
+ slower than k=1.5*w (m=69 and k=1540), thus we change for 1.5*w. */
mpfr_set_prec (s, 53);
mpfr_gamma_alpha (s, w);
- mpfr_set_ui_2exp (s, 9, -1, MPFR_RNDU);
+ mpfr_set_ui_2exp (s, 3, -1, MPFR_RNDU);
mpfr_mul_ui (s, s, w, MPFR_RNDU);
if (mpfr_cmp (z0, s) < 0)
{
Index: src/gamma.c
===
--- src/gamma.c (revision 8920)
+++ src/gamma.c (working copy)
@@ -258,6 +258,10 @@
mpfr_exp_t expxp;
MPFR_BLOCK_DECL (flags);
+ /* quick test for the default exponent range */
+ if (mpfr_get_emax () >= 1073741823UL && MPFR_GET_EXP(x) <= 25)
+return mpfr_gamma_aux (gamma, x, rnd_mode);
+
/* 1/e rounded down to 53 bits */
#define EXPM1_STR "0.0100001011010101100011011000101100111000111"
mpfr_init2 (xp, 53);
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On Wednesday, February 12, 2014 3:01:29 PM UTC+1, William wrote: > > 2. Thanks for clarifying your original question. It's surprising that > MPFR is a full *order of magnitude* slower than PARI at computing > gamma on real input.It's pretty likely that when the line of code > in question was written (prob in 2005 or 2006) this speed difference > wasn't the case. I've cc'd Paul Zimmerman (author of MPFR) in case he > has any comments about this: > > a = RealField(1000)(pi^2) > b = ComplexField(1000)(pi^2) > > %timeit a.gamma() # SLOW -- uses mpfr -- "mpfr_gamma(x.value, > self.value, (self._parent).rnd)" > %timeit b.gamma() # FAST -- uses pari -- > "sage.libs.pari.all.pari.complex(self.real()._pari_(), > self.imag()._pari_())" > > Maybe we should switch to PARI for this.At the least, you could add > >a.gamma(algorithm='pari') > > and at some point make that the default... > In the past, I think MPFR used Spouge's formula to compute gamma which is less efficient than the Stirling series. It seems that the Stirling series is used in the current version of the code, though. The explanation is probably that MPFR doesn't cache Bernoulli numbers (Pari does). Fredrik -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Numerical Methods in Sage
Does anyone have know who is working on improving the numerical methods in Sage? I am beginning my graduate program in numerical analysis and would like to use Sage for my work and research. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On Wed, Feb 12, 2014 at 4:55 AM, wrote: > Ah, I see what you mean. If that's the case then I understand. How does > one find out if this is true? 1. It is *NOT* true.Sage just directly calls the PARI C library, which is always loaded on startup of Sage. 2. Thanks for clarifying your original question. It's surprising that MPFR is a full *order of magnitude* slower than PARI at computing gamma on real input.It's pretty likely that when the line of code in question was written (prob in 2005 or 2006) this speed difference wasn't the case. I've cc'd Paul Zimmerman (author of MPFR) in case he has any comments about this: a = RealField(1000)(pi^2) b = ComplexField(1000)(pi^2) %timeit a.gamma() # SLOW -- uses mpfr -- "mpfr_gamma(x.value, self.value, (self._parent).rnd)" %timeit b.gamma() # FAST -- uses pari -- "sage.libs.pari.all.pari.complex(self.real()._pari_(), self.imag()._pari_())" Maybe we should switch to PARI for this.At the least, you could add a.gamma(algorithm='pari') and at some point make that the default... -- William > > On Wednesday, February 12, 2014 7:46:21 AM UTC-5, Jori Mantysalo wrote: >> >> On Wed, 12 Feb 2014, ref...@uncg.edu wrote: >> >> > I don't understand what you mean. The real and complex fields are >> > loaded >> > upon start up. It seems as though time testing that if the user wishes >> > to >> > compute gamma(x) for real x, he would achieve a faster result by >> > changing x >> > into a complex number and then computing gamma(x). >> >> Fields are, but how about pari? I think that >> >> gamma(3.14159) >> >> actually means something like >> >> load_to_memory(mpfr) >> mpfr.gamma(3.14159) >> >> and >> >> gamma(3.14159+2.71828*I) >> >> means >> >> load_to_memory(pari) >> pari.gamma(3.14159+2.71828*I) >> >> And if we have old server and 20 students using Sage, it may mean >> something more than just waiting for few hunder milliseconds. >> >> -- >> Jori Mäntysalo > > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On Wed, 12 Feb 2014, ref...@uncg.edu wrote: Ah, I see what you mean. If that's the case then I understand. How does one find out if this is true? In general memory usage is complicated to even define on Linux. However, a quick test print get_memory_usage() gamma(3.14159) print get_memory_usage() gamma(3.14159+2.71828*I) print get_memory_usage() output 901.09375 901.09375 901.671875 which means, I think, that "RR-gamma" does not need additional packages, but using "CC-gamma" uses 579 kB additional memory. Not much, even if multiplied with number of students sitting in computer class. -- Jori Mäntysalo -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Explicit example of a theorem someone proved but they couldn't afford to use?
On 8 Feb 2014 05:17, "kcrisman" wrote: > > So, in the Sage/GAP/etc. urban legend, some pathetic PhD student proves a theorem, and then upon graduating can't afford the software it's implemented in. Nice argument for open source. I have no reason to disbelieve it, and have seen very similar quotes attributed to someone from the GAP project. I can believe it, but I can't see any fundamental difference from a Ph.D student developing something which requires hardware he can't afford to use later. That is probably uncommon for a mathematics Ph.D, but it extremely common for an engineering Ph.D. During my Ph.D I made extensive use of a picosecond pulsed laser, but there is no way I could continue that work without working at an institution which had such an expensive laser. There must be a lot of people who done their Ph.D at CERN using facilities no other lab in the world has. I know a licence for some software is expensive. Someone told me that some software for modelling the coverage of cell sites for mobile phones was £1,000,000 which is about 1.6 million USD. But ultimately, I believe that the most expensive hardware will always cost much more than the most expensive software. Personally I believe the most useful thing one gets from doing a Ph.D, is learning how to do research properly. Most people end up using that research knowledge in fields other than what they did their Ph.D in. So the fact that they don't have access to the hardware or software they used during their Ph.D is not such a big issue. Of course free software is nice, and I do understand reasons why it would be sensible to avoid programs like Mathematica. Dave -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
Ah, I see what you mean. If that's the case then I understand. How does one find out if this is true? On Wednesday, February 12, 2014 7:46:21 AM UTC-5, Jori Mantysalo wrote: > > On Wed, 12 Feb 2014, ref...@uncg.edu wrote: > > > I don't understand what you mean. The real and complex fields are > loaded > > upon start up. It seems as though time testing that if the user wishes > to > > compute gamma(x) for real x, he would achieve a faster result by > changing x > > into a complex number and then computing gamma(x). > > Fields are, but how about pari? I think that > > gamma(3.14159) > > actually means something like > > load_to_memory(mpfr) > mpfr.gamma(3.14159) > > and > > gamma(3.14159+2.71828*I) > > means > > load_to_memory(pari) > pari.gamma(3.14159+2.71828*I) > > And if we have old server and 20 students using Sage, it may mean > something more than just waiting for few hunder milliseconds. > > -- > Jori Mäntysalo > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
On Wed, 12 Feb 2014, ref...@uncg.edu wrote: I don't understand what you mean. The real and complex fields are loaded upon start up. It seems as though time testing that if the user wishes to compute gamma(x) for real x, he would achieve a faster result by changing x into a complex number and then computing gamma(x). Fields are, but how about pari? I think that gamma(3.14159) actually means something like load_to_memory(mpfr) mpfr.gamma(3.14159) and gamma(3.14159+2.71828*I) means load_to_memory(pari) pari.gamma(3.14159+2.71828*I) And if we have old server and 20 students using Sage, it may mean something more than just waiting for few hunder milliseconds. -- Jori Mäntysalo -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: Issue With Implementation of Gamma Function
I don't understand what you mean. The real and complex fields are loaded upon start up. It seems as though time testing that if the user wishes to compute gamma(x) for real x, he would achieve a faster result by changing x into a complex number and then computing gamma(x). I don't know how to answer your question. On Wednesday, February 12, 2014 2:38:02 AM UTC-5, Jori Mantysalo wrote: > > On Tue, 11 Feb 2014, ref...@uncg.edu wrote: > > > It seems as though one should always use pari to compute gamma(x) > > regardless of whether x is real or complex, since there is such a > > drastic speedup when using pari. > > Memory? Time to load faster code from disk? > > What actually happens when user of Sage uses functions that internally use > kash, pari, gap... I mean, is package in question dynamically loaded but > never unloaded? > > -- > Jori Mäntysalo > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
