[sage-devel] Re: integration algorithms

[parisse]

Le mercredi 1 mars 2017 22:58:48 UTC+1, rjf a écrit :
>
> As I have said before, the objective of most students taking calculus
> is to pass the course so they never have to know any of this integration
> stuff ever again.  Thus computer systems are useful primarily to
> help them do homework (cheat?).  And for this work, Maxima is probably
> sufficient.
>
>
> A reasonable CAS on a smartphone/tablet/calculator is sufficient for 
students learning calculus (at some point geogebra will certainly provide 
the CAS window on their app). Otherwise I believe that more symbolic 
integration is essentially interesting for benchmarks (beware that they may 
be biaised) and to make regression tests (compare output and check that the 
derivative of the antiderivative is the original function).

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

Is "scientist" a job?

see US statistics here
https://www.bls.gov/ooh/

There are 780 hits on "scientist".

The occupational outlook for "mathematician" 
https://www.bls.gov/ooh/math/mathematicians.htm
is informative.

The number of persons in this category (in 2014)  was 3,500.

computer scientists, 25,600.

dental hygienist 200,500.  

I have suggested to people that if they want to make money writing programs,
they should not have as a target audience "mathematicians".
Maybe they should pick some other occupation, e.g.  dental hygienists.

RJF

 

-- 
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 9:58:48 PM UTC, rjf wrote:
>
> I think that if *students *are using Sage to access the integration 
> program in Maxima, they could just
> use Maxima.
>
> If they are choosing an integration program based on speed,
> they must have a very very old computer, since almost any student
> problem is done instantly. By almost any program.
>
> Implementing Rubi is certainly feasible. "Converting" the Mathematica code
> to python means writing a pattern matching program that parses the Rubi
> code in python.  And figuring out what simplifications are inherent in it.
> There is already such a pattern matching program in Lisp, so doing it
> in python is not actually necessary.  But maybe someone has done
> it anyway. Who can be sure?
>
> As I have said before, the objective of most students taking calculus
> is to pass the course so they never have to know any of this integration
> stuff ever again.  Thus computer systems are useful primarily to
> help them do homework (cheat?).  And for this work, Maxima is probably
> sufficient.
>
> Learning to do symbolic integration "by hand" is a useful test of
> "can you do algebra".  Beyond that, it's not really a vital part of
> most occupations in say, engineering.  The only job that I
> can think of that really requires knowledge of these methods is
> "calculus teacher".  
>

Is "scientist" a job? If yes, then, well, perhaps you can have a look at 
papers on analysis of algorithms. E.g.
your humble servant had fun with integration (by hand or otherwise) here:
https://link.springer.com/article/10.1023/B:JOCO.038911.67280.3f
(https://pure.uvt.nl/ws/files/623688/onapprox.pdf)---Appendix 1 and 
Appendix 2.



 

>
>
>
>
> On Wednesday, March 1, 2017 at 11:13:38 AM UTC-8, saad khalid wrote:
>>
>> I think Sage's integration can't compare to Mathematica's. The output is 
>> not as clean and it doesn't solve as many integrals and it is not as fast. 
>> Sage is used by many students, and in my opinion, its profitability and 
>> sustainability in the future depends on classroom use, to a large extent. 
>> For that reason alone, I think it is worthwhile to make integration cleaner 
>> and better, as that is what the majority of students do. I'm not sure what 
>> the  qualm against adding thousands of rules is. If it's more efficient and 
>> effective, why does it matter if its similar to a student who simply 
>> "memorizes the formulas." Also, saying that we can integrate better than 
>> mathematica is definitely a solid advertising point. 
>>
>> My main question is why this is so difficult to implement. Is the 
>> difficulty in implementing the "if-then-else"/binary-search-tree method? Or 
>> is it with converting the mathematica code to python? I have a hard time 
>> believing it's the latter. It's just that several people have said now that 
>> implementing Rubi is unfeasible, and I don't totally understand why. Could 
>> someone clarify this for me?
>>
>

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

I think that if *students *are using Sage to access the integration program 
in Maxima, they could just
use Maxima.

If they are choosing an integration program based on speed,
they must have a very very old computer, since almost any student
problem is done instantly. By almost any program.

Implementing Rubi is certainly feasible. "Converting" the Mathematica code
to python means writing a pattern matching program that parses the Rubi
code in python.  And figuring out what simplifications are inherent in it.
There is already such a pattern matching program in Lisp, so doing it
in python is not actually necessary.  But maybe someone has done
it anyway. Who can be sure?

As I have said before, the objective of most students taking calculus
is to pass the course so they never have to know any of this integration
stuff ever again.  Thus computer systems are useful primarily to
help them do homework (cheat?).  And for this work, Maxima is probably
sufficient.

Learning to do symbolic integration "by hand" is a useful test of
"can you do algebra".  Beyond that, it's not really a vital part of
most occupations in say, engineering.  The only job that I
can think of that really requires knowledge of these methods is
"calculus teacher".  




On Wednesday, March 1, 2017 at 11:13:38 AM UTC-8, saad khalid wrote:
>
> I think Sage's integration can't compare to Mathematica's. The output is 
> not as clean and it doesn't solve as many integrals and it is not as fast. 
> Sage is used by many students, and in my opinion, its profitability and 
> sustainability in the future depends on classroom use, to a large extent. 
> For that reason alone, I think it is worthwhile to make integration cleaner 
> and better, as that is what the majority of students do. I'm not sure what 
> the  qualm against adding thousands of rules is. If it's more efficient and 
> effective, why does it matter if its similar to a student who simply 
> "memorizes the formulas." Also, saying that we can integrate better than 
> mathematica is definitely a solid advertising point. 
>
> My main question is why this is so difficult to implement. Is the 
> difficulty in implementing the "if-then-else"/binary-search-tree method? Or 
> is it with converting the mathematica code to python? I have a hard time 
> believing it's the latter. It's just that several people have said now that 
> implementing Rubi is unfeasible, and I don't totally understand why. Could 
> someone clarify this for me?
>

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

[rjf]

Maxima's version of Risch is about 13 pages of code, not counting some
material that may reside in other files having to do with finding 
appropriate
algebraic or transcendental extensions.  I suspect no one has looked at
it seriously in 40 years.




On Wednesday, March 1, 2017 at 1:26:04 PM UTC-8, heb...@math.uni.wroc.pl 
wrote:
>
>
>
> W dniu wtorek, 28 lutego 2017 09:03:52 UTC użytkownik Dima Pasechnik 
> napisał:
>>
>> 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.
>>
>  
> In 2006 Axiom had "most complete" implementation.  But there were several 
> holes.  Some missing parts
> are implemented in FriCAS and there are extensions.  Currently more than 
> 25% of integration code in
> FriCAS is new.  AFAIK FriCAS is the only system which can reasonably claim 
> to have full implementation
> of transcendental part of Risch algorithm.  To complete what was in Axiom 
> I had to add a sizable subsytem
> to integration code.  Testing seem to indicate that commercial competion 
> (Maple and Mathematica) did
> not implement this part.  Maxima has part called Risch, but AFAIK this is 
> heuristic using ideas from
> early Risch papers (part may be original).  AFAIK Maxima Risch misses most 
> of what is now considered
> Risch algorithm.  To get some idea of scope of various implementations you 
> may wish to look at
> examples on:
> http://axiom-wiki.newsynthesis.org/FriCASIntegration
> or at FriCAS integration test suite:
> https://sourceforge.net/p/fricas/code/HEAD/tree/trunk/src/input/integ.input
>
> You may be also interested in extensions of Risch algorithm to special 
> functions:
> http://www.math.uni.wroc.pl/~hebisch/other/icms.pdf
>

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

[hebisch]

W dniu wtorek, 28 lutego 2017 09:03:52 UTC użytkownik Dima Pasechnik 
napisał:
>
> 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.
>
 
In 2006 Axiom had "most complete" implementation.  But there were several 
holes.  Some missing parts
are implemented in FriCAS and there are extensions.  Currently more than 
25% of integration code in
FriCAS is new.  AFAIK FriCAS is the only system which can reasonably claim 
to have full implementation
of transcendental part of Risch algorithm.  To complete what was in Axiom I 
had to add a sizable subsytem
to integration code.  Testing seem to indicate that commercial competion 
(Maple and Mathematica) did
not implement this part.  Maxima has part called Risch, but AFAIK this is 
heuristic using ideas from
early Risch papers (part may be original).  AFAIK Maxima Risch misses most 
of what is now considered
Risch algorithm.  To get some idea of scope of various implementations you 
may wish to look at
examples on:
http://axiom-wiki.newsynthesis.org/FriCASIntegration
or at FriCAS integration test suite:
https://sourceforge.net/p/fricas/code/HEAD/tree/trunk/src/input/integ.input

You may be also interested in extensions of Risch algorithm to special 
functions:
http://www.math.uni.wroc.pl/~hebisch/other/icms.pdf

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

[Paul Ivanov]

On Wed, Mar 1, 2017 at 11:52 AM, Paul Ivanov  wrote:

> I've opened an IPython issue for this. I've been avoiding using IPython 5
> for similar reasons (or grudgingly using it without my precious .inputrc vi
> mode), because I though I was one of a small minority, but I think enough
> people are affected by such issues that we should considering bringing back
> the original code.
>

Sorry, here's a link to the issue:
 https://github.com/ipython/ipython/issues/10364


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

[Paul Ivanov]

I've opened an IPython issue for this. I've been avoiding using IPython 5
for similar reasons (or grudgingly using it without my precious .inputrc vi
mode), because I though I was one of a small minority, but I think enough
people are affected by such issues that we should considering bringing back
the original code.

On Tue, Feb 28, 2017 at 1:46 AM, Enrique Artal 
wrote:

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



-- 
   _
  / \
A*   \^   -
 ,./   _.`\\ / \
/ ,--.S\/   \
   /  `"~,_ \\
 __o   ?
   _ \<,_ /:\
--(_)/-(_).../ | \
--...J
Paul Ivanov
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

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

[saad khalid]

I think Sage's integration can't compare to Mathematica's. The output is 
not as clean and it doesn't solve as many integrals and it is not as fast. 
Sage is used by many students, and in my opinion, its profitability and 
sustainability in the future depends on classroom use, to a large extent. 
For that reason alone, I think it is worthwhile to make integration cleaner 
and better, as that is what the majority of students do. I'm not sure what 
the  qualm against adding thousands of rules is. If it's more efficient and 
effective, why does it matter if its similar to a student who simply 
"memorizes the formulas." Also, saying that we can integrate better than 
mathematica is definitely a solid advertising point. 

My main question is why this is so difficult to implement. Is the 
difficulty in implementing the "if-then-else"/binary-search-tree method? Or 
is it with converting the mathematica code to python? I have a hard time 
believing it's the latter. It's just that several people have said now that 
implementing Rubi is unfeasible, and I don't totally understand why. Could 
someone clarify this for me?

-- 
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-03-01 18:27, Nils Bruin wrote:

you might want to look
for precedents of implementations that use that naming conventions for
protocols that are only supported by add-on libraries


NumPy is an example: it specifies a special method .__array__(). So at 
least we would be in good company with .__pari__().



In fact, using something other than "_pari_" could be advantageous:
you can tweak the API of pyri until you hit 1.0


I don't need to change any API. I want to split of src/sage/libs/cypari2 
as a separate package called CyPari2, without changing any API.



It does seem to me that your desire to choose a different name


I don't have a particular desire to *change* the name. I want to decide 
on the best name to use. And I don't want to keep the name just because 
that is the status-quo.


And of course, I will think of backwards-compatibility.

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

[Nils Bruin]

On Wednesday, March 1, 2017 at 2:59:07 AM UTC-8, Jeroen Demeyer wrote:
>
>
> No, you are misunderstanding. There is absolutely nothing Sage-specific 
> about _pari_. In fact, I started this discussion because we would like 
> to split up the PARI interface as a different package, independent from 
> Sage. And the Sage convention _pari_ would not make much sense then. 
>
> Well, it is in fact sage-specific at the moment. However, what you're 
proposing is that an independent package (pyri?) would be spun off. It 
looks to me that the renaming should (at least initially) be limited to 
that package. Essentially this package would introduce a new protocol 
(conversion from/to the pari library) and third party classes can 
participate in this protocol by implementing a "_pari_"/"__pari__" method. 
Using "__pari__" seems reasonable, but you might want to look for 
precedents of implementations that use that naming conventions for 
protocols that are only supported by add-on libraries (most such protocols 
I know of, like "iterator", are supported by python out of the box).

If you go with "__pari__" then objects in sage (at least for the time 
being) would have "_pari_" as an alias, for compatibility reasons, but that 
has little to do with pyri.

In fact, using something other than "_pari_" could be advantageous: you can 
tweak the API of pyri until you hit 1.0 and we'll have the namespace room 
in sage to put the appropriate shim between "_pari_" and your chosen 
protocol method name.

It does seem to me that your desire to choose a different name is mainly 
driven by the fact that the pari interface is spun off, which is not the 
case for other interfaces at the moment. So I think it makes most sense to 
limit the discussion to just the pari interface.

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

[Daniel Krenn]

On 2017-02-28 17:26, Jeroen Demeyer wrote:
> (4) __pari__(): consistent with Python (__int__, __str__) and NumPy
> (__array__). However, creating such names possibly goes against the
> Python documentation [2].

If we change it, then +1 for option (4).

Daniel

-- 
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] Experimental package gap3 installation broken

[Dima Pasechnik]

On Wednesday, March 1, 2017 at 9:48:19 AM UTC, Christian Stump wrote:
>
> Dear Jeroen,
>
> > This was broken in #20692, the "cd src" should NOT have been removed: 
>
> thanks for spotting, I created ticket #22480 
> .
>

and fixed, please review 

>
> Christian
> 
>

-- 
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] MPIR-3.0.0 released

['Bill Hart' via sage-devel]

Hi all,

We have just released MPIR-3.0.0.

http://mpir.org/

Note that you now need to have the latest yasm to build MPIR.

http://yasm.tortall.net/

To build yasm, download the tarball:

./configure
make

To test MPIR, download the tarball:

./configure --enable-gmpcompat --with-yasm=/path_to_yasm/yasm
make
make check

Major changes in MPIR-3.0.0 are:

* Separate yasm from MPIR build (use --with-yasm=/path_to_yasm/yasm with
MPIR's configure, or install yasm systemwide if you prefer)
* New Intel Skylake assembly support due to Jens Nurmann, Alex Kruppa and
GMP
* New Intel Haswell assembly support due to Alex Kruppa and GMP
* Rudimentary Broadwell support (no optimisation)
* Improved AMD Bulldozer support due to Alex Kruppa
* Faster mpz_powm, mpz_powm_ui from GMP
* New mpz_limbs functionality from GMP 6
* New mpn_sizeinbase, mullow_n_basecase, binvert, redc_1, redc_2, redc_n
functions from GMP
* New mpn_nsumdiff_n function (speeds up FFT on haswell)
* Visual Studio 2017 support due to Brian Gladman
* mpir.net for interface to .net languages due to Alex Dyachenko
* Appveyor-CI support
* GMP 6 compatibility
* Numerous bug fixes

Known issues with the 3.0.0 release:

* No Intel Broadwell optimisation [1]
* No Intel Kaby Lake support [2]
* No AMD Steamroller support [3]
* No AMD Excavator support [4]
* No ARM64 support [5]
* No ARM-UWP support [6]
* New GMP 6.1 functionality not fully supported [7, 8]
* Tuning values for many architectures missing [9]
* Fat binary not available on OSX [10]

As all MPIR funding has now run out, MPIR is again maintained by community
volunteers. Patches in the form of complete GitHub Pull Requests are very
welcome.

This release of MPIR was supported in part by the OpenDreamKit EU
Horizon2020 grant. In particular, Alex Best and Alex Kruppa wrote an
assembly superoptimiser which has been used to superoptimise for some of
the above architectures.

The main contributors to this release were:

   Alex Best, Alex Kruppa, Brian Gladman, Jens Nurmann, Alex Dyachenko, JP
   Flori, Isuru Fernando, William Hart

As usual we would also like to acknowledge the GMP developers for their
indirect contribution through the official GNU project, and numerous others
who submitted tuning values, bug fixes or bug reports, including:

   Tommy Hofmann, Averkhaturau, Marcell Keller, Sergey Taymanov, sav-ix
(Alexander), jengelh

Thanks to William Stein for providing access to a Bulldozer machine.

Bill.
[1] https://github.com/wbhart/mpir/issues/198
[2] https://github.com/wbhart/mpir/issues/199
[3] https://github.com/wbhart/mpir/issues/200
[4] https://github.com/wbhart/mpir/issues/201
[5] https://github.com/wbhart/mpir/issues/108
[6] https://github.com/wbhart/mpir/issues/177
[7] https://github.com/wbhart/mpir/issues/191
[8] https://github.com/wbhart/mpir/issues/190
[9] https://github.com/wbhart/mpir/issues/194
[10] https://github.com/wbhart/mpir/issues/212

-- 
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-03-01 11:47, Simon King wrote:

I don't think they are that much different in spirit. In all cases,
the single underscore methods are for implementing functionality
in a Sage-specific way


No, you are misunderstanding. There is absolutely nothing Sage-specific 
about _pari_. In fact, I started this discussion because we would like 
to split up the PARI interface as a different package, independent from 
Sage. And the Sage convention _pari_ would not make much sense then.


On the other hand, _repr_ or _mul_ are only defined for subclasses of 
SageObject, so therefore they are Sage-specific.



a "visible" one (.pari())
in the case of _pari_


There is no such thing as a .pari() method. Maybe you are confusing with 
the pari() global function? But then I would argue that the situation is 
very similar to str or int: Python has global functions str() and int() 
calling .__str__() and .__int__() methods. Which is *exactly* analogous 
as what pari() does: it currently calls a ._pari_() method. Given the 
analogy I just explained, this should be changed to .__pari__().


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

[Simon King]

Hi Jeroen,

On 2017-03-01, Jeroen Demeyer  wrote:
>> 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 don't think they are that much different in spirit. In all cases,
the single underscore methods are for implementing functionality
in a Sage-specific way, instead of overriding a Python method: A
magical one (.__repr__()) in the case of _repr_, a "visible" one (.pari())
in the case of _pari_, similar _latex_ etc.

I think that's a very clear and easy-to-recall scheme, and therefore
I don't see the point of changing _foo_ into to_foo for foo in ["pari",
"latex", "gap"].

Cheers,
Simon

-- 
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] Integral is divergent (playing with floor and ceil)

[Peleg Michaeli]

Hi,

I have two questions, one might be thought of as a bug report / feature 
request, please tell me what you think. Trying
integrate(x, x, 0, infinity)
raises ValueError: Integral is divergent.

My first question: why it does not simply return infinity? (it does, by the 
way, if one chooses algorithm='sympy')

Now, trying
integrate(ceil(x), x, 0, infinity)
returns something weird:
limit(1/2*(2*x + 1)*ceil(x) - 1/2*ceil(x)^2, x, +Infinity, minus)
and trying to evaluate it with `.n()` raises TypeError.

My second question: why it does not return infinity / raises ValueError: 
Integral is divergent..?

And now, two more observations, which are certainly bugs:

Bug 1: running
integrate(ceil(x), x, 0, infinity, algorithm='sympy')
raises AttributeError: 'module' object has no attribute 'ceiling'. I am not 
sure, but I think that the problem is that in sympy there's no `ceil` but 
rather `ceiling`.

Bug 2: running
integrate(floor(x), x, 0, infinity, algorithm='sympy')
returns
integrate(floor(x), x, 0, +Infinity)
and trying to evaluate it with `.n()` returns (!!)
-679.7441466712775

Should I open 2 tickets for these last two bugs?


Thanks,
Peleg.





-- 
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] Experimental package gap3 installation broken

[Christian Stump]

Dear Jeroen,

> This was broken in #20692, the "cd src" should NOT have been removed: 

thanks for spotting, I created ticket #22480 
.

Christian


-- 
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] Experimental package gap3 installation broken

[Jeroen Demeyer]

This was broken in #20692, the "cd src" should NOT have been removed:


diff --git a/build/pkgs/gap3/spkg-install b/build/pkgs/gap3/spkg-install
index a91ab6f..cf76e22 100755
--- a/build/pkgs/gap3/spkg-install
+++ b/build/pkgs/gap3/spkg-install
@@ -17,20 +17,6 @@ echo "GAP3_DIR = $GAP3_DIR"
 echo "INSTALL_DIR = $INSTALL_DIR"

 ###
-## MODIFY UPSTREAM
-###
-
-cd src
-for patch in ../patches/*.patch; do
-[ -r "$patch" ] || continue  # Skip non-existing or non-readable 
patches

-patch -p1 <"$patch"
-if [ $? -ne 0 ]; then
-echo >&2 "Error applying '$patch'"
-exit 1
-fi
-done
-
-###
 ## INSTALLATION
 ###


--
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] Experimental package gap3 installation broken

[Christian Stump]

Hi,

on 7.5.beta3, I can still install without problems the experimental package 
GAP3 after deleting the upstream tarball. I then created a second copy of 
sage with the (now almost) newest development version 7.6.beta4. When 
trying to install the package there, I get the following error:

Makefile:1736: recipe for target 
'/home/stumpc5/Programs/sage-git/local/var/lib/sage/installed/gap3-jm5-2015-02-01'
 
failed
make[1]: *** 
[/home/stumpc5/Programs/sage-git/local/var/lib/sage/installed/gap3-jm5-2015-02-01]
 
Error 1
make[1]: Leaving directory '/home/stumpc5/Programs/sage-git/build/make'

(More details in the attached log file.)

What am I doing wrong / what causes this problem ?

Thanks for your help!

Christian

-- 
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.
Found local metadata for gap3-jm5-2015-02-01
Attempting to download package gap3-jm5-2015-02-01.tar.gz from mirrors
http://mirror.switch.ch/mirror/sagemath/spkg/upstream/gap3/gap3-jm5-2015-02-01.tar.gz
[..]
gap3-jm5-2015-02-01

Setting up build directory for gap3-jm5-2015-02-01
Finished extraction
Applying patches from ../patches...
Applying ../patches/gap3_init.patch
patching file lib/init.g
Applying ../patches/gap3_makefile.patch
patching file src/Makefile
Applying ../patches/gap3_startup.patch
patching file bin/gap.sh

Host system:
Linux associahedron 4.8.0-39-generic #42-Ubuntu SMP Mon Feb 20 11:47:27 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.0-5ubuntu12' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib 
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) 

spkg-install is using
VERSION = jm5-2015-02-01
GAP3_DIR = gap-jm5-2015-02-01
INSTALL_DIR = /home/stumpc5/Programs/sage-git/local/gap3/gap-jm5-2015-02-01/gap3
make[2]: Entering directory 
'/home/stumpc5/Programs/sage-git/local/var/tmp/sage/build/gap3-jm5-2015-02-01/src'
make[2]: *** No targets specified and no makefile found.  Stop.
make[2]: Leaving directory 
'/home/stumpc5/Programs/sage-git/local/var/tmp/sage/build/gap3-jm5-2015-02-01/src'
Error building gap3.

real0m0.003s
user0m0.000s
sys 0m0.000s

Error installing package gap3-jm5-2015-02-01

Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
  /home/stumpc5/Programs/sage-git/logs/pkgs/gap3-jm5-2015-02-01.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/home/stumpc5/Programs/sage-git/local/var/tmp/sage/build/gap3-jm5-2015-02-01 
and type 'make' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
  (cd 
'/home/stumpc5/Programs/sage-git/local/var/tmp/sage/build/gap3-jm5-2015-02-01' 
&& '/home/stumpc5/Programs/sage-git/sage' --sh)
When you 

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

[Dima Pasechnik]

On Wednesday, March 1, 2017 at 7:52:26 AM UTC, Jeroen Demeyer wrote:
>
> 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. 
>

Probably one can have an optional `replacements` file
in the package directory of each package that can be replaced by some 
others; or,
in build/packages/, a file named `alternatives` listing alternative 
packages, e.g.

altas openblas
foo bar baz
... ...
...






 

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