Re: [sage-devel] "replacement" optional packages

I have been thinking about this too. My personal conclusion was that the "type" enumeration (standard, optional, experimental, pip, script) is simply too restricted and that we need additional metadata with more degrees of freedom. Currently, the "type" field is relevant for: - which packages

[sage-devel] Re: "replacement" optional packages

On Tuesday, February 28, 2017 at 5:20:23 PM UTC, Thierry (sage-googlesucks@xxx) wrote: > > Hi, > > having the possibility to install all optional packages is interesting for > easy deployment as well as for testing (we need more automated tests of > all optional packages, in particular more

Re: [sage-devel] Names of special methods like _pari_

On 2017-03-01 03:43, David Roe wrote: I don't see the benefits of changing as sufficient to outweigh the costs of an incompatible change We could always keep supporting _pari_ with deprecation, so the cost of changing is zero. -- You received this message because you are subscribed to the

Re: [sage-devel] Names of special methods like _pari_

What about _latex_? Would you plan to change that, too? Sage objects and elements have lots of single-underscore methods, like _repr_, _mul_, etc. Well, I would put _latex_ in the same basket as _pari_. But _repr_ and _mul_ are different: they deal with the implementation of SageObject/Element

[sage-devel] Re: integration algorithms

On Wednesday, March 1, 2017 at 5:38:28 AM UTC, rjf wrote: > > It is possible that people interested in this thread would benefit by > reading > the PhD theses of Joel Moses, and also James Slagle. > > Briefly, Moses viewed the problem as 3 stages. A simple algorithm > (derivative-divides) >

[sage-devel] Re: integration algorithms

Le mercredi 1 mars 2017 06:38:28 UTC+1, rjf a écrit : > > Other than the academic interest in 'anti-differentiation' it is not > clear that this is such an important problem in (say) physics or > engineering. > Definite integration problems can be done by quadrature programs, > and of course

[sage-devel] Re: integration algorithms

It is possible that people interested in this thread would benefit by reading the PhD theses of Joel Moses, and also James Slagle. Briefly, Moses viewed the problem as 3 stages. A simple algorithm (derivative-divides) which can be written very compactly if you have the right tools. 2. a

Re: [sage-devel] Names of special methods like _pari_

I don't see the benefits of changing as sufficient to outweigh the costs of an incompatible change, so I would vote for (1). Among the other options, (4) seems the most reasonable. David On Tue, Feb 28, 2017 at 8:57 PM, Travis Scrimshaw wrote: > > > On Tuesday, February 28,

Re: [sage-devel] Names of special methods like _pari_

On Tuesday, February 28, 2017 at 4:41:40 PM UTC-6, John H Palmieri wrote: > > > > On Tuesday, February 28, 2017 at 1:16:53 PM UTC-8, Jeroen Demeyer wrote: >> >> On 2017-02-28 20:46, Johan S. H. Rosenkilde wrote: >> > In that case, it >> > could be seen as an implementation detail that objects

[sage-devel] Re: "replacement" optional packages

+1 to having another marker for those alternative-to-standard packages, but I think this is a bit of a problem to do in some general framework. These packages are suppose to come in sets and one of them will have to be installed. So it might be better to think of ways to combine these packages

Re: [sage-devel] Names of special methods like _pari_

On Tue, Feb 28, 2017 at 2:41 PM, John H Palmieri wrote: > > > On Tuesday, February 28, 2017 at 1:16:53 PM UTC-8, Jeroen Demeyer wrote: >> >> On 2017-02-28 20:46, Johan S. H. Rosenkilde wrote: >> > In that case, it >> > could be seen as an implementation detail that objects

Re: [sage-devel] Names of special methods like _pari_

On Tuesday, February 28, 2017 at 1:16:53 PM UTC-8, Jeroen Demeyer wrote: > > On 2017-02-28 20:46, Johan S. H. Rosenkilde wrote: > > In that case, it > > could be seen as an implementation detail that objects have the _pari > > method, and private would be apt. > > Yes, it's an

Re: [sage-devel] Names of special methods like _pari_

On 2017-02-28 20:46, Johan S. H. Rosenkilde wrote: In that case, it could be seen as an implementation detail that objects have the _pari method, and private would be apt. Yes, it's an "implementation detail" but it's not "private". I would say it's a public implementation detail: something

Re: [sage-devel] Re: Names of special methods like _pari_

On 2017-02-28 21:08, Nils Bruin wrote: On Tuesday, February 28, 2017 at 8:26:22 AM UTC-8, Jeroen Demeyer wrote: (4) __pari__(): consistent with Python (__int__, __str__) and NumPy (__array__). However, creating such names possibly goes against the Python documentation [2]. This

Re: [sage-devel] Re: Names of special methods like _pari_

On 2017-02-28 21:08, Nils Bruin wrote: So it seems to me changing the names will be a lot of work with very limited actual benefit. It's just a simple search-and-replace-all, so essentially no work. I don't think we should stick with the status quo just because of that. -- You received this

[sage-devel] Re: Names of special methods like _pari_

On Tuesday, February 28, 2017 at 8:26:22 AM UTC-8, Jeroen Demeyer wrote: > > (4) __pari__(): consistent with Python (__int__, __str__) and NumPy > (__array__). However, creating such names possibly goes against the > Python documentation [2]. > > This would leave with me the strong expectation

Re: [sage-devel] Names of special methods like _pari_

> > (2) _pari(): meant for private methods. This doesn't seem correct to me, > because we want this method to be part of the public API. But as Thierry says, perhaps not so public that we want it to figure in tab-completion on all objects everywhere. Isn't this exactly because most users would

[sage-devel] Re: integration algorithms

Le mardi 28 février 2017 18:32:19 UTC+1, mmarco a écrit : > > If it makes sense to use integration by parts or not deppends heavily on > the actual expression. I suspect that, if you try to make a sane criterion > te decide when to apply it, you could end up with something very > complicated

Re: [sage-devel] trac seems down

It works again ! Thanks to the one who restarted the service or wrote a self-healing service ! Ciao, Thierry On Tue, Feb 28, 2017 at 06:38:57PM +0100, Thierry wrote: > Hi, > > at least from Olot, where we are having days 84, we can not reach trac > anymore. > > Ciao, > Thierry > > -- > You

[sage-devel] trac seems down

Hi, at least from Olot, where we are having days 84, we can not reach trac anymore. Ciao, Thierry -- 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] Re: integration algorithms

If it makes sense to use integration by parts or not deppends heavily on the actual expression. I suspect that, if you try to make a sane criterion te decide when to apply it, you could end up with something very complicated as well. Ther is reason why there are so many rules in RUBI (although

[sage-devel] "replacement" optional packages

Hi, having the possibility to install all optional packages is interesting for easy deployment as well as for testing (we need more automated tests of all optional packages, in particular more patchbots with optional packages installed). Currently, some optional packages, like gmp/mpir,

[sage-devel] Re: integration algorithms

Le mardi 28 février 2017 15:57:53 UTC+1, mmarco a écrit : > > Many RUBI rules actually consist on applying that kind of algorithms. The > trick with those algorithms is that sometimes they help, and sometimes they > hurt (in the sense that you get something that is actually harder to >

Re: [sage-devel] Names of special methods like _pari_

Hi, On Tue, Feb 28, 2017 at 04:41:39PM +, John Cremona wrote: > On 28 February 2017 at 16:26, Jeroen Demeyer wrote: > > This is a continuation of discussion from > > https://trac.sagemath.org/ticket/22470 > > > > I will only talk about _pari_ below but this is just an

Re: [sage-devel] Names of special methods like _pari_

On 28 February 2017 at 16:26, Jeroen Demeyer wrote: > This is a continuation of discussion from > https://trac.sagemath.org/ticket/22470 > > I will only talk about _pari_ below but this is just an example. We also > have _gap_ and others. > > Sage supports the special

[sage-devel] Names of special methods like _pari_

This is a continuation of discussion from https://trac.sagemath.org/ticket/22470 I will only talk about _pari_ below but this is just an example. We also have _gap_ and others. Sage supports the special method _pari_() to convert arbitrary objects to PARI. Now I would like to ask the

Re: [sage-devel] GSoC 2017 accepted SageMath

Harald Schilly writes: > Just got word: > >> Congratulations! Sage Mathematical Software System has been selected as a >> Google Summer of Code 2017 mentor organization. Awesome! I got a bit worried the last few days before deadline since our GSoC page was somewhat sparse :-) -- You received

[sage-devel] Re: integration algorithms

Many RUBI rules actually consist on applying that kind of algorithms. The trick with those algorithms is that sometimes they help, and sometimes they hurt (in the sense that you get something that is actually harder to integrate). One of the important things about RUBI that many people forget

Re: [sage-devel] Re: integration algorithms

Fricas does some integrals very well (also, gives more compact form, as it does not introduce as many field extensions as other packages), and some pretty badly. IMHO one first has to classify the integrals and only then choose a good backend. On Tuesday, February 28, 2017 at 9:21:35 AM UTC,

[sage-devel] Re: integration algorithms

My opinion is that it's better to add new algorithms for failures than rules. Of course adding rules will add a few success, but it's not like adding algorithms that can be combined together like integration by part and partial fraction decomposition or integration of rational fraction of x

[sage-devel] Re: integration algorithms

> > > Back to the original proposal. Certainly rules can't catch all cases > either. Doesn't this call for a combined approach? As soon as we have rules > in Sage they should be called before the best algorithm we have. The > default then IMO should be "special rules + Maxima" instead of

[sage-devel] Re: what happened to ipython?

I tried to downgrade to ipython 4.x from Sage 7.5 but there is a problem with python module prompts El lunes, 20 de febrero de 2017, 16:30:53 (UTC+1), Sébastien Labbé escribió: > > @bennigoetz reported the same problem in December 2016 : >

Re: [sage-devel] Re: integration algorithms

Assuming the Fricas implementation is as good as Axiom's, would this alone not be enough reason to make Fricas a standard package (and call it first when integrating)? On Tue, Feb 28, 2017 at 10:03 AM Dima Pasechnik wrote: > The problem with Risch "algorithm" is that's not

Re: [sage-devel] Re: integration algorithms

The problem with Risch "algorithm" is that's not very implementable. No system ever had a complete implementation; it's true that results and implementations by Manuel Bronstein (this is a memorial page, for he died 12 years

Re: [sage-devel] Re: integration algorithms

Fricas was forked from Axiom, according to https://en.wikipedia.org/wiki/Axiom_(computer_algebra_system)#History and Axiom had the complete Risch algorithm implemented. On Tue, Feb 28, 2017 at 9:01 AM Thierry Dumont wrote: > Following

[sage-devel] Re: Table of contents of the Sage reference manual

No more comments? Then would someone review that? -- 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,

Re: [sage-devel] Re: integration algorithms

Following https://en.wikipedia.org/wiki/Risch_algorithm ,the Risch algorithm is able to find an antiderivative of: x |-> x/sqrt(x^4+10*x^2-96*x-71) but not of: x |-> x/sqrt(x^4+10*x^2-96*x-72) . What can do Sage? #