[sage-devel] Re: symbolic series precision vs order term exponent
rjf, what I'm doing is speeding up a subset of series expansions, those that result in rational coefficients. I'm using Flint for poly/series manipulation, so the hard work of reading Brent/Kung was already done by them. My problem was to effectively convert from the expression *tree to the ring/field universe. This is done by walking depth-first and applying operations. Therefore you only know at the end which low degree comes out. However I know now how to get the low degree without losing too much efficiency so I'll try to support both prec and order in the interface. Regards, -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation
On Sunday, October 30, 2016, Emmanuel Charpentier < emanuel.charpent...@gmail.com> wrote: > Dear William, > > Sorry to have sounded frightened by *you* : I'm frightened by the amount > of *my* ignorance... > > Since it seems that I'm (almost) alone among Sage users to be interested > by the development of an interface to R, I'm exploring the options. And I'm > trying to understand things I was used to *use* (as you use your car > without thinking about the thousands of engeenering problems that had to be > solved to make it "just run"). So I try to list all the possible solutions > and ranking them also by a very personal criterion : the amount of knew > knowledge I will need to use them... Your description of Jupyter kernels > makes me put it at the extremity of my list... > > You do not have to convince me that pexpect is a poor way to do it : I'm > convinced : the data interchange involves a serious amount of playing fast > and loose with Python and R dumps. Not quite steamlined... > For data interchange I think rpy2 will be (by far) the optimal approach. William > > > Sincerely, > > -- > Emmanuel Charpentier > > Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit : >> >> Hi all, >> >> The latest R versions depends on libcurl and actually more than that: on >> a libcurl with https support. >> So we might want to build our own libcurl with https support (see #21767) >> but we then need an SSL/TLS implementation which Sage curretnly provides >> only optionally through openSSL because of license issues so we can: >> [1] either make R depend on libcurl depend on openssl and they all become >> optional, >> [2] or make R depend on libcurl and make them standard and add an SSL/TLS >> implementation and its development headers a prereq, >> [3] or make libcurl with https support (and development headers) a >> prereq, which basically means adding an SSL/TLS implementation as a prereq >> as well, >> [4] or make R a prereq, >> [5] or drop R support, >> [6] or patch R not to use curl, >> [7] or patch R to use curl but without https support, >> [8] or wait until the end of times, >> [9] or a mix of all of this, >> [10] or do something else. >> >> What do you think? >> >> Best, >> JPF >> > > -- > 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 https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- Sent from my massive iPhone 6 plus. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Bug: Sage says Maxima was unable to solve this BVP but it's not true!
Hi,
I just realized "depends(y,x)" is not needed when using "maxima_calculus"
(which means, as you pointed out, that something similar is being executed
under the hood).
> reset()
> maxima_calculus('eq: x^2*diff(y,x,2)-x*diff(y,x,1)+y=0')
> maxima_calculus('sol: ode2(eq, y,x)')
> maxima_calculus('exactSol: bc2(sol,x=1,y=1,x=%e,y=2*%e)')
Output:
..
y=x*(%k2*log(x)+%k1)y=x*(log(x)+1)
Note that Sage can solve the differential equation if we remove the
boundary conditions:
> y(x) = function('y')(x); y
> eq = x^2*diff(y,x,2)-x*diff(y,x,1)+y==0; eq
> h = desolve(eq, dvar=y, ivar=x); h
Output:
...
(_K2*log(x) + _K1)*x
So it's definitely something related to way in which boundary conditions
are handled.
Regards
On Sunday, October 30, 2016 at 6:41:21 PM UTC+1, Nils Bruin wrote:
>
> On Sunday, October 30, 2016 at 9:04:37 AM UTC-7, M. Fernandez wrote:
>>
>> I hope that's the right place to post the bug.
>>
>
> Yes, that works.
>
>
>> Use Maxima's interface to solve the problem
>>
>>1.
>>>
>>>maxima('depends(y,x)')
>>>maxima('eq: x^2*diff(y,x,2)-x*diff(y,x,1)+y=0')
>>>maxima('sol: ode2(eq, y,x)')
>>>maxima('exactSol: bc2(sol,x=1,y=1,x=%e,y=2*%e)')
>>
>>
>>
>> Scanning through the code, it looks like the command "depends(y,x)" does
> not get executed by sage, and without it indeed also maxima fails to find a
> solution. Perhaps it should. So, fixing it might boil down to figuring out
> how to execute "depends(y,x)" safely, without affecting future computations.
>
> (by the way, using "maxima_calculus" instead of "maxima" will get you a
> closer replication of the sage use of maxima: sage sets various flags and
> options that are not activated by default in "maxima". Also, changing such
> options in "maxima_calculus" may affect further use of maxima in sage). So
>
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation
Dear William, Sorry to have sounded frightened by *you* : I'm frightened by the amount of *my* ignorance... Since it seems that I'm (almost) alone among Sage users to be interested by the development of an interface to R, I'm exploring the options. And I'm trying to understand things I was used to *use* (as you use your car without thinking about the thousands of engeenering problems that had to be solved to make it "just run"). So I try to list all the possible solutions and ranking them also by a very personal criterion : the amount of knew knowledge I will need to use them... Your description of Jupyter kernels makes me put it at the extremity of my list... You do not have to convince me that pexpect is a poor way to do it : I'm convinced : the data interchange involves a serious amount of playing fast and loose with Python and R dumps. Not quite steamlined... Sincerely, -- Emmanuel Charpentier Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit : > > Hi all, > > The latest R versions depends on libcurl and actually more than that: on a > libcurl with https support. > So we might want to build our own libcurl with https support (see #21767) > but we then need an SSL/TLS implementation which Sage curretnly provides > only optionally through openSSL because of license issues so we can: > [1] either make R depend on libcurl depend on openssl and they all become > optional, > [2] or make R depend on libcurl and make them standard and add an SSL/TLS > implementation and its development headers a prereq, > [3] or make libcurl with https support (and development headers) a prereq, > which basically means adding an SSL/TLS implementation as a prereq as well, > [4] or make R a prereq, > [5] or drop R support, > [6] or patch R not to use curl, > [7] or patch R to use curl but without https support, > [8] or wait until the end of times, > [9] or a mix of all of this, > [10] or do something else. > > What do you think? > > Best, > JPF > -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation
On Sunday, October 30, 2016, William Stein wrote:
> On Sun, Oct 30, 2016 at 12:09 PM, Emmanuel Charpentier
> > wrote:
> > Dear William,
> >
> > thanks for this advice, which I'll consider seriously, notwithstanding
> its
> > total opacity to me at the moment
> >
> > I just checked that the r interface in SMC is indeed different from what
> > exists in sage "standalone". It is also a bit difficult to understand,
> due
> > to present lack of documentation. Cut-n'paste from a sagews :
> >
> > help("r")
> > ︡983aebe0-3f6e-46ff-9d40-ce8e153480d2︡{"stdout":"no Python documentation
> > found for 'r'\n\n"}︡{"done":true}︡
> >
> > But the behavior of R in % cells is crystal-clear. The first difficulty I
> > have is to understand how to exchange data (or other structures) between
> R
> > and Sage (which is the *whole* point of the exercise...).
> >
> > Do you think that this R interface, specific to Sagemath Cloud, could be
> > ported to Sage ? And do you think that t would involve R-version specific
> > code ?
>
> I don't think this question really makes any sense. What you have to
> do is simply learn Jupyter... then rethink the question. Except
> that's harder than it should be...! I just posted this to
> https://gitter.im/jupyter/jupyter: "Hi, I just spent a shockingly
> large amount of time searching and googling for basically an overview
> of what a Jupyter kernel is and how to write one. There's some old
> deprecated docs about this, which all have big pointers to newer docs.
> I can't find any new docs that simply explain what a Jupyter kernel is
> and how to write one. I'm trying to convince other Sage developers to
> use Jupyter kernels instead of the pexpect interfaces I wrote for Sage
> -- at least for R mode -- and it's impossible to convince them if I
> can't even point to the docs. So help... For example, going here, I
> would expect under "Kernels" the docs I want, but I can't find
> anything."
Answer: https://github.com/jupyter/jupyter/issues/216
>
> >
> > Another potential stumbling point it that the main part of the interface
> > (the IRkernel package), has not (het) been accepted by CRAN, rendering
> its
> > future ability questionable.
> >
> > I plan to look also at what is offered by the Rpy2 interface It would
> take a
> > bit of work to emulate the behavior of the pexpect nterface, but that
> might
> > offer a good interim solution (at this time, I have *no* idea about what
> the
> > IRkernel and its companion libraries are supposed to do).
> >
> > Last recourse : the R library itself. Again, I don't know (yet) what it
> > offers.
> >
> > Again, thank you for your (a bit frightening...) advice,
>
> Sorry for being scary. It's just advice. Feel free to ignore, of course.
>
> > --
> > Emmanuel Charpentier
> >
> > Le dimanche 30 octobre 2016 17:10:31 UTC+1, William a écrit :
> >>
> >> On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier
> >> > wrote:
> >> > OK. It seems that a clear consensus exists for the excision of R
> >> > _proprio
> >> > dictu_ from Sage.
> >> >
> >> > If we break it, can we at least keep the (Sage's) pieces ? An optional
> >> > package offering the current R interface(s) depending on a
> >> > systemwide(at
> >> > least user-reachable) version of R and the R library might offer the
> >> > functionality without entailing the (not so trivial) work of
> maintaining
> >> > our
> >> > own R port.
> >> >
> >> > Do you have an idea of the amount of work involved ? And how to, do
> it ?
> >> > The
> >> > rpy2 part is probably easy, but I expect surprises on the pexpec(t)
> >> > front
> >> > (at least if we want to keep compatibility with existing code using
> >> > current
> >> > R interface facilities...). Any hint on the right starting point(s)
> >> > would
> >> > be welcome...
> >> >
> >> > BTW : I have also had a (quite superficial) look at what pandas and
> >> > statsmodel claim to do. They (and scikit-learn, which look
> interesting,
> >> > and
> >> > stan, already available from Python) might be indeed useful for
> >> > run-of-the-mill descriptive analysis and regression models (and Stan
> for
> >> > more exotic modeling). Packaging them for Sage might prove useful.
> >> >
> >> > However, those 9000+ R packages are here for a reason : if some of
> them
> >> > (a
> >> > small minority, IMHO) are obvious PhD-earning byproducts, others aim
> to
> >> > solve difficult (if specialized) problems, badly solved (or not even
> >> > considered) by the aforementioned trio. keeping a way to reach them
> from
> >> > Sage might be important. Hence my plea for an "R interface(s)"
> package.
> >> >
> >> > Another (IMHO futile) reason for keeping an R interface in our arsenal
> >> > is
> >> > "name recognition" : quoting R in a "Materials and methods" section no
> >> > longer raises questions from reviewers ; somehow, I doubt that pandas
> >> > and
> >> > statmodels get the same answer...
> >> >
> >> > What can you add ? Can someone propose a work plan ?
> >>
> >> I'm n
Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation
On Sun, Oct 30, 2016 at 12:09 PM, Emmanuel Charpentier
wrote:
> Dear William,
>
> thanks for this advice, which I'll consider seriously, notwithstanding its
> total opacity to me at the moment
>
> I just checked that the r interface in SMC is indeed different from what
> exists in sage "standalone". It is also a bit difficult to understand, due
> to present lack of documentation. Cut-n'paste from a sagews :
>
> help("r")
> ︡983aebe0-3f6e-46ff-9d40-ce8e153480d2︡{"stdout":"no Python documentation
> found for 'r'\n\n"}︡{"done":true}︡
>
> But the behavior of R in % cells is crystal-clear. The first difficulty I
> have is to understand how to exchange data (or other structures) between R
> and Sage (which is the *whole* point of the exercise...).
>
> Do you think that this R interface, specific to Sagemath Cloud, could be
> ported to Sage ? And do you think that t would involve R-version specific
> code ?
I don't think this question really makes any sense. What you have to
do is simply learn Jupyter... then rethink the question. Except
that's harder than it should be...! I just posted this to
https://gitter.im/jupyter/jupyter: "Hi, I just spent a shockingly
large amount of time searching and googling for basically an overview
of what a Jupyter kernel is and how to write one. There's some old
deprecated docs about this, which all have big pointers to newer docs.
I can't find any new docs that simply explain what a Jupyter kernel is
and how to write one. I'm trying to convince other Sage developers to
use Jupyter kernels instead of the pexpect interfaces I wrote for Sage
-- at least for R mode -- and it's impossible to convince them if I
can't even point to the docs. So help... For example, going here, I
would expect under "Kernels" the docs I want, but I can't find
anything."
>
> Another potential stumbling point it that the main part of the interface
> (the IRkernel package), has not (het) been accepted by CRAN, rendering its
> future ability questionable.
>
> I plan to look also at what is offered by the Rpy2 interface It would take a
> bit of work to emulate the behavior of the pexpect nterface, but that might
> offer a good interim solution (at this time, I have *no* idea about what the
> IRkernel and its companion libraries are supposed to do).
>
> Last recourse : the R library itself. Again, I don't know (yet) what it
> offers.
>
> Again, thank you for your (a bit frightening...) advice,
Sorry for being scary. It's just advice. Feel free to ignore, of course.
> --
> Emmanuel Charpentier
>
> Le dimanche 30 octobre 2016 17:10:31 UTC+1, William a écrit :
>>
>> On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier
>> wrote:
>> > OK. It seems that a clear consensus exists for the excision of R
>> > _proprio
>> > dictu_ from Sage.
>> >
>> > If we break it, can we at least keep the (Sage's) pieces ? An optional
>> > package offering the current R interface(s) depending on a
>> > systemwide(at
>> > least user-reachable) version of R and the R library might offer the
>> > functionality without entailing the (not so trivial) work of maintaining
>> > our
>> > own R port.
>> >
>> > Do you have an idea of the amount of work involved ? And how to, do it ?
>> > The
>> > rpy2 part is probably easy, but I expect surprises on the pexpec(t)
>> > front
>> > (at least if we want to keep compatibility with existing code using
>> > current
>> > R interface facilities...). Any hint on the right starting point(s)
>> > would
>> > be welcome...
>> >
>> > BTW : I have also had a (quite superficial) look at what pandas and
>> > statsmodel claim to do. They (and scikit-learn, which look interesting,
>> > and
>> > stan, already available from Python) might be indeed useful for
>> > run-of-the-mill descriptive analysis and regression models (and Stan for
>> > more exotic modeling). Packaging them for Sage might prove useful.
>> >
>> > However, those 9000+ R packages are here for a reason : if some of them
>> > (a
>> > small minority, IMHO) are obvious PhD-earning byproducts, others aim to
>> > solve difficult (if specialized) problems, badly solved (or not even
>> > considered) by the aforementioned trio. keeping a way to reach them from
>> > Sage might be important. Hence my plea for an "R interface(s)" package.
>> >
>> > Another (IMHO futile) reason for keeping an R interface in our arsenal
>> > is
>> > "name recognition" : quoting R in a "Materials and methods" section no
>> > longer raises questions from reviewers ; somehow, I doubt that pandas
>> > and
>> > statmodels get the same answer...
>> >
>> > What can you add ? Can someone propose a work plan ?
>>
>> I'm not thinking about politics and name recognition below - I'm just
>> providing a technical/engineering perspective.
>>
>> If anybody is seriously planning to work on the R pexpect interface, I
>> would personally suggest they consider instead working on the R
>> Jupyter kernel bridge instead, and maybe create a drop in replacement
>> for the current pexpe
Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation
Dear William,
thanks for this advice, which I'll consider seriously, notwithstanding its
total opacity to me at the moment
I just checked that the r interface in SMC is indeed different from what
exists in sage "standalone". It is also a bit difficult to understand, due
to present lack of documentation. Cut-n'paste from a sagews :
help("r")
︡983aebe0-3f6e-46ff-9d40-ce8e153480d2︡{"stdout":"no Python documentation
found for 'r'\n\n"}︡{"done":true}︡
But the behavior of R in % cells is crystal-clear. The first difficulty I
have is to understand how to exchange data (or other structures) between R
and Sage (which is the *whole* point of the exercise...).
Do you think that this R interface, specific to Sagemath Cloud, could be
ported to Sage ? And do you think that t would involve R-version specific
code ?
Another potential stumbling point it that the main part of the interface
(the IRkernel package), has not (het) been accepted by CRAN, rendering its
future ability questionable.
I plan to look also at what is offered by the Rpy2 interface It would take
a bit of work to emulate the behavior of the pexpect nterface, but that
might offer a good interim solution (at this time, I have *no* idea about
what the IRkernel and its companion libraries are supposed to do).
Last recourse : the R library itself. Again, I don't know (yet) what it
offers.
Again, thank you for your (a bit frightening...) advice,
--
Emmanuel Charpentier
Le dimanche 30 octobre 2016 17:10:31 UTC+1, William a écrit :
>
> On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier
> > wrote:
> > OK. It seems that a clear consensus exists for the excision of R
> _proprio
> > dictu_ from Sage.
> >
> > If we break it, can we at least keep the (Sage's) pieces ? An optional
> > package offering the current R interface(s) depending on a
> systemwide(at
> > least user-reachable) version of R and the R library might offer the
> > functionality without entailing the (not so trivial) work of maintaining
> our
> > own R port.
> >
> > Do you have an idea of the amount of work involved ? And how to, do it ?
> The
> > rpy2 part is probably easy, but I expect surprises on the pexpec(t)
> front
> > (at least if we want to keep compatibility with existing code using
> current
> > R interface facilities...). Any hint on the right starting point(s)
> would
> > be welcome...
> >
> > BTW : I have also had a (quite superficial) look at what pandas and
> > statsmodel claim to do. They (and scikit-learn, which look interesting,
> and
> > stan, already available from Python) might be indeed useful for
> > run-of-the-mill descriptive analysis and regression models (and Stan for
> > more exotic modeling). Packaging them for Sage might prove useful.
> >
> > However, those 9000+ R packages are here for a reason : if some of them
> (a
> > small minority, IMHO) are obvious PhD-earning byproducts, others aim to
> > solve difficult (if specialized) problems, badly solved (or not even
> > considered) by the aforementioned trio. keeping a way to reach them from
> > Sage might be important. Hence my plea for an "R interface(s)" package.
> >
> > Another (IMHO futile) reason for keeping an R interface in our arsenal
> is
> > "name recognition" : quoting R in a "Materials and methods" section no
> > longer raises questions from reviewers ; somehow, I doubt that pandas
> and
> > statmodels get the same answer...
> >
> > What can you add ? Can someone propose a work plan ?
>
> I'm not thinking about politics and name recognition below - I'm just
> providing a technical/engineering perspective.
>
> If anybody is seriously planning to work on the R pexpect interface, I
> would personally suggest they consider instead working on the R
> Jupyter kernel bridge instead, and maybe create a drop in replacement
> for the current pexpect interface that uses the R Jupyter kernel.
> This would likely be time well spent. This is what we (mostly Hal
> Snyder) have been doing with SageMathCloud, where now the %r mode in
> Sage worksheets is implemented entirely using Jupyter (which we did
> due to user bug/robustness reports with the sage pexpect interface):
>
>
> https://github.com/sagemathinc/smc/blob/master/src/smc_sagews/smc_sagews/sage_jupyter.py
>
>
> Some history - I wrote those (stupid) pexpect interfaces in
> 2005-2006 as a way to bootstrap making Python talk to everything else.
> However, they are basically the worst *viable* approach to the
> problem. Jupyter kernels are potentially a lot more work than using
> pexpect, but they are clearly a better approach.
>
> Yes, using pexpect is one way to write a Jupyter kernel, but
> fortunately there are better ways. For example, the Jupyter kernel is
> 1000(s) of lines of nontrivial code written in the R language, which
> is being improved all the time due to extensive use by users. The
> Jupyter R kernel is a serious actively developed project:
[sage-devel] Re: Multivariate polynomial factoring and bug(?)
Unless I'm mistaken, the polynomials are at the end. I guess that the heuristics used by Singular for sparse multivariate factorization did not succeed for this polynomial (this pair is slightly more complicated than the previous pairs), and reverted to dense factorization (probably Hensel lift algorithm), which requires much more ressources (I have checked with giac and aborted after half an hour and more than 8G of RAM required). P:=373248*a^25*b^9*c^25*d^21*E^21 + 1866240*a^20*b^9*c^25*d^24*E^21 + 373248*a^20*b^4*c^25*d^22*E^21 + 124416*a^20*b^4*c^28*d^21*E^18 + 37324800*a^16*b^4*c^25*d^21*E^20 + 186624000*a^16*b^4*c^26*d^21*E^18 + 18662400*a^13*b^6*c^25*d^21*E^17 + 1244160*a^13*b^5*c^25*d^21*E^12 + 311040*a^13*b^7*c^23*d^16*E^12 + 1244160*a^13*b^4*c^25*d^16*E^13 + 311040*a^16*b^4*c^20*d^16*E^12 + 62208*a^13*b*c^21*d^16*E^12 + 23328*a^13*b*c^20*d^17*E^8 + 7776*a^13*b*c^15*d^18*E^8 + 2592*a^13*b*c^15*d^14*E^10 + 2592*a^13*b^4*c^15*d^10*E^8 + 1728*a^8*b*c^15*d^14*E^8 + 324*a^8*b^4*c^15*d^6*E^8 + 216000*a^4*b^3*c^15*d^6*E^8 + 216000*a^4*b*c^10*d^9*E^8 + 86400*a^4*b*c^10*d^8*E^7 + 32400*a^7*b*c^10*d^3*E^7 + 2700*a^4*b^4*c^10*d^3*E^3 + 675*a^6*b*c^7*d^3*E^3 + 1125*a^5*b*c^2*d^3*E^3 + 135*b^5*c^2*d^3*E^3 + 27*c^2*d^6*E^3 + 12*c^7 + 9*c^3*d^3 + a^2; Q:=33177600*a^7*b^16*c^6*d^33*E^36 + 8294400*a^7*b^16*c^6*d^33*E^35 + 10368000*a^7*b^16*c^6*d^33*E^31 + 2073600*a^7*b^15*c^8*d^33*E^29 + 3110400*a^7*b^15*c^6*d^33*E^29 + 622080*a^2*b^15*c^6*d^33*E^32 + 311040*a^2*b^15*c^6*d^33*E^26 + 51840*a^2*b^19*c^6*d^33*E^20 + 25920*a^2*b^14*c^6*d^37*E^20 + 6480*a^2*b^14*c^10*d^31*E^20 + 1728*a^7*b^14*c^2*d^29*E^20 + 6480*a^2*b^14*c^2*d^32*E^20 + 3456000*a^6*b^12*c^2*d^29*E^20 + 1152000*a^2*b^14*d^29*E^20 + 72*a^6*b^9*d^29*E^20 + 144000*a*b^9*d^34*E^20 + 28800*a*b^9*c^3*d^29*E^18 + 23040*a*b^9*d^31*E^18 + 8640*a*b^9*c^5*d^26*E^17 + 1728*a*b^9*c^4*d^23*E^17 + 2304*a*b^9*d^18*E^21 + 576*b^9*d^22*E^17 + 1152000*b^14*d^16*E^17 + 230400*b^12*d^16*E^17 + 138240*b^8*d^21*E^12 + 115200*b^4*d^19*E^12 + 34560*b^4*d^13*E^14 + 11520*b^6*d^13*E^8 + 2304*b^4*c*d^11*E^8 + 288*b^4*c^2*d^11*E^3 + 72*b^7*d^8*E^3 + 288*c^2*d^8*E^3 + 18*d^8*E^3 + 9*b*d^7 + 3*c^5 + 6*b^2*d^3; -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Bug: Sage says Maxima was unable to solve this BVP but it's not true!
On Sunday, October 30, 2016 at 9:04:37 AM UTC-7, M. Fernandez wrote:
>
> I hope that's the right place to post the bug.
>
Yes, that works.
> Use Maxima's interface to solve the problem
>
>1.
>>
>>maxima('depends(y,x)')
>>maxima('eq: x^2*diff(y,x,2)-x*diff(y,x,1)+y=0')
>>maxima('sol: ode2(eq, y,x)')
>>maxima('exactSol: bc2(sol,x=1,y=1,x=%e,y=2*%e)')
>
>
>
> Scanning through the code, it looks like the command "depends(y,x)" does
not get executed by sage, and without it indeed also maxima fails to find a
solution. Perhaps it should. So, fixing it might boil down to figuring out
how to execute "depends(y,x)" safely, without affecting future computations.
(by the way, using "maxima_calculus" instead of "maxima" will get you a
closer replication of the sage use of maxima: sage sets various flags and
options that are not activated by default in "maxima". Also, changing such
options in "maxima_calculus" may affect further use of maxima in sage). So
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Multivariate polynomial factoring and bug(?)
On Saturday, October 29, 2016 at 10:33:42 PM UTC-7, Jori Mäntysalo wrote: > > On Sat, 29 Oct 2016, rjf wrote: > > > If you think that there is a problem factoring a polynomial,present the > polynomial. > > > > A report that something random happens with something random > > is not a useful bug report. > > If the random thing has been generated by Sage random functions after > set_random_seed(n) with given n, it is not that random. > If you are not running sage, but perhaps want to try that polynomial factorization on some other system, it would be nice to see the polynomial. Especially since the original script seems to print the polynomial. Also "got stuck" is not a very good specification of what happened. How long did it run? Did it stop with a message? RJF > > -- > 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation
On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier wrote: > OK. It seems that a clear consensus exists for the excision of R _proprio > dictu_ from Sage. > > If we break it, can we at least keep the (Sage's) pieces ? An optional > package offering the current R interface(s) depending on a systemwide(at > least user-reachable) version of R and the R library might offer the > functionality without entailing the (not so trivial) work of maintaining our > own R port. > > Do you have an idea of the amount of work involved ? And how to, do it ? The > rpy2 part is probably easy, but I expect surprises on the pexpec(t) front > (at least if we want to keep compatibility with existing code using current > R interface facilities...). Any hint on the right starting point(s) would > be welcome... > > BTW : I have also had a (quite superficial) look at what pandas and > statsmodel claim to do. They (and scikit-learn, which look interesting, and > stan, already available from Python) might be indeed useful for > run-of-the-mill descriptive analysis and regression models (and Stan for > more exotic modeling). Packaging them for Sage might prove useful. > > However, those 9000+ R packages are here for a reason : if some of them (a > small minority, IMHO) are obvious PhD-earning byproducts, others aim to > solve difficult (if specialized) problems, badly solved (or not even > considered) by the aforementioned trio. keeping a way to reach them from > Sage might be important. Hence my plea for an "R interface(s)" package. > > Another (IMHO futile) reason for keeping an R interface in our arsenal is > "name recognition" : quoting R in a "Materials and methods" section no > longer raises questions from reviewers ; somehow, I doubt that pandas and > statmodels get the same answer... > > What can you add ? Can someone propose a work plan ? I'm not thinking about politics and name recognition below - I'm just providing a technical/engineering perspective. If anybody is seriously planning to work on the R pexpect interface, I would personally suggest they consider instead working on the R Jupyter kernel bridge instead, and maybe create a drop in replacement for the current pexpect interface that uses the R Jupyter kernel. This would likely be time well spent. This is what we (mostly Hal Snyder) have been doing with SageMathCloud, where now the %r mode in Sage worksheets is implemented entirely using Jupyter (which we did due to user bug/robustness reports with the sage pexpect interface): https://github.com/sagemathinc/smc/blob/master/src/smc_sagews/smc_sagews/sage_jupyter.py Some history - I wrote those (stupid) pexpect interfaces in 2005-2006 as a way to bootstrap making Python talk to everything else. However, they are basically the worst *viable* approach to the problem. Jupyter kernels are potentially a lot more work than using pexpect, but they are clearly a better approach. Yes, using pexpect is one way to write a Jupyter kernel, but fortunately there are better ways. For example, the Jupyter kernel is 1000(s) of lines of nontrivial code written in the R language, which is being improved all the time due to extensive use by users. The Jupyter R kernel is a serious actively developed project: https://github.com/IRkernel/IRkernel Compare that to the Sage R pexpect interface... https://github.com/sagemath/sage/commits/master/src/sage/interfaces/r.py -- William -- William (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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] bug: Sage says Maxima can't solve this BVP but it's not true!
I hope that's the right place to post the bug.
When solving this linear second order ODE boundary value problem:
> x^2*diff(y,x,2)-x*diff(y,x,1)+y == 0
> y(1)=1
> y(e)=2*e
Sage says Maxima can't solve it but when calling Maxima through Sage's
interface I get the right solution.
Steps to reproduce it
1. Try to solve the BVP in Sage:
y(x) = function('y')(x); y
>eq = x^2*diff(y,x,2)-x*diff(y,x,1)+y==0; eq
>h = desolve(eq, dvar=y, ivar=x,ics=[1,1,e,2*e]); h
Output:
Error in lines 3-3
Traceback (most recent call last):
File
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/smc_sagews/sage_server.py",
line 968, in execute
exec compile(block+'\n', '', 'single') in namespace, locals
File "", line 1, in
File
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/calculus/desolvers.py",
line 522, in desolve
raise NotImplementedError("Maxima was unable to solve this BVP. Remove
the initial condition to get the general solution.")
NotImplementedError: *Maxima was unable to solve this BVP. Remove the
initial condition to get the general solution.
*
2. Use Maxima's interface to solve the problem
maxima('depends(y,x)')
>maxima('eq: x^2*diff(y,x,2)-x*diff(y,x,1)+y=0')
>maxima('sol: ode2(eq, y,x)')
>maxima('exactSol: bc2(sol,x=1,y=1,x=%e,y=2*%e)')
Output:
...
y=x*(log(x)+1)
Tested using SageMathCloud on the 30/10/2016 so I guess Sage version 7.3
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Bug: Sage says Maxima was unable to solve this BVP but it's not true!
I hope that's the right place to post the bug.
When solving this linear second order ODE boundary value problem:
> x^2*diff(y,x,2)-x*diff(y,x,1)+y == 0
> y(1)=1
> y(e)=2*e
Sage says Maxima can't solve it but when calling Maxima through Sage's
interface I get the right solution.
Steps to reproduce it
1. Try to solve the BVP in Sage:
y(x) = function('y')(x); y
>eq = x^2*diff(y,x,2)-x*diff(y,x,1)+y==0; eq
>h = desolve(eq, dvar=y, ivar=x,ics=[1,1,e,2*e]); h
Output:
Error in lines 3-3
Traceback (most recent call last):
File
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/smc_sagews/sage_server.py",
line 968, in execute
exec compile(block+'\n', '', 'single') in namespace, locals
File "", line 1, in
File
"/projects/sage/sage-7.3/local/lib/python2.7/site-packages/sage/calculus/desolvers.py",
line 522, in desolve
raise NotImplementedError("Maxima was unable to solve this BVP. Remove
the initial condition to get the general solution.")
NotImplementedError: *Maxima was unable to solve this BVP. Remove the
initial condition to get the general solution.
*
2. Use Maxima's interface to solve the problem
maxima('depends(y,x)')
>maxima('eq: x^2*diff(y,x,2)-x*diff(y,x,1)+y=0')
>maxima('sol: ode2(eq, y,x)')
>maxima('exactSol: bc2(sol,x=1,y=1,x=%e,y=2*%e)')
Output:
...
y=x*(log(x)+1)
Tested using SageMathCloud on the 30/10/2016 so I guess Sage version 7.3
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: actions Zmod and QQ
On Sunday, October 30, 2016 at 6:16:37 AM UTC-7, vdelecroix wrote: > > I think that the behavior of these operations should be similar. Do > you think that > A) the above is fine (with explanation please) > B) we should raise an error in the first example > C) the second example should work and the answer be an element of > Zmod(5) > D) ? > I'd think B or C, depending on what makes for a more consistent coercion system (sometimes special cases are naturally resolved one way or another by design choices made elsewhere) I'm leaning more towards B (and perhaps A), since it seems that successful action discovery seems due to a fluke in pushout, combined by the use of conversion in action implementation where coercion seems more appropriate: sage: F=GF(5) sage: K=sage.categories.pushout.pushout(F,QQ) Finite Field of size 5 sage: F.0*K(QQ.0) 1 sage: F.0*QQ.0 TypeError: unsupported operand parent(s) for '*': 'Finite Field of size 5' and 'Rational Field' so, we see the pushout of F and QQ exists, but QQ does not coerce into it. Elements do convert into it, though. This is different for the uncontroversial case (Z['x'] and QQ) sage: P=ZZ['x'] sage: R=sage.categories.pushout.pushout(P,QQ); R Univariate Polynomial Ring in x over Rational Field sage: P.0*QQ.0 x In the implementation of sage.structure.ModuleAction, you can see that: - pushout is used to find a common module - in Action.__call__, a *conversion* is used to put the module element into that overmodule. So the fact that there (rightly) isn't a coercion from QQ^2 to (GF(5))^2 is actively circumvented. I'm not sure that's such a good idea. I think the pushout of GF(5) and QQ exists because: sage: sage.categories.pushout.construction_tower(QQ) [(None, Rational Field), (FractionField, Integer Ring)] sage: sage.categories.pushout.construction_tower(GF(5)) [(None, Finite Field of size 5), (QuotientFunctor, Integer Ring)] and we can get GF(5) by taking FractionField(QuotientFunctor(ZZ by (5)). Indeed, if we take a quotient of ZZ that is not a field already, the module action fails: sage: a=Zmod(15)(1) sage: b=(QQ^2).0 sage: a*b TypeError: unsupported operand parent(s) for '*': 'Ring of integers modulo 15' and 'Vector space of dimension 2 over Rational Field' -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] actions Zmod and QQ
On 2016-10-30 14:16, Vincent Delecroix wrote: > I think that the behavior of these operations should be similar. Do > you think that > A) the above is fine (with explanation please) > B) we should raise an error in the first example > C) the second example should work and the answer be an element of Zmod(5) > D) ? C -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] actions Zmod and QQ
On 30 October 2016 at 13:16, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
> Dear all,
>
> (cross post sage-devel, sage-nt)
>
> While working on something else I discovered that it is possible to
> multiply vectors over QQ by elements of Zmod rings
> {{{
> sage: Zmod(5).an_element() * (QQ^2).an_element()
> (0, 0)
> sage: parent(_)
> Vector space of dimension 2 over Ring of integers modulo 5
> }}}
> However it is not possible to multiply rationals by elements of Zmod ring
> {{{
> sage: Zmod(5).an_element() * QQ.an_element()
> Traceback (most recent call last):
> ...
> TypeError: unsupported operand parent(s) for '*': 'Ring of integers
> modulo 5' and 'Rational Field'
> }}}
>
> I think that the behavior of these operations should be similar. Do
> you think that
> A) the above is fine (with explanation please)
> B) we should raise an error in the first example
> C) the second example should work and the answer be an element of Zmod(5)
> D) ?
>
I vote C (so that QQ works the same as QQ^1) with the usual proviso
that if the denominator is not coprime to the modulus, an error is
raised.
> Cheers
> 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 https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] actions Zmod and QQ
Dear all,
(cross post sage-devel, sage-nt)
While working on something else I discovered that it is possible to
multiply vectors over QQ by elements of Zmod rings
{{{
sage: Zmod(5).an_element() * (QQ^2).an_element()
(0, 0)
sage: parent(_)
Vector space of dimension 2 over Ring of integers modulo 5
}}}
However it is not possible to multiply rationals by elements of Zmod ring
{{{
sage: Zmod(5).an_element() * QQ.an_element()
Traceback (most recent call last):
...
TypeError: unsupported operand parent(s) for '*': 'Ring of integers
modulo 5' and 'Rational Field'
}}}
I think that the behavior of these operations should be similar. Do
you think that
A) the above is fine (with explanation please)
B) we should raise an error in the first example
C) the second example should work and the answer be an element of Zmod(5)
D) ?
Cheers
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation
OK. It seems that a clear consensus exists for the excision of R _proprio dictu_ from Sage. If we break it, can we at least keep the (Sage's) pieces ? An optional package offering the current R interface(s) depending on a systemwide(at least user-reachable) version of R and the R library might offer the functionality without entailing the (not so trivial) work of maintaining our own R port. Do you have an idea of the amount of work involved ? And how to, do it ? The rpy2 part is probably easy, but I expect surprises on the pexpec(t) front (at least if we want to keep compatibility with existing code using current R interface facilities...). Any hint on the right starting point(s) would be welcome... BTW : I have also had a (quite superficial) look at what pandas and statsmodel claim to do. They (and scikit-learn, which look interesting, and stan, already available from Python) might be indeed useful for run-of-the-mill descriptive analysis and regression models (and Stan for more exotic modeling). Packaging them for Sage might prove useful. However, those 9000+ R packages are here for a reason : if some of them (a small minority, IMHO) are obvious PhD-earning byproducts, others aim to solve difficult (if specialized) problems, badly solved (or not even considered) by the aforementioned trio. keeping a way to reach them from Sage might be important. Hence my plea for an "R interface(s)" package. Another (IMHO futile) reason for keeping an R interface in our arsenal is "name recognition" : quoting R in a "Materials and methods" section no longer raises questions from reviewers ; somehow, I doubt that pandas and statmodels get the same answer... What can you add ? Can someone propose a work plan ? -- Emmanuel Charpentier -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
