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

[Jeroen Demeyer]

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 are installed by default
- which packages should be packed in the source tarball
- which --optional tags are given when doctesting
- whether a warning message is given when installing the package
- the Make rules of a package
- the automatic dependencies of a package

I think that's bordering on being too much already. So +1 to more 
metadata but -1 to inventing yet another type.


--
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: "replacement" optional packages

[Dima Pasechnik]

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 patchbots with optional packages 
> installed). Currently, some optional packages, like gmp/mpir, 
> atlas/openblas, boost/boost_cropped (what else ?) are alternatives to some 
> existing standard packages. Hence, those should not be installed when we 
> want to set up a patchbot to test optional packages (unless we want to 
> specifically test those). There is also the special case of openssl, which 
> should not be installed when openssl-dev is present on the system. 
>
> I would like to suggest to have such 
> replacement/duplicate/redundent/alternative/...  packages be tagged not as 
> 'optional' but with another word, so as to ease the selection and 
> installation of all optional packages, in order to easily provide some 
> kind of "sage-full" binaries and patchbots. I currently use a hand-made 
> list of optional packages for Sage Debian Live but it requires to be 
> updated at each release. 
>

IMHO it's something to be encoded---already encoded, right?---
in dependencies rather than in type.
So all this can be recovered by parsing dependencies.

 

>
> - What do you think about distinguish such packages to optional ones ? 
> - Which name should be given to such packages ? 
> - What are your current strategies to install all meaningful optional 
>   packages ? 
>
> 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+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] Names of special methods like _pari_

[Jeroen Demeyer]

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 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] Names of special methods like _pari_

[Jeroen Demeyer]

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 so this is *not* about those methods.



I'm not convinced, because you'll potentially break code people have
written that is not included in the Sage library.   For that
reason, I'm -1 to changing _pari_ in a backwards incompatible way.


We could always keep supporting _pari_ with deprecation, so that's not 
really an issue.


--
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: integration algorithms

[Dima Pasechnik]

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)
> which can be written very compactly if you have the right tools.
> 2.  a pattern-matching problem,  but only about 13 patterns,
> each attached to an algorithm.
> 3. a kind of Risch-like program  (prior to Risch's publications).
>
> attaching more patterns and methods to stage 2 would be plausible.
> Maybe Rubi.  
> implementing a better stage 3  (or calling FriCAS!) would be plausible too.
>
> One problem with Rubi "converted" to sympy or Maxima or    is that
> (at least in the past) it relied, in non-obvious ways, on Mathematica 
> semantics.
> This resulted in loops.  I have read in and run parts of the Rubi rule-set 
> in
> Maxima; I think dozens if not hundreds of test cases.  But this was years 
> ago.
>
> Albert Rich promised, some time ago to (auto-?) write 
>  Rubi-as-"if-then-else", 
> for consumption by other systems. Still waiting.
>
> Oh, about Slagle.
>
> His program, earlier than Moses'  viewed integration as an AI
> problem involving hill-climbing, breaking up problems into sub-problems,
> etc.
>
> 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,
>

most interesting, in practice, definite integrals are multiple and 
depending upon parameters.
and often the problem is of asymptotic nature. This makes numeric 
quadratures
almost useless.

  

> and of course the vast majority of symbolic integration problems
> (from calculus texts) can be done by almost any reasonable computer
> algebra system.
>
> The more challenging (and fun) stuff is probably apparent to anyone
> who has taken a course in complex variables/ conformal mapping/ special 
> functions.
>
> I am guess that this is not what most Sage fans have studied.
>

I would not be so sure.
 

> Probably pursuing these kinds of problems would involve mostly
> Maxima  (and FriCAS if it is there)  and maybe sympy;  though that
> last one may be wrong -- I don't follow sympy much.
>
> RJF
>
>
>
>
>
> On Tuesday, February 28, 2017 at 11:10:49 AM UTC-8, parisse wrote:
>>
>>
>>
>> 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 as well. Ther is reason why there are so many rules in RUBI 
>>> (although I heard that the author is considering reorganizing them in a 
>>> decission tree, which might simplify things to some extent).
>>>
>>
>> The only reason I could see for that number of rules is that rubi works 
>> like a student who does not want to understand "the big picture" about 
>> integration but has a fabulous memory and remembers all the integrals from 
>> all known textbooks. But perhaps I'm wrong, that's why I was asking how it 
>> cooperates with classical methods, like partial fraction decomposition or 
>> integration by part, change of variables etc. I'm just not convinced by 
>> that number of rules and the fact that some of them are not grouped in an 
>> algorithm.
>>
>

-- 
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: integration algorithms

[parisse]

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 the vast majority of symbolic integration problems
> (from calculus texts) can be done by almost any reasonable computer
> algebra system.
>
>
>
This is one reason why I said I would not try to implement something like 
rubi in Giac/Xcas : my current symbolic integrator is good enough, it's 
better to invest programming time in other areas. I'm not against adding a 
few rules, but not thousands...

-- 
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: integration algorithms

[rjf]

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 pattern-matching problem,  but only about 13 patterns,
each attached to an algorithm.
3. a kind of Risch-like program  (prior to Risch's publications).

attaching more patterns and methods to stage 2 would be plausible.
Maybe Rubi.  
implementing a better stage 3  (or calling FriCAS!) would be plausible too.

One problem with Rubi "converted" to sympy or Maxima or    is that
(at least in the past) it relied, in non-obvious ways, on Mathematica 
semantics.
This resulted in loops.  I have read in and run parts of the Rubi rule-set 
in
Maxima; I think dozens if not hundreds of test cases.  But this was years 
ago.

Albert Rich promised, some time ago to (auto-?) write 
 Rubi-as-"if-then-else", 
for consumption by other systems. Still waiting.

Oh, about Slagle.

His program, earlier than Moses'  viewed integration as an AI
problem involving hill-climbing, breaking up problems into sub-problems,
etc.

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 the vast majority of symbolic integration problems
(from calculus texts) can be done by almost any reasonable computer
algebra system.

The more challenging (and fun) stuff is probably apparent to anyone
who has taken a course in complex variables/ conformal mapping/ special 
functions.

I am guess that this is not what most Sage fans have studied.
Probably pursuing these kinds of problems would involve mostly
Maxima  (and FriCAS if it is there)  and maybe sympy;  though that
last one may be wrong -- I don't follow sympy much.

RJF





On Tuesday, February 28, 2017 at 11:10:49 AM UTC-8, parisse wrote:
>
>
>
> 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 as well. Ther is reason why there are so many rules in RUBI 
>> (although I heard that the author is considering reorganizing them in a 
>> decission tree, which might simplify things to some extent).
>>
>
> The only reason I could see for that number of rules is that rubi works 
> like a student who does not want to understand "the big picture" about 
> integration but has a fabulous memory and remembers all the integrals from 
> all known textbooks. But perhaps I'm wrong, that's why I was asking how it 
> cooperates with classical methods, like partial fraction decomposition or 
> integration by part, change of variables etc. I'm just not convinced by 
> that number of rules and the fact that some of them are not grouped in an 
> algorithm.
>

-- 
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] Names of special methods like _pari_

[David Roe]

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, 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 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 that users
>>> shouldn't need to know but something that package developers should know
>>> and can rely on. A private name like "_pari" would imply that we can
>>> remove/change it at will, which is not applicable in this case.
>>>
>>> I think this is exactly like Python's special methods such as __init__:
>>> as a user, you would normally not call these but they are very important
>>> when developing a class.
>>>
>>
>> What about _latex_? Would you plan to change that, too? Sage objects and
>> elements have lots of single-underscore methods, like _repr_, _mul_, etc.
>> The use of _pari_ could be seen as in line with all of these, so I'm not
>> sure why that choice has been rejected so quickly.
>>
>>
> What I am seeing this as is a special conversion of the underlying type
> that is essentially a system operation like __int__. So it makes a lot of
> sense to me to have __pari__ as this is not a Sage special function. We
> shouldn't touch _repr_, _mul_, etc. as these are Sage special functions
> that are redirected to from the standard Python hooks, but we would
> otherwise use __repr__, __mul__, etc. Thus, we arrive at Sage special
> functions _latex_, _ascii_art_, etc., but I see that as using that
> convention for functions that are specific to Sage. Thus, I would say (4),
> but I could live with (1).
>
> Best,
> Travis
>
> --
> 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.

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

[Travis Scrimshaw]

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 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 that users 
>> shouldn't need to know but something that package developers should know 
>> and can rely on. A private name like "_pari" would imply that we can 
>> remove/change it at will, which is not applicable in this case. 
>>
>> I think this is exactly like Python's special methods such as __init__: 
>> as a user, you would normally not call these but they are very important 
>> when developing a class. 
>>
>
> What about _latex_? Would you plan to change that, too? Sage objects and 
> elements have lots of single-underscore methods, like _repr_, _mul_, etc. 
> The use of _pari_ could be seen as in line with all of these, so I'm not 
> sure why that choice has been rejected so quickly.
>
>
What I am seeing this as is a special conversion of the underlying type 
that is essentially a system operation like __int__. So it makes a lot of 
sense to me to have __pari__ as this is not a Sage special function. We 
shouldn't touch _repr_, _mul_, etc. as these are Sage special functions 
that are redirected to from the standard Python hooks, but we would 
otherwise use __repr__, __mul__, etc. Thus, we arrive at Sage special 
functions _latex_, _ascii_art_, etc., but I see that as using that 
convention for functions that are specific to Sage. Thus, I would say (4), 
but I could live with (1).

Best,
Travis

-- 
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: "replacement" optional packages

[Travis Scrimshaw]

+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 
under common descriptions that the user could swap out by rebuilding.

Best,
Travis


On Tuesday, February 28, 2017 at 11:20:23 AM UTC-6, 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 patchbots with optional packages 
> installed). Currently, some optional packages, like gmp/mpir, 
> atlas/openblas, boost/boost_cropped (what else ?) are alternatives to some 
> existing standard packages. Hence, those should not be installed when we 
> want to set up a patchbot to test optional packages (unless we want to 
> specifically test those). There is also the special case of openssl, which 
> should not be installed when openssl-dev is present on the system. 
>
> I would like to suggest to have such 
> replacement/duplicate/redundent/alternative/...  packages be tagged not as 
> 'optional' but with another word, so as to ease the selection and 
> installation of all optional packages, in order to easily provide some 
> kind of "sage-full" binaries and patchbots. I currently use a hand-made 
> list of optional packages for Sage Debian Live but it requires to be 
> updated at each release. 
>
> - What do you think about distinguish such packages to optional ones ? 
> - Which name should be given to such packages ? 
> - What are your current strategies to install all meaningful optional 
>   packages ? 
>
> 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+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] Names of special methods like _pari_

[William Stein]

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 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 that users
>> shouldn't need to know but something that package developers should know
>> and can rely on. A private name like "_pari" would imply that we can
>> remove/change it at will, which is not applicable in this case.
>>
>> I think this is exactly like Python's special methods such as __init__:
>> as a user, you would normally not call these but they are very important
>> when developing a class.
>
>
> What about _latex_? Would you plan to change that, too? Sage objects and
> elements have lots of single-underscore methods, like _repr_, _mul_, etc.
> The use of _pari_ could be seen as in line with all of these, so I'm not
> sure why that choice has been rejected so quickly.

The subject of this thread is "Names of special methods like _pari_",
so I suspect Jeroen wants to change *everything*.

Jeroen says:
> It's just a simple search-and-replace-all, so essentially no work.

I'm not convinced, because you'll potentially break code people have
written that is not included in the Sage library.   For that
reason, I'm -1 to changing _pari_ in a backwards incompatible way.

 -- William


>
> --
> John
>
> --
> 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.



-- 
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.

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

[John H Palmieri]

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 "implementation detail" but it's not "private". 
>
> I would say it's a public implementation detail: something that users 
> shouldn't need to know but something that package developers should know 
> and can rely on. A private name like "_pari" would imply that we can 
> remove/change it at will, which is not applicable in this case. 
>
> I think this is exactly like Python's special methods such as __init__: 
> as a user, you would normally not call these but they are very important 
> when developing a class. 
>

What about _latex_? Would you plan to change that, too? Sage objects and 
elements have lots of single-underscore methods, like _repr_, _mul_, etc. 
The use of _pari_ could be seen as in line with all of these, so I'm not 
sure why that choice has been rejected so quickly.

-- 
John

-- 
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] Names of special methods like _pari_

[Jeroen Demeyer]

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 that users 
shouldn't need to know but something that package developers should know 
and can rely on. A private name like "_pari" would imply that we can 
remove/change it at will, which is not applicable in this case.


I think this is exactly like Python's special methods such as __init__: 
as a user, you would normally not call these but they are very important 
when developing a class.


--
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: Names of special methods like _pari_

[Jeroen Demeyer]

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 would leave with me the strong expectation that the advised way of
invoking this method is via pari(), which of course could work.


That's exactly right. So if it does give you that impression, that would 
be an additional reason in favour of (4).


--
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: Names of special methods like _pari_

[Jeroen Demeyer]

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 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: Names of special methods like _pari_

[Nils Bruin]

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 that the advised way of 
invoking this method is via pari(), which of course could work. It 
just  means that, for instance, gap(a) would translate to a.__gap__(G=gap) 
[in cases where there are multiple interfaces around].

I'm not sure it's an improvement. Is _pari_ so likely to clash with other 
packages? It doesn't seem any of the alternatives come out as great winners 
either, and they have their own issues. So it seems to me changing the 
names will be a lot of work with very limited actual benefit.

-- 
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] Names of special methods like _pari_

[Johan S . H . Rosenkilde]

>
> (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 use this "convert to PARI"
method through other, more publicly visible services? In that case, it
could be seen as an implementation detail that objects have the _pari
method, and private would be apt.

I think I vote for this, though my only objection to (4) is that it
possibly goes against the Python doc.

Best,
Johan

-- 
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: integration algorithms

[parisse]

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 as well. Ther is reason why there are so many rules in RUBI 
> (although I heard that the author is considering reorganizing them in a 
> decission tree, which might simplify things to some extent).
>

The only reason I could see for that number of rules is that rubi works 
like a student who does not want to understand "the big picture" about 
integration but has a fabulous memory and remembers all the integrals from 
all known textbooks. But perhaps I'm wrong, that's why I was asking how it 
cooperates with classical methods, like partial fraction decomposition or 
integration by part, change of variables etc. I'm just not convinced by 
that number of rules and the fact that some of them are not grouped in an 
algorithm.

-- 
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] trac seems down

[Thierry]

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 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] trac seems down

[Thierry]

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+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: integration algorithms

[mmarco]

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 I heard that the author is considering reorganizing them in a 
decission tree, which might simplify things to some extent).

Anyways, even if being able to run several steps of simplification->partial 
integration->further simplification-> further partial integration... would 
possibly increase the number of cases that we can integrate, the first step 
would be to have some support for simplification rules. 

El martes, 28 de febrero de 2017, 18:01:58 (UTC+1), parisse escribió:
>
>
>
> 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 
>> integrate).
>>
>> One of the important things about RUBI that many people forget about is 
>> that it not only is able to integrate more expressions than 
>> Mathematica/Maple/Maxima... (and usually does it faster), but that it also 
>> often produces "better" output (in the sense of more compact
>> expressions and/or fewer discontinuity problems). In general, each rule 
>> of RUBI turns the expression into something simpler, so even if you don't 
>> have the full set of rules, you can use the ones you have as a 
>> preprocessing step for other kinds of algorithms.
>>
>>
> But what about using them in the middle of other algorithms? Because that 
> is what you would want to do. For example if you have a generic expression 
> with an inverse trig function, then it makes sense to do integration by 
> part, and after that you might apply some nice and compact expression 
> obtained by a rule on sqrt. Or maybe you should do a partial fraction 
> decomposition somewhere. My main concern with what I looked at is that some 
> rules should be grouped in one algorithm. There are too many rules in 
> rubi...
>

-- 
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] "replacement" optional packages

[Thierry]

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,
atlas/openblas, boost/boost_cropped (what else ?) are alternatives to some
existing standard packages. Hence, those should not be installed when we
want to set up a patchbot to test optional packages (unless we want to
specifically test those). There is also the special case of openssl, which
should not be installed when openssl-dev is present on the system.

I would like to suggest to have such
replacement/duplicate/redundent/alternative/...  packages be tagged not as
'optional' but with another word, so as to ease the selection and
installation of all optional packages, in order to easily provide some
kind of "sage-full" binaries and patchbots. I currently use a hand-made
list of optional packages for Sage Debian Live but it requires to be
updated at each release.

- What do you think about distinguish such packages to optional ones ?
- Which name should be given to such packages ?
- What are your current strategies to install all meaningful optional
  packages ?

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+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: integration algorithms

[parisse]

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 
> integrate).
>
> One of the important things about RUBI that many people forget about is 
> that it not only is able to integrate more expressions than 
> Mathematica/Maple/Maxima... (and usually does it faster), but that it also 
> often produces "better" output (in the sense of more compact
> expressions and/or fewer discontinuity problems). In general, each rule of 
> RUBI turns the expression into something simpler, so even if you don't have 
> the full set of rules, you can use the ones you have as a preprocessing 
> step for other kinds of algorithms.
>
>
But what about using them in the middle of other algorithms? Because that 
is what you would want to do. For example if you have a generic expression 
with an inverse trig function, then it makes sense to do integration by 
part, and after that you might apply some nice and compact expression 
obtained by a rule on sqrt. Or maybe you should do a partial fraction 
decomposition somewhere. My main concern with what I looked at is that some 
rules should be grouped in one algorithm. There are too many rules in 
rubi...

-- 
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] Names of special methods like _pari_

[Thierry]

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 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 question whether _pari_() is really the
> > best name. Especially if we want Sage to fit better in a larger Python
> > ecosystem, it makes sense to think about this.
> >
> >
> > We essentially have 5 options:
> 
> Must the name be just 'pari' with some number of underscores?  As this
> is an explicit conversion, something like (6) to_pari() would seem OK
> to me.

I am -1 for (5) and (6) since it will pollute autocompletion on every Sage
object.

Ciao,
Thierry


> 
> >
> > (1) _pari_(): the status-quo. This seems to be very Sage-specific, I don't
> > know if this naming convention is used anywhere else.
> >
> > (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.
> >
> > (3) __pari(): even more private with mangling, so even less suitable.
> >
> > (4) __pari__(): consistent with Python (__int__, __str__) and NumPy
> > (__array__). However, creating such names possibly goes against the Python
> > documentation [2].
> >
> > (5) pari(): very simple but it doesn't make it clear that it has a special
> > meaning. Higher chance of false positives with people using a pari() method
> > for something else.
> >
> >
> > My personal choice would be (4). Since this seems to be a controversial
> > topic, I decided to write this sage-devel post.
> >
> >
> > There is some discussion about naming in these two references:
> > [1] https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles
> > [2]
> > https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers
> >
> > but neither seems to answer what is the right thing to do for our use case.
> >
> >
> > 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 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.

-- 
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] Names of special methods like _pari_

[John Cremona]

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 method _pari_() to convert arbitrary objects to
> PARI. Now I would like to ask the question whether _pari_() is really the
> best name. Especially if we want Sage to fit better in a larger Python
> ecosystem, it makes sense to think about this.
>
>
> We essentially have 5 options:

Must the name be just 'pari' with some number of underscores?  As this
is an explicit conversion, something like (6) to_pari() would seem OK
to me.

>
> (1) _pari_(): the status-quo. This seems to be very Sage-specific, I don't
> know if this naming convention is used anywhere else.
>
> (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.
>
> (3) __pari(): even more private with mangling, so even less suitable.
>
> (4) __pari__(): consistent with Python (__int__, __str__) and NumPy
> (__array__). However, creating such names possibly goes against the Python
> documentation [2].
>
> (5) pari(): very simple but it doesn't make it clear that it has a special
> meaning. Higher chance of false positives with people using a pari() method
> for something else.
>
>
> My personal choice would be (4). Since this seems to be a controversial
> topic, I decided to write this sage-devel post.
>
>
> There is some discussion about naming in these two references:
> [1] https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles
> [2]
> https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers
>
> but neither seems to answer what is the right thing to do for our use case.
>
>
> 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 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] Names of special methods like _pari_

[Jeroen Demeyer]

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 question whether _pari_() is really 
the best name. Especially if we want Sage to fit better in a larger 
Python ecosystem, it makes sense to think about this.



We essentially have 5 options:

(1) _pari_(): the status-quo. This seems to be very Sage-specific, I 
don't know if this naming convention is used anywhere else.


(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.


(3) __pari(): even more private with mangling, so even less suitable.

(4) __pari__(): consistent with Python (__int__, __str__) and NumPy 
(__array__). However, creating such names possibly goes against the 
Python documentation [2].


(5) pari(): very simple but it doesn't make it clear that it has a 
special meaning. Higher chance of false positives with people using a 
pari() method for something else.



My personal choice would be (4). Since this seems to be a controversial 
topic, I decided to write this sage-devel post.



There is some discussion about naming in these two references:
[1] https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles
[2] 
https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers


but neither seems to answer what is the right thing to do for our use case.


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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] GSoC 2017 accepted SageMath

[Johan S . H . Rosenkilde]

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 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: integration algorithms

[mmarco]

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 about is 
that it not only is able to integrate more expressions than 
Mathematica/Maple/Maxima... (and usually does it faster), but that it also 
often produces "better" output (in the sense of more compact
expressions and/or fewer discontinuity problems). In general, each rule of 
RUBI turns the expression into something simpler, so even if you don't have 
the full set of rules, you can use the ones you have as a preprocessing 
step for other kinds of algorithms.

El martes, 28 de febrero de 2017, 11:14:13 (UTC+1), parisse escribió:
>
> 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 
> and sqrt(polynomial of degree 2). But perhaps I misunderstand Rubi, and it 
> does that inside Mathematica?
>
> Le mardi 28 février 2017 10:50:50 UTC+1, mmarco a écrit :
>>
>>
>>> 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 Maxima alone.
>>>
>>> Regards, 
>>>
>>
>> I agree with that approach, specially because it allows adding rules 
>> incrementally. Even if we don't have all the set of RUBI rules, having a 
>> few of them could be an improvement.
>>
>

-- 
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: integration algorithms

[Dima Pasechnik]

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, Ralf Stephan wrote:
>
> 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 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 ago),
>> who authored a lot of results towards making Risch more practical, are 
>> most completely represented in Axiom.
>>
>>
>>
>> On Tuesday, February 28, 2017 at 8:45:27 AM UTC, Ralf Stephan wrote:
>>
>>> 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 <
>>> tdu...@math.univ-lyon1.fr> wrote:
>>>
>> 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?

 #
 fok(x)=x/sqrt(x^4+10*x^2-96*x-71)
 fnot_ok(x)=x/sqrt(x^4+10*x^2-96*x-72)
 #
 algs=["maxima","sympy","fricas"]
 #
 for alg in algs:
 print alg,integral(fok,x,algorithm=alg)
 #
 for alg in algs:
 print alg,integral(fnot_ok,x,algorithm=alg)
 #-

 For fnot_ok no primitive is found (may be an other algorithm could find
 it -it exists in terms of elliptic integrals-)

 For f_ok, *only*  *fricas* finds the primitive:

 maxima x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
 sympy x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
 fricas x |--> 1/8*log(x^8 + 20*x^6 - 128*x^5 + 54*x^4 - 1408*x^3 +
 3124*x^2 + (x^6 + 15*x^4 - 80*x^3 + 27*x^2 - 528*x + 781)*sqrt(x^4 +
 10*x^2 - 96*x - 71) + 10001)

 The wikipedia paper says that Risch algorithm was implemented in Macsyma
 (and thus I think in maxima!). So, iffricas and maxima use Risch
 algorithm, the implementation in fricas is better, or may be fricas uses
 some other method.

 What about maple and mathematica ? As far as I remember maple can
 integrate f_ok. I have no more access to maple to look at this :-) .

 t.



 --
 You received this message because you are subscribed to a topic in the 
 Google Groups "sage-devel" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/sage-devel/7OO_VyMC1Ts/unsubscribe.

>>> To unsubscribe from this group and all its topics, send an email to 
 sage-devel+...@googlegroups.com.
 To post to this group, send email to sage-...@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 a topic in the 
>> Google Groups "sage-devel" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/sage-devel/7OO_VyMC1Ts/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> sage-devel+...@googlegroups.com .
>> To post to this group, send email to sage-...@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] Re: integration algorithms

[parisse]

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 
and sqrt(polynomial of degree 2). But perhaps I misunderstand Rubi, and it 
does that inside Mathematica?

Le mardi 28 février 2017 10:50:50 UTC+1, mmarco a écrit :
>
>
>> 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 Maxima alone.
>>
>> Regards, 
>>
>
> I agree with that approach, specially because it allows adding rules 
> incrementally. Even if we don't have all the set of RUBI rules, having a 
> few of them could be an improvement.
>

-- 
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: integration algorithms

[mmarco]

>
>
> 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 Maxima alone.
>
> Regards, 
>

I agree with that approach, specially because it allows adding rules 
incrementally. Even if we don't have all the set of RUBI rules, having a 
few of them could be an improvement.

-- 
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: what happened to ipython?

[Enrique Artal]

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 :
> https://github.com/ipython/ipython/issues/9816#issuecomment-258242213
>
> For now, the only solution seems to go back to IPython 4.x ...
>
>

-- 
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: integration algorithms

[Ralf Stephan]

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 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 ago),
> who authored a lot of results towards making Risch more practical, are
> most completely represented in Axiom.
>
>
>
> On Tuesday, February 28, 2017 at 8:45:27 AM UTC, Ralf Stephan wrote:
>
> 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 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?
>
> #
> fok(x)=x/sqrt(x^4+10*x^2-96*x-71)
> fnot_ok(x)=x/sqrt(x^4+10*x^2-96*x-72)
> #
> algs=["maxima","sympy","fricas"]
> #
> for alg in algs:
> print alg,integral(fok,x,algorithm=alg)
> #
> for alg in algs:
> print alg,integral(fnot_ok,x,algorithm=alg)
> #-
>
> For fnot_ok no primitive is found (may be an other algorithm could find
> it -it exists in terms of elliptic integrals-)
>
> For f_ok, *only*  *fricas* finds the primitive:
>
> maxima x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
> sympy x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
> fricas x |--> 1/8*log(x^8 + 20*x^6 - 128*x^5 + 54*x^4 - 1408*x^3 +
> 3124*x^2 + (x^6 + 15*x^4 - 80*x^3 + 27*x^2 - 528*x + 781)*sqrt(x^4 +
> 10*x^2 - 96*x - 71) + 10001)
>
> The wikipedia paper says that Risch algorithm was implemented in Macsyma
> (and thus I think in maxima!). So, iffricas and maxima use Risch
> algorithm, the implementation in fricas is better, or may be fricas uses
> some other method.
>
> What about maple and mathematica ? As far as I remember maple can
> integrate f_ok. I have no more access to maple to look at this :-) .
>
> t.
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/7OO_VyMC1Ts/unsubscribe.
>
> To unsubscribe from this group and all its topics, send an email to
> sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@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 a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/7OO_VyMC1Ts/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

Re: [sage-devel] Re: integration algorithms

[Dima Pasechnik]

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 ago),
who authored a lot of results towards making Risch more practical, are most 
completely represented in Axiom.



On Tuesday, February 28, 2017 at 8:45:27 AM UTC, Ralf Stephan wrote:
>
> 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 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?
>>
>> #
>> fok(x)=x/sqrt(x^4+10*x^2-96*x-71)
>> fnot_ok(x)=x/sqrt(x^4+10*x^2-96*x-72)
>> #
>> algs=["maxima","sympy","fricas"]
>> #
>> for alg in algs:
>> print alg,integral(fok,x,algorithm=alg)
>> #
>> for alg in algs:
>> print alg,integral(fnot_ok,x,algorithm=alg)
>> #-
>>
>> For fnot_ok no primitive is found (may be an other algorithm could find
>> it -it exists in terms of elliptic integrals-)
>>
>> For f_ok, *only*  *fricas* finds the primitive:
>>
>> maxima x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
>> sympy x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
>> fricas x |--> 1/8*log(x^8 + 20*x^6 - 128*x^5 + 54*x^4 - 1408*x^3 +
>> 3124*x^2 + (x^6 + 15*x^4 - 80*x^3 + 27*x^2 - 528*x + 781)*sqrt(x^4 +
>> 10*x^2 - 96*x - 71) + 10001)
>>
>> The wikipedia paper says that Risch algorithm was implemented in Macsyma
>> (and thus I think in maxima!). So, iffricas and maxima use Risch
>> algorithm, the implementation in fricas is better, or may be fricas uses
>> some other method.
>>
>> What about maple and mathematica ? As far as I remember maple can
>> integrate f_ok. I have no more access to maple to look at this :-) .
>>
>> t.
>>
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "sage-devel" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/sage-devel/7OO_VyMC1Ts/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> sage-devel+...@googlegroups.com .
>> To post to this group, send email to sage-...@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.

Re: [sage-devel] Re: integration algorithms

[Ralf Stephan]

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 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?
>
> #
> fok(x)=x/sqrt(x^4+10*x^2-96*x-71)
> fnot_ok(x)=x/sqrt(x^4+10*x^2-96*x-72)
> #
> algs=["maxima","sympy","fricas"]
> #
> for alg in algs:
> print alg,integral(fok,x,algorithm=alg)
> #
> for alg in algs:
> print alg,integral(fnot_ok,x,algorithm=alg)
> #-
>
> For fnot_ok no primitive is found (may be an other algorithm could find
> it -it exists in terms of elliptic integrals-)
>
> For f_ok, *only*  *fricas* finds the primitive:
>
> maxima x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
> sympy x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
> fricas x |--> 1/8*log(x^8 + 20*x^6 - 128*x^5 + 54*x^4 - 1408*x^3 +
> 3124*x^2 + (x^6 + 15*x^4 - 80*x^3 + 27*x^2 - 528*x + 781)*sqrt(x^4 +
> 10*x^2 - 96*x - 71) + 10001)
>
> The wikipedia paper says that Risch algorithm was implemented in Macsyma
> (and thus I think in maxima!). So, iffricas and maxima use Risch
> algorithm, the implementation in fricas is better, or may be fricas uses
> some other method.
>
> What about maple and mathematica ? As far as I remember maple can
> integrate f_ok. I have no more access to maple to look at this :-) .
>
> t.
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/7OO_VyMC1Ts/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: Table of contents of the Sage reference manual

[Kwankyu Lee]

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, 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: integration algorithms

[Thierry Dumont]

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?

#
fok(x)=x/sqrt(x^4+10*x^2-96*x-71)
fnot_ok(x)=x/sqrt(x^4+10*x^2-96*x-72)
#
algs=["maxima","sympy","fricas"]
#
for alg in algs:
print alg,integral(fok,x,algorithm=alg)
#
for alg in algs:
print alg,integral(fnot_ok,x,algorithm=alg)
#-

For fnot_ok no primitive is found (may be an other algorithm could find
it -it exists in terms of elliptic integrals-)

For f_ok, *only*  *fricas* finds the primitive:

maxima x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
sympy x |--> integrate(x/sqrt(x^4 + 10*x^2 - 96*x - 71), x)
fricas x |--> 1/8*log(x^8 + 20*x^6 - 128*x^5 + 54*x^4 - 1408*x^3 +
3124*x^2 + (x^6 + 15*x^4 - 80*x^3 + 27*x^2 - 528*x + 781)*sqrt(x^4 +
10*x^2 - 96*x - 71) + 10001)

The wikipedia paper says that Risch algorithm was implemented in Macsyma
(and thus I think in maxima!). So, iffricas and maxima use Risch
algorithm, the implementation in fricas is better, or may be fricas uses
some other method.

What about maple and mathematica ? As far as I remember maple can
integrate f_ok. I have no more access to maple to look at this :-) .

t.



-- 
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.
<>