[sage-devel] Re: VOTE: move Sage development to Github

[Markus Wageringel]

+1 for Github

David Roe schrieb am Mittwoch, 21. September 2022 um 19:23:36 UTC+2:

> Dear Sage developers,
> Following extensive discussion, both recently 
>  
> (prompted 
> by issues upgrading the trac server) and over 
>  the 
>  last 
>  
> decade 
> , we 
> are calling a vote on switching Sage development from Trac 
>  to Github .  We've 
> created a summary of the pros and cons of each system 
> , a 
> description 
> of the development model to be used on github 
> , 
> and a trac ticket  for 
> coordinating work on the transition.  More work will need to be done to 
> carry out the actual transition once voting is complete.
>
> The voting will last until noon Eastern time (16:00 UTC) on Wednesday, 
> October 5.  Please use this thread only for sending votes, to make it 
> easier to count them afterward; there is a parallel thread where you can 
> make arguments in favor of either system.
>
> Finally, I will close with a plea to be involved in this vote and 
> discussion even if you are not a core Sage developer.  By definition, core 
> Sage developers have become comfortable with trac, and I think that one of 
> the major arguments in favor of github is that it will help bring in new 
> contributors who are not familiar with Sage's development workfow 
> .  Anyone who has 
> ever contributed to the Sage code base or who maintains a Sage user package 
> is welcome to vote.
> David
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1909897b-45d4-49ed-8a71-ac2ed7ed3ccen%40googlegroups.com.

[sage-devel] Parallel docbuild

[Markus Wageringel]

Currently, the html docs are not built in parallel when running `MAKE='make 
-j10' make ptestlong`, even when SAGE_NUM_THREADS is set. Is there a way to 
enable it again? This also limits the throughput of the patchbots.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1ee05f28-0230-4086-9b5f-9b96e487fd2an%40googlegroups.com.

Re: [sage-devel] trouble pushing to a ticket

[Markus Wageringel]

>
> OpenSSH 8.8 (recently stable on Gentoo) disables RSA with SHA-1. You 
> can work around it, but probably the best long-term solution is to 
> replace your RSA key with an ECDSA one (ssh-keygen -t ecdsa) and re- 
> upload it to trac.


 By the way, the trac server seems to be using an old version of OpenSSH 
(OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.13) which does not support the 
rsa-sha2-256 signature type yet. With a newer version of OpenSSH (≥7.2) on 
the trac server, it would be possible to use RSA keys, I think.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/37f6ff5c-4881-4d4a-a0fb-9414cae581fan%40googlegroups.com.

[sage-devel] Re: Bug computing kernel of ring homomorphism GCA

[Markus Wageringel]

Hi Trevor,

thank you for reporting this bug. This is indeed a problem, as the 
implementation is written only with the commutative case in mind. We should 
make sure that it is called in that case only.

As for your proposed fix, I am afraid I am not so familiar with the 
non-commutative theory myself, so I would value another opinion on this or 
a reference to some literature that covers this specifically.

Trevor Karn schrieb am Montag, 18. Oktober 2021 um 19:28:39 UTC+2:

> I forgot to add that Sage does recognize that f(a1*b2) is nonzero:
>
> sage: f(a1*a2)
> b1*b2
>
>
> On Monday, October 18, 2021 at 12:21:47 PM UTC-5 Trevor Karn wrote:
>
>> Hi all,
>>
>> It looks like I have found a bug in the `.kernel()` method of a ring 
>> homomorphism from one  `GradedCommutativeAlgebra` to another. I think I 
>> have identified the issue, but was hoping to post here for confirmation 
>> that my thinking makes sense before opening a trac ticket and working on a 
>> fix. 
>>
>> *The bug:* let A, B be `GradedCommutativeAlgebra`s each generated by two 
>> elements (a_1, a_2 and b_1, b_2 respectively) of degree-1 (so A,B are 
>> exterior algebras). Define a homomorphism f: A -> B taking a_1 -> b_1 and 
>> a_2 -> b_1 + b_2. 
>>
>> Then f(a_1a_2) = f(a_1)f(a_2) = b_1(b_1+b_2) = b_1^2 + b_1b_2 = 0 + b_1b2 
>> =/= 0.
>>
>> When I perform the same computation in Sage,  I get:
>>
>> sage: A = GradedCommutativeAlgebra(QQ,['a1','a2'], (1,1))
>> sage: B = GradedCommutativeAlgebra(QQ,['b1','b2'], (1,1))
>> sage: A.inject_variables();
>> sage: B.inject_variables();
>> sage: f = A.hom([b1, b1+b2], codomain=B)
>> sage: f.kernel()
>> Twosided Ideal (0, a1*a2, 0) of Graded Commutative Algebra with 
>> generators ('a1', 'a2') in degrees (1, 1) over Rational Field
>>
>> which I believe to be incorrect by my computation above. 
>>
>> *What I think is going wrong:*
>> When computing the kernel, the graph ideal is computed as an ideal in the 
>> tensor product ring of the domain tensored with the codomain. In 
>> constructing this it uses a (commutative) polynomial ring and takes a 
>> quotient. In creating the commutative polynomial ring the 
>> `.defining_ideal().gens()` method is called on the domain. The 
>> `.defining_ideal()` for a noncommutative ring has generators and relations, 
>> but calling the `.gens()` method accesses the generators only. For example:
>>
>> sage: A.defining_ideal()
>> Twosided Ideal (a1^2, a2^2) of Noncommutative Multivariate Polynomial 
>> Ring in a1, a2 over Rational Field, nc-relations: {a2*a1: -a1*a2}
>> sage: A.defining_ideal().gens()
>> (a1^2, a2^2)
>>
>> And so the relation that a2*a1 = - a1*a2 is forgotten in the tensor 
>> product ring.
>>
>> *My proposed fix:*
>> Add a function in sage.rings.morphism that computes the tensor product 
>> ring when the two rings are noncommutative, then add a check inside of 
>> graph_ideal to call _tensor_product_ring_nc as opposed to 
>> _tensor_product_ring. 
>>
>> Does this seem like a reasonable plan, or is there a better approach?
>>
>> Thanks!
>>
>> -Trevor
>>
>>
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b1e6ed6e-127f-4579-8f9b-889c8c64f5f7n%40googlegroups.com.

Re: [sage-devel] Re: Vector spaces with immutable vectors by default

[Markus Wageringel]

Generally, I would be in favor of having an option for immutable vectors by 
default, as I had similar uses before. Usually, I just convert everything 
to tuples.

However, I am not sure if having an additional flag on the parent is worth 
the extra burden on maintenance. Already the sparsity flag is not always 
handled correctly (#29359, #29360), immutability may be even easier to 
miss. In my own code, I tend to construct vectors by `vector(ring, [..])`, 
which relies on the uniqueness of the parent and will not preserve 
immutability of vectors. Though, it is fair to say that this code is 
already broken as it does not preserve sparsity either. On the other hand, 
code that is careful about preserving the parent could break if now the 
parent vector space does not allow for mutation. For example, in case of a 
(fabricated) function like

def f(vec, i):
w = vec.parent()(0)
w[i] = vec[i]
return w

one would have to convert the vector from an immutable vector space to one 
that allows for mutable elements before calling it. This just displaces the 
original problem.


Regarding the performance discussion, (although this was not the question) 
using vectors also has the potential of being much slower than using numpy 
arrays directly.

sage: a = vector(CDF, [CDF(1, i/(i+1)) for i in range(10^6)])
sage: %time c1 = a.conjugate()
Wall time: 4.39 s
sage: %time c2 = a.parent()(a.numpy().conj())
Wall time: 11.8 ms

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cb07a81a-f414-4316-a7bf-594d5b1a6169n%40googlegroups.com.

[sage-devel] Re: multi-polynomial subs memory leak

[Markus Wageringel]

vdelecroix schrieb am Freitag, 7. Mai 2021 um 10:09:59 UTC+2:

> I propose to switch to naive symbolic 
> evaluation. This is infinitely slower but at least does not 
> leak memory.
>

Recently, I have looked into performance problems of multivariate power 
series. One of the bottlenecks is the use of subs() of polynomials, so I am 
worried that the proposed change has an unforeseen impact on performance in 
other places, especially if this is rushed into 9.3 at this point. This is 
a trade-off between running out of memory and running out of time in 
computations. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/efeba33b-a44c-4b75-b6d9-45c5c0c63e49n%40googlegroups.com.

Re: [sage-devel] possible bug: kernel of ring homomorphism

[Markus Wageringel]

Thank you for reporting this problem. I have opened 
https://trac.sagemath.org/ticket/31367 for it and will provide a fix there 
shortly.

Akos M schrieb am Montag, 8. Februar 2021 um 11:42:59 UTC+1:

> It seems that unfortunately the problem persists for multivariate rings as 
> well:
>
> A. = QQ[]
> B. = QQ[]
> H = B.quotient(B.ideal([B.2]))
> f = A.hom([H.0, H.1], H)
> f
> f.kernel()
>
> Ring morphism: 
>  From: Multivariate Polynomial Ring in t, u over Rational Field 
>  To: Quotient of Multivariate Polynomial Ring in x, y, z over Rational 
> Field by the ideal (z) 
>  Defn: t |--> xbar 
>u |--> ybar 
> Ideal (-t, -u, 0) of Multivariate Polynomial Ring in t, u over Rational 
> Field
>
> I have the impression that the fact that the ring homomorphism is to a 
> quotient ring introduces the error, but that's just a wild guess. 
> On Monday, February 8, 2021 at 11:09:52 AM UTC+1 dim...@gmail.com wrote:
>
>> A wild guess would be that it's due to univariate and multivariate 
>> rings handled by different backends in Sage, one sees this kinds of 
>> corner cases errors. 
>>
>> On Mon, Feb 8, 2021 at 10:06 AM John Cremona  
>> wrote: 
>> > 
>> > It looks like a bug to me. f.kernel() expands to 
>> > f._inverse_image_ideal(f.codomain().zero_ideal()) and 
>> > f.codomain().zero_ideal() looks OK so the problem must be in the 
>> > inverse image. The author is apparently Simon King (2011). Simon, 
>> > can you help? 
>> > 
>> > John 
>> > 
>> > On Mon, 8 Feb 2021 at 09:20, Akos M  wrote: 
>> > > 
>> > > Hi, 
>> > > 
>> > > I'm not sure whether this is a bug or not, but the kernel of a ring 
>> homomorphism to a quotient ring gives unexpected results: 
>> > > 
>> > > A. = QQ[] 
>> > > B. = QQ[] 
>> > > H = B.quotient(B.ideal([B.1])) 
>> > > f = A.hom([H.0], H) 
>> > > f 
>> > > f.kernel() 
>> > > 
>> > > outputs: 
>> > > 
>> > > Ring morphism: From: Univariate Polynomial Ring in t over Rational 
>> Field 
>> > > To: Quotient of Multivariate Polynomial Ring in x, y over Rational 
>> Field by the ideal (y) Defn: t |--> xbar 
>> > > Principal ideal (t) of Univariate Polynomial Ring in t over Rational 
>> Field 
>> > > 
>> > > whereas the kernel of f:A[t]->B[x,y]->B[x,y]/(y), for f(t)=x should 
>> be (0). 
>> > > 
>> > > Is this a bug? 
>> > > 
>> > > Thanks, 
>> > > Akos 
>> > > 
>> > > -- 
>> > > 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+...@googlegroups.com. 
>> > > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/3eeea5f7-4ea2-4586-bbb6-04d00c0d4fa9n%40googlegroups.com.
>>  
>>
>> > 
>> > -- 
>> > 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+...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/CAD0p0K45OKUuLWegC6sXWHoTWs9ppPf7htmZ1wVyBo_O08%3DNTw%40mail.gmail.com.
>>  
>>
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/806d3b24-3f01-49b5-89e1-50e218b427d0n%40googlegroups.com.

Re: [sage-devel] Re: Generalized eigenvalues with GUPTRI

[Markus Wageringel]

Thank you for the link. I am a bit surprised I did not find that myself.

I have been planning to add something to the release notes and will do so soon. 
I do not have a legacy trac account yet, but I have just sent a request for one.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1606D672-B430-4E14-A655-2F05F61AB876%40gmail.com.

[sage-devel] Re: inconsistencies when computing eigenvectors over a number field and over QQbar

[Markus Wageringel]

Hello Paul, thank you for the report. I can confirm that the problem is 
still present in the current version of Sage and have 
opened https://trac.sagemath.org/ticket/30518 for it.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/81f74139-37f0-4992-9936-aa26c2c957d9n%40googlegroups.com.

Re: [sage-devel] check merge failure on Trac

[Markus Wageringel]

Another option is to use git worktree to create a second copy of the source 
tree in the repository.

$ git worktree add my_worktree
$ cd my_worktree/
$ ln -s ../upstream/ .

This creates a subdirectory with a copy of all source files, where one can 
merge the branches without touching the main tree. The last command is 
useful in case one decides to build a second copy of sage in the 
subdirectory.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8c587d38-4651-49d8-a5ea-ba4eda7bbcabn%40googlegroups.com.

[sage-devel] Generalized eigenvalues with GUPTRI

[Markus Wageringel]

Hello everyone.

In Sage 9.2.beta11, Sage's functionality for eigenvalues and eigenvectors 
has been extended in two directions:

• In #30393 , Marc Mezzarobba has 
added wrappers for arb's new support for arbitrary precision computation of 
eigenvalues and eigenvectors.
• In #29243 , support for computing 
generalized eigenvalues via SciPy was added (both reviewed by Sébastien 
Labbé – thanks).

Adding to the second point, I would like to share an external package, 
guptri_py [1], that I created for NumPy and Sage. It is a small wrapper for 
the Fortran library GUPTRI [2] and can be used to compute generalized 
eigenvalues when a matrix pencil is singular.

To give some details, for two matrices A and B, the roots of the polynomial 
det(A - λB) are called generalized eigenvalues. If the polynomial is 
constantly zero, the pencil is said to be singular, in which case 
eigenvalues are more difficult to define and to compute – this is what 
GUPTRI can be used for (in contrast to SciPy/LAPACK).

I hope this package might be useful for someone.
By the way, is there a place that lists external Sage packages to make them 
easier to find? All I could find is a collection of old SPKGs.

Best regards,
Markus

[1] https://github.com/mwageringel/guptri_py
[2] https://www8.cs.umu.se/research/nla/singular_pairs/guptri/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/dbd13b61-227d-493d-bbbe-8d910ea90eben%40googlegroups.com.

[sage-devel] Re: Preparser is seriously broken!

[Markus Wageringel]

I have also noticed this problem. It seems to be caused by the upgrade to 
IPython 7 https://trac.sagemath.org/ticket/28197. I have opened 
https://trac.sagemath.org/ticket/30417 for this.

Andrey Novoseltsev schrieb am Donnerstag, 20. August 2020 um 23:54:52 UTC+2:

> It interferes with multiline strings now!!!
>
> ┌┐
> │ SageMath version 9.2.beta9, Release Date: 2020-08-18   │
> │ Using Python 3.7.3. Type "help()" for help.│
> └┘
> ┏┓
> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> ┗┛
> sage: html(r""" 
> : $2 \leq x$ 
> : """) 
> 
>
> Integer(2)  * BackslashOperator() * leq x
>
> sage: html(r"""$2 \leq x$""") 
>  
> 2 \leq 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b5f8fe1a-fddc-412a-825f-9316dad128edn%40googlegroups.com.

[sage-devel] Re: Get source (??) bug

[Markus Wageringel]

This is not related to the init.sage file, but to the fact that 
TriangleNumbers is a class. You can reproduce the problem like this

sage: class TriangleNumbers:
: pass
sage: import inspect
sage: inspect.getsourcelines(TriangleNumbers)
...
TypeError:  is a built-in class

which is what gets called in `sage.misc.sageinspect`. On the other hand, 
for functions defined in the init.sage file, inspection works as usual. 
This is an IPython feature, which is not directly implemented in Sage. 
There is an IPython issue for the problem with classes: 
https://github.com/ipython/ipython/issues/11249


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/96cbc125-b974-43b5-af03-50bf3c6a6410n%40googlegroups.com.

Re: [sage-devel] Definite Integral wrong

[Markus Wageringel]

Even if there are two possible choices, the result of the definite integral 
should be ±8, not 0. It is rather strange to pick the positive square root 
for half the integral and then (discontinuously) the negative one for the 
other half.

There is a ticket for exactly this integral, by the way: 
https://trac.sagemath.org/ticket/17183.

rjf schrieb am Mittwoch, 5. August 2020 um 20:59:01 UTC+2:

> There are two square roots.  In this (classic) integration example/bug, a 
> choice has
> to be made.  You know that 4 has two square roots,  -2 and 2. 
> The integrand, which also can be rewritten as   sqrt ( 4-4*cos(x/2)^2) , 
> has 2 square roots.
> Therefore there are two potential different values for the integral.  Any 
> answer
> that supplies only one answer is wrong.
>
>
>
> On Tuesday, August 4, 2020 at 1:56:16 AM UTC-7, Emmanuel Charpentier wrote:
>>
>> BTW :
>>
>> sage: integrate(sqrt(2-2*cos(x)),x, algorithm="fricas")
>> -2*(cos(x) + 1)*sqrt(-2*cos(x) + 2)/sin(x)
>> sage: integrate(sqrt(2-2*cos(x)),x, algorithm="mathematica_free")
>> -2*sqrt(-2*cos(x) + 2)*cot(1/2*x)
>>
>> Both are visually (on plot) and numerically correct ; both differentiate 
>> to expressions very hard to show equal to the original function.
>>
>> HTH,
>>
>> Le lundi 3 août 2020 10:50:12 UTC+2, Dima Pasechnik a écrit :
>>
>> This is a well-known bug in Sage. A workaround is to set the domain to 
>>> "real":
>>>
>>> sage: maxima_calculus.eval('domain: real');
>>> sage: integrate(sqrt(2-2*cos(x)),x,0,2*pi) # correct answer
>>> 8
>>>
>>> sage: maxima_calculus.eval('domain: complex'); # restore the state back
>>> sage: integrate(sqrt(2-2*cos(x)),x,0,2*pi) # now here the result is 
>>> again wrong, of course
>>> 0
>>>
>>>
>>> On Sun, Aug 2, 2020 at 5:26 PM Nico Guth  wrote:
>>>
 Hi,

 I discovered a bug, where a definite integral is calculated wrong!
 WolframAlpha result for comparison.

 Code:
 integrate(sqrt(2-2*cos(x)),x,0,2*pi)

 Also if I type show() instead of print() SageMathCell just doesn't show 
 anything.

 Also the form in which the indefinite integral is given is not very 
 pretty.
 WolframAlpha does a much better job simplifying.

 [image: sage_wrong_integral.png][image: 
 sage_wrong_integral_wolfram.png]
 [image: sage_wrong_integral_wolfram_2.png]

 -- 
 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-...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/sage-devel/487d0db8-5711-41a8-a7d4-1548286b5573n%40googlegroups.com
  
 
 .

>>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/20aefabc-e29b-4453-a7ea-cfc4e7e0f138n%40googlegroups.com.

[sage-devel] Re: cd /Documents/course-123/ fails because of preparser

[Markus Wageringel]

This issue is difficult to solve. A similar problem was discussed in 
https://trac.sagemath.org/ticket/29391#comment:4. Using `cd` instead of 
`%cd` is an IPython "feature" called automagic which is not guaranteed to 
always work – for example, if there is a variable named `cd` in scope. The 
following behavior is correct I would say:

sage: implicit_multiplication(True)
sage: cd = 10
sage: test = 100
sage: cd test-123
877
sage: preparse("cd test-123")
cd*test-Integer(123)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2677f0f7-5a68-4c56-920e-734963528aabo%40googlegroups.com.

Re: [sage-devel] Re: Patchbot r640 fails with "disk full"

[Markus Wageringel]

Yes, I will give that a try. Thanks.

By searching through the patchbot logs in reverse, I also found the ticket that 
was causing the infinite print loop: https://trac.sagemath.org/ticket/19025 
.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/D0F4A927-DFEC-41A4-9650-60894A62FFAF%40gmail.com.

[sage-devel] Re: Patchbot r640 fails with "disk full"

[Markus Wageringel]

Thank you for the note. I have disabled this patchbot client for now.

The problem seems to be that the /tmp directory gets flooded with thousands 
of little files that do not get removed automatically. It has been less 
than two weeks since I have last cleared the /tmp directory, and now there 
are already more than 100.000 files. Is there a way to let the patchbot 
delete the temporary files it created automatically after each ticket? The 
machine the patchbot client is running on has recently been switched from 
CentOS to Ubuntu – maybe it is just a coincidence, but this has not been a 
problem before.

97% of the temporary files are created by ECL (they are named `ecl`). 
Maybe the ECL upgrade in 9.2.beta5 has something to do with it?

Another major problem are two huge files containing the following output. 
One of them is more than 30 GB in size. Does anyone know where this is 
coming from? This code is not the source tree of the develop branch, so it 
might be some trac ticket, possibly related to Cysignals.

sage: cython('while True: print("Hello")') ## line 245 ##
Hello
Hello
Hello
Hello
Hello
Hello
Hello
Hello
Hello
Hello
Hello
Hello
Hello
...

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/aa01ffce-445d-4450-ba75-860741ccb004o%40googlegroups.com.

Re: [sage-devel] Making executables available to Sage

[Markus Wageringel]

One example is https://github.com/mwageringel/fgb_sage, which is a small 
wrapper for an external C binary and which uses sage_sample as a template. 
The relevant part is the setup.py file, which downloads the external files 
and makes them available for compiling the Cython code. It does not use 
pipx (which I do not know about), but is implemented in a somewhat ad-hoc 
fashion, so probably this is not the optimal way to achieve this but could 
be streamlined a bit.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/33bca7b6-33d9-4ae2-a734-e809ec5f120co%40googlegroups.com.

Re: [sage-devel] Re: Wrong matrix of Permutation

[Markus Wageringel]

Am Freitag, 19. Juni 2020 18:40:34 UTC+2 schrieb Nils Bruin:
>
> All this disappears once we are happy using functions with two parameters 
> as "action operation":
>
> left = G.acting_on_the_left_on(M) # or left = M.left_action_by(G)
>
> left(g,m)
>
> left = G.acting_on_the_right_on(M) # or left = M.right_action_by(G)
>
> right(m,g)
>

This functionality is already available for actions that are actually 
implemented via Action:

sage: G = SymmetricGroup(3)
sage: M = MatrixSpace(QQ, 3)
sage: right = coercion_model.get_action(M, G)
sage: right(M.diagonal_matrix([1,2,3]), G('(2,3)'))  # with #29808
⎛1 0 0⎞
⎜0 0 2⎟
⎝0 3 0⎠

For cases where this is not implemented, it is possible to construct and 
register custom actions (a factory function for this might be useful). For 
example, the right action of the symmetric group on the integers via 
exponentiation:

sage: class CallAction(sage.categories.action.Action):
: def _act_(self, g, a):
: return g(a)
sage: G = SymmetricGroup(3); g, h = G('(1,2,3)'), G('(2,3)')
sage: right = CallAction(G, ZZ, is_left=False, op=operator.pow)
sage: right(right(1, g), h)
3
sage: ZZ._unset_coercions_used()
sage: ZZ.register_action(right)
sage: (1 ^ g) ^ h
3
sage: 1 ^ (g * h)
3

It is not currently possible to use shift operators for this, as they are 
not implemented in sage.structure.element. Also, it might not be easily 
possible to support the operator syntax for actions on non-Sage types such 
as Python lists.
 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/219e0c77-210f-4cbb-89dc-71493ffb28e7o%40googlegroups.com.

[sage-devel] Re: Bug in category_singleton.__contains__ or in CombinatorialFreeModule

[Markus Wageringel]

I think the problem here is that enumerating over a disjoint union of an 
infinite set and a finite set will never reach the elements in the finite 
set. There is this comment in the documentation of 
DisjointUnionEnumeratedSets

   Possible extensions: the current enumeration order is not suitable
>for unions of infinite enumerated sets (except possibly for the
>last one). One could add options to specify alternative enumeration
>orders (anti-diagonal, round robin, ...) to handle this case.


so the workaround is to first enumerate over the finite set and then the 
infinite set, as the last enumerated set in the union will determine 
whether the disjoint union is finite or not:

sage: DisjointUnionEnumeratedSets([NonNegativeIntegers(), Family('x')]) in 
FiniteSets()
True
sage: DisjointUnionEnumeratedSets([Family('x'), NonNegativeIntegers()]) in 
FiniteSets()
False

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/aeb3c3ba-c804-428d-9119-2629950be6cbo%40googlegroups.com.

Re: [sage-devel] Re: Wrong matrix of Permutation

[Markus Wageringel]

Am 18.06.2020 um 19:47 schrieb Nils Bruin :
> 
> On Thursday, June 18, 2020 at 5:00:00 AM UTC-7, kcrisman wrote:
> 
> I assume that would need a pretty major change in the preparser?  Does other 
> mathematical software use this as a convention?  (Just asking, no 
> presuppositions here.) 
> 
> No, not the preparser. It would affect the coercion framework quite a bit, 
> though. It would mean that __lshift__ and __rshift__ need to be hooked into 
> left actions and right actions. Using ">>" and "<<" for actions has the large 
> advantage that the methods are for the most part available. The coercion 
> framework can already discover left and right multiplicative actions (used 
> for scalar multiplication and matrix actions on modules), so I'd expect it 
> can be made to discover "shift" actions by specifying the relevant operator.

Indeed, this would not require changes to the preparser, as these are standard 
Python operators. I assume that we could implement the shift methods on 
SageObject (possibly with some special care for Integers that implement the 
bitwise shifts), which would then redirect to the appropriate discovery of the 
correct action that is already implemented. Cython actually helps us here 
because, instead of calling x.__lshift__(y), it automatically calls something 
like type(y).__lshift__(x, y) if __lshift__ is not implemented on x. This is 
useful if x is not a Sage type, but a Python type such as list or int, on which 
a permutation might act from the right.


As for other mathematical software, I do not know any that uses >> and << for 
group actions. However, I think it is rather common to use operators that are 
the same but flipped for operations that have a right- and left-minded variant. 
In Python, only the shift operators can be used for that, unless we extend the 
preparser.

The best example I can think of is that of the Monad bind operation >>= and 
Kleisli composition >=> in Haskell, which has also been adopted by several 
libraries in other languages. For a monad element m and Kleisli functions f and 
g, the following are the same

(m >>= f) >>= g
m >>= (f >=> g)

so this can be thought of as a right action. Similarly, the flipped operators 
exist:

f =<< (g =<< m)
(f <=< g) =<< m

Another common example of same-but-flipped operators is <<< and >>> for 
composition of arrows in a category/semigroupoid.

Other examples include Matlab's / and \ operators for matrix division, and the 
/ and \ operator in Macaulay2 for mapping a function over a list. For example, 
the following are the same in Macaulay2

(1,2,3) / sqrt / sin
sin \ sqrt \ (1,2,3)
sin @@ sqrt \ (1,2,3)

so this is a left action. If one views permutations as bijective functions of 
{1,..,n}, the left action of permutations is a special case of this.

Admittedly, these operators do not look like mathematical notation, but they 
can still be useful for programming. In all the associativity laws above, 
mathematically one does not care about the execution order, but for programming 
it is still often relevant. I do not expect Sage/Python to embrace unicode 
operators the way, for example, Agda does [1], so this limits the options quite 
a bit.


[1] 
https://github.com/agda/agda-stdlib/blob/49fa0985b2e7ed8896174f4d7ecca92d4e8c847d/src/Algebra/Module/Bundles.agda#L145-L151


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/59D0D81E-75CF-494A-BF50-1431DE13288E%40gmail.com.

Re: [sage-devel] Re: Wrong matrix of Permutation

[Markus Wageringel]

Am Dienstag, 16. Juni 2020 19:03:40 UTC+2 schrieb Nils Bruin:
>
> That's quite a thread. One thing I'd like to highlight from there that 
> didn't seem to get so much traction is a point Marco Streng made about 
> possible notations for right actions:
>
> If G is a group acting on the right on a ring R, and a,b in R and s in G 
> then denoting right-action by right-multiplication has a problem:
>
> (a*b)*s would suggest it's equal to a*(b*s), which it is generally not. 
> Exponential notation (a*b)^s does not suffer from this problem. That 
> disqualifies right-multiplication as a general notation for right-actions 
> to me.
>

I would also be in favor of using a different notation for actions. My 
suggestion would be to use the shift operator << to denote right actions 
and, similarly, the right shift operator >> for left actions. This makes it 
explicit what kind operation is intended; for example, `a*b << s*t` and 
`a*b << s << t` would do exactly what one expects.

This notation can be thought of as a generalization of the bitwise << 
operation if one interprets it as a monoid action of (ℕ,+). The notation 
can be used for both multiplicative and additive groups.

As the shift operators are not common mathematical operators, it is less 
likely to confuse them with actual mathematical operations like 
exponentiation or multiplication. This could also resolve otherwise 
ambiguous cases, such as the Weyl algebra acting on the polynomial ring, 
where multiplication already has a different meaning.

If one wants, one could even define the action of permutations on 
permutations themselves and, thus, distinguish between left-to-right and 
right-to-left multiplication via << and >>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f2bda511-d8ce-416a-b0cd-fa5150023dbdo%40googlegroups.com.

Re: [sage-devel] Re: Wrong matrix of Permutation

[Markus Wageringel]

Am Dienstag, 16. Juni 2020 13:40:45 UTC+2 schrieb kcrisman:
>
>
> so, "Permutation" objects aren't really meant to be a group: 
>>
>
> I think this is the salient point.   Is there any documentation that 
> already has matrix(Permutation(...)) ? 
>
 
The documentation of Permutation.to_matrix 

 
states this:

Notice that matrix multiplication corresponds to permutation 
multiplication only when the permutation option mult=’r2l’

I am not sure why exactly it was implemented like this, but I imagine this 
makes it generally more predictable, as the conversion to matrices does not 
depend on a global option of Permutations.
 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2146dc83-fc14-43cb-bc07-487dd3812439o%40googlegroups.com.

Re: [sage-devel] bug in matrix solve over inexact coefficients?

[Markus Wageringel]

Don't get me wrong. I would greatly prefer if RR would detect the 
ill-conditioned cases as well, but, as it stands, this is not implemented. 
Neither LU nor QR decompositions are supported for RR, so it is not easy to 
change this. The default implementation for solve_right just computes an 
echelonization.

Putting a warning in the except clause might be a good first step indeed, as it 
should at least detect the case of a matrix that is singular to machine 
precision.

For the record, this is what Matlab does in these cases:

>> linsolve([0], [1])
Warning: Matrix is singular to working precision.

ans =

   Inf

>> linsolve([0], [0])
Warning: Matrix is singular to working precision.

ans =

   NaN

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4969CF48-442E-4486-891B-151FF39AFD0A%40gmail.com.

Re: [sage-devel] bug in matrix solve over inexact coefficients?

[Markus Wageringel]

Indeed, instead of ignoring the `check` keyword altogether over inexact 
fields, it would be useful to verify the solution when that is possible, 
such as for exact input over SR and for ball and intervall fields. I have 
opened #29729  for this. For 
general inexact rings though, the result cannot be verified, so it would 
not make sense to do the check by default.


Am Samstag, 23. Mai 2020 07:15:45 UTC+2 schrieb Dave Morris:
>
> From the documentation at 
> https://www.mathworks.com/help/matlab/ref/mldivide.html, it appears to me 
> that MATLAB gives a warning: "Warning: Matrix is close to singular or badly 
> scaled. Results may be inaccurate."  That seems to me to be a better 
> default behavior than what sage is doing now, but I think it would make 
> sense to let users choose to turn off the warning (and maybe also let them 
> upgrade it to an error).
>

 The generic implementation of `solve_right` does not provide this. I would 
suggest to use a type that has a specialized implementation for this, such 
as RDF, CDF, CBF. For example over RDF and CDF, a warning is issued if the 
input is ill-conditioned and an error is raised if the matrix is singular, 
which is a reasonable behavior:

sage: matrix(RDF, [[2/3, 1], [0.4, 0.6]]).solve_right(vector(RDF, [1, 1]))
/Applications/SageMath/src/bin/sage-ipython:1: LinAlgWarning: Ill-conditioned 
matrix (rcond=2.77556e-17): result may not be accurate.
  #!/usr/bin/env sage-python
(5404319552844596.0, -3602879701896396.0)
sage: matrix(RDF, [[0]]).solve_right(vector(RDF, [1]))
...
LinAlgError: Matrix is singular.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/bf5e377d-630c-49f9-8347-4798dd6fd8bc%40googlegroups.com.

Re: [sage-devel] remove log_html() and other log_*()

[Markus Wageringel]

Am Freitag, 8. Mai 2020 09:03:08 UTC+2 schrieb Sebastian Oehms:
>
> But if we talk about users who are not interested in code and strings, 
> wouldn't it be more useful for them to have a function that searches 
> through the global name space? Do we have such a one?
>

We do indeed. It is an IPython feature. You can use

sage: *poly*?

which is equivalent to

sage: %psearch *poly*

The psearch magic also has options such as case-insensitivity

sage: %psearch -i *poly*


As for SageMathCell, I seem to recall that tab completion used to work 
there as usual, but currently it does not work for me either.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f0b327fc-eb76-43ca-9233-7cec554ab6bc%40googlegroups.com.

[sage-devel] Re: Polarization of Homogeneous Polynomials

[Markus Wageringel]

Am Dienstag, 28. April 2020 20:23:01 UTC+2 schrieb Markus Wageringel:
>
> T = TensorFreeModule(V, (0, n))
> t = T([], name='t', sym=range(n))
>

There is an error in this code. Here, `n` needs to be replaced by 
`f.degree()`. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/34020e36-b81a-4c92-a9ff-37df66a692bb%40googlegroups.com.

[sage-devel] Re: Polarization of Homogeneous Polynomials

[Markus Wageringel]

Hi Michael,

I do not know about preimplemented algorithms outside Sage itself, but it 
would not be so difficult to define this map directly. For example, as a 
map to the free algebra:

sage: T. = FreeAlgebra(QQ)
sage: R. = PolynomialRing(QQ)
sage: def _polarize(f):
: M = T.indices()
: D = {}
: for e, c in zip(f.exponents(), f.coefficients()):
: c2 = c / multinomial(e)
: for p in Permutations(M(list(enumerate(e))).to_list()):
: D[M.prod(p)] = c2
: return T._from_dict(D)
sage: from sage.categories.morphism import SetMorphism
sage: polarize = SetMorphism(Hom(R, T, Modules(R.base_ring())), _polarize)
sage: polarize(x^2*y + x*y*z)
1/3*u^2*v + 1/3*u*v*u + 1/6*u*v*w + 1/6*u*w*v + 1/3*v*u^2 + 1/6*v*u*w + 1/6*
v*w*u + 1/6*w*u*v + 1/6*w*v*u

Now this is a one-sided inverse for symmetrization:

sage: symmetrize = T.module_morphism(on_basis=lambda a: R.prod(R.gen(ai)^ni 
for ai, ni in a._element_list),
:codomain=R)
sage: f = R.random_element(6, 15)
sage: symmetrize(polarize(f)) == f
True

The main problem with this is the combinatorial complexity, as the output 
quickly becomes huge for larger input. So it might be better if you can 
avoid computing this representation explicitly in your use case. After all, 
all this does is to divide the coefficients by some multinomial 
coefficient. Nevertheless, I still think this functionality would be useful 
for small cases and nice to have in Sage.

Alternatively, if you are more interested in viewing this as a multilinear 
form, then TensorFreeModule may be more suitable. This representation keeps 
track of symmetries in order to store coefficients without redundancy. Here 
is a quick example, but there may be room for improvement:

def polarize_form(f):
n = f.parent().ngens()
V = FiniteRankFreeModule(f.parent().base_ring(), n, name='V')
B = V.basis('x')
from sage.tensor.modules.tensor_free_module import TensorFreeModule
T = TensorFreeModule(V, (0, n))
t = T([], name='t', sym=range(n))
for e, c in zip(f.exponents(), f.coefficients()):
idx = [j for j, ej in e.sparse_iter() for _ in range(ej)]
t.set_comp(B)[idx] = c / multinomial(e)
return t

sage: t = polarize_form(x^2*y + x*y*z)
sage: t.symmetries()
symmetry: (0, 1, 2); no antisymmetry
sage: t.display()
t = 1/3 x_0*x_0*x_1 + 1/3 x_0*x_1*x_0 + 1/6 x_0*x_1*x_2 + 1/6 x_0*x_2*x_1 + 
1/3 x_1*x_0*x_0 + 1/6 x_1*x_0*x_2 + 1/6 x_1*x_2*x_0 + 1/6 x_2*x_0*x_1 + 1/6 
x_2*x_1*x_0
sage: V = t.base_module()
sage: t(V([0,0,1]), V([1,7,3]), V([1,0,0]))
7/6

Best,
Markus

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/36efbf3f-9672-48bb-a925-33963f83ac6a%40googlegroups.com.

[sage-devel] Re: Efficient algorithm to express symmetric polynomial in terms of elementary ones

[Markus Wageringel]

The bottleneck in `from_polynomial` is the check to test whether the input 
is actually a symmetric polynomial. If you disable the check, the 
computation is moderately fast, although not quite as fast as Vincent's 
code.

Sym.e().from_polynomial(P(seq_taylor), check=False)



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6bf4416c-f515-4eba-a631-27a795860386%40googlegroups.com.

[sage-devel] Re: Is this a bug?

[Markus Wageringel]

Am Donnerstag, 16. April 2020 13:39:39 UTC+2 schrieb Mihai:
>
> fn = diff(FN(x,n), x)
> mean(n) = integral(fn(x, n), (x, 0, oo))
>
 
The main problem with this is that `fn` is just an expression, not a 
function of `(x, n)`. The call `fn(x, n)` switches the position of x and n, 
as apparently the arguments of the expression are listed in alphabetical 
order.

sage: fn
n*(1/(e^(-x) + 1))^(n - 1)*e^(-x)/(e^(-x) + 1)^2
sage: fn.arguments()
(n, x)
sage: fn(x, n)
x*(e^(-n) + 1)^(-x + 1)*e^(-n)/(e^(-n) + 1)^2

With that in mind, replacing `fn(x, n)` by just `fn` in the integral leads 
to the output that Michael obtained, so apparently Sage (or Maxima) has 
difficulties to compute this integral symbolically for all n. However, if 
you replace n by an actual integer before integrating, you get better 
results:

sage: F(x)=1/(1 + exp(-x))
sage: FN(x,n) = F(x)**n
sage: fn = diff(FN(x,n), x)
sage: mean = lambda k: integral(fn.subs({n: k}), (x, 0, oo))
sage: [mean(k) for k in (1..10)]
[1/2, 3/4, 7/8, 15/16, 31/32, 63/64, 127/128, 255/256, 511/512, 1023/1024]

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1a316463-c289-48ec-881b-e48324117b15%40googlegroups.com.

[sage-devel] Re: Segmentation fault factoring a multivariate polynomial over IntegerModRing

[Markus Wageringel]

It looks like this problem is going to be fixed by the upgrade to Singular 
4.1.3 (#25993).

sage: R. = Integers(7)[]
sage: p = x**2-1
sage: p.factor()
(x + 1) * (x + 6)

There is another segmentation fault related to the non-commutative 
subsystem Plural, though, causing a doctest failure on the upgrade branch. 
See https://trac.sagemath.org/ticket/25993#comment:22 for details. Any help 
with this is appreciated.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/79f7bfbe-ac80-4ea3-9204-6a33abc31964%40googlegroups.com.

Re: [sage-devel] Re: Possible bug regarding the mod() method for multi-variable polynomials

[Markus Wageringel]

Oh, you are right. Sorry for the noise.


> Am 09.04.2020 um 19:32 schrieb Dima Pasechnik :
> 
> On Fri, Apr 10, 2020 at 1:20 AM Markus Wageringel
>  wrote:
>> 
>> There is also #27508 about this problem. It looks like a possible solution 
>> was suggested by upstream, but has not been implemented in Sage yet.
>> 
> IMHO #27508 is a different issue - that the reductions (for some
> orders/cases) are not always done,
> whereas here reductions are done.
> 
>> --
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/a68ce5c3-abec-4ad3-bd49-2c505851696d%40googlegroups.com.
> 
> -- 
> 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/nDoUXqpJ6OU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CAAWYfq2pzwhGSDL6C4%2BeguBibPEj2GgykAenFG84G9TPbGcEJg%40mail.gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/C8890659-3860-4EC6-86B6-F363C61006DA%40gmail.com.

[sage-devel] Re: Possible bug regarding the mod() method for multi-variable polynomials

[Markus Wageringel]

There is also #27508  about this 
problem. It looks like a possible solution was suggested by upstream, but 
has not been implemented in Sage yet.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a68ce5c3-abec-4ad3-bd49-2c505851696d%40googlegroups.com.

[sage-devel] Re: doc for web server installation

[Markus Wageringel]

Hi Denis, I am not sure if this helps with your use case, but something I 
occasionally use to run Jupyter on a remote machine is a command like this:

ssh -L localhost::localhost: REMOTE -t sage -n jupyter --no-browser 
--port=

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4c72e371-a070-4f8e-bf09-12003416d095%40googlegroups.com.

Re: [sage-devel] Re: solve() yields an expression rather than an equation/inequality

[Markus Wageringel]

Yes, if you could do that, that would be nice. Thank you. I am not really 
familiar with Maxima myself.


> Am 31.03.2020 um 15:13 schrieb Evan O'Dorney :
> 
> Thank you, Markus. So shall I submit it as a bug on 
> https://sourceforge.net/p/maxima/bugs/ 
> <https://sourceforge.net/p/maxima/bugs/>? I searched for it, and it appears 
> to be new.
> 
> Thanks,
> Evan
> 
> 
> On Sun, Mar 29, 2020 at 5:36 PM Markus Wageringel 
> mailto:markus.wagerin...@gmail.com>> wrote:
> Thank you for the report. This seems to be a problem in Maxima itself:
> 
> sage -maxima
> (%i1) load(to_poly_solve)$
> (%i2) to_poly_solve([x > 0, x <= 2*y, x <= 2 - 2*y], x);
> (%o2) %union([0 < x, x < min(2 y, 2 - 2 y), 2 y > 0, - 2 (y - 1) > 0],
> [x = 2 - 2 y, - 2 (y - 1) > 0, 2 (2 y - 1) > 0], [x = 2 y, 2 y > 0, 2 y - 1],
> [x = 2 y, - 2 (2 y - 1) > 0, 2 y > 0])
> 
> 
> -- 
> 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/uSKLDDC77ZM/unsubscribe 
> <https://groups.google.com/d/topic/sage-devel/uSKLDDC77ZM/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> sage-devel+unsubscr...@googlegroups.com 
> <mailto:sage-devel+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/e7f6205b-8ff8-4536-a756-1e62f71f3b25%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/sage-devel/e7f6205b-8ff8-4536-a756-1e62f71f3b25%40googlegroups.com?utm_medium=email_source=footer>.
> 
> -- 
> 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/uSKLDDC77ZM/unsubscribe 
> <https://groups.google.com/d/topic/sage-devel/uSKLDDC77ZM/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> sage-devel+unsubscr...@googlegroups.com 
> <mailto:sage-devel+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/CA%2BZgNF5%3D78gin-WDWdgsge3sNQ0XNC5SfTc%3D3MJGewYmEXwC8w%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/sage-devel/CA%2BZgNF5%3D78gin-WDWdgsge3sNQ0XNC5SfTc%3D3MJGewYmEXwC8w%40mail.gmail.com?utm_medium=email_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/209A0EE8-C685-40CA-BFD7-2360E3DA8D90%40gmail.com.

[sage-devel] Re: solve() yields an expression rather than an equation/inequality

[Markus Wageringel]

Thank you for the report. This seems to be a problem in Maxima itself:

sage -maxima
(%i1) load(to_poly_solve)$
(%i2) to_poly_solve([x > 0, x <= 2*y, x <= 2 - 2*y], x);
(%o2) %union([0 < x, x < min(2 y, 2 - 2 y), 2 y > 0, - 2 (y - 1) > 0],
[x = 2 - 2 y, - 2 (y - 1) > 0, 2 (2 y - 1) > 0], [x = 2 y, 2 y > 0, 2 y - 1
],
[x = 2 y, - 2 (2 y - 1) > 0, 2 y > 0])

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e7f6205b-8ff8-4536-a756-1e62f71f3b25%40googlegroups.com.

[sage-devel] Re: Assumptions with complex variables (possible BUG)

[Markus Wageringel]

You are probably using Sage with Python 2. In Python 2, a list expression 
involving an index variable `a` like

assume([U_asm[a] for a in [0, 1, 3]])

overwrites the previous content of the variable `a`. At the end of the 
loop, `a` will have the value `3`, which leads to the output you obtained. 
If you rename the loop index to something other than a,b,c,d, the problem 
goes away.

With Python 3, this problem does not exist either, as loop variables are 
local as one would expect. Therefore, I suggest to switch to using Sage 
with Python 3.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0cb37fb2-c5fd-4a57-9574-4d674ef7698a%40googlegroups.com.

[sage-devel] Re: What should happen when we solve a linear system?

[Markus Wageringel]

Over inexact rings, it is generally impossible to determine the rank or to 
check whether a square matrix is singular, so such a check should not be 
done at all, IMO. This implies that the `check` keyword should be ignored. 
This is also what https://trac.sagemath.org/ticket/13932 is about. For 
inexact rings like RDF/CDF, the Matlab behavior is consistent and 
predictable. In particular, the answer does not depend on numerical noise. 
In other words, for near-singular square matrices, the method should _not_ 
attempt to find a least-squares solution, but continue the computation as 
if the matrix was regular (which may lead to a warning or error). 
Otherwise, the output of the method would just be very unpredictable, so 
one would always have to check which type of solution it decided to return.

For inexact rings other than RDF/CDF, other notions of "approximate 
solution" may be more appropriate, but that does not seem to be a problem 
as long as it clearly documented.

For exact rings, it is possible to determine the rank and whether an exact 
solution exists. Therefore, I would expect the method to always return an 
exact solution if it exists and raise an error otherwise, regardless of 
whether the matrix is square or not. The `check` keyword is, in my 
understanding, a detail that helps speed up a computation if one already 
knows a priori that what it would check is unnecessary. Otherwise, the 
output may just be wrong.

I will try to reply to your changes on the ticket soon.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/54c30868-5900-40fb-bac6-d131cfd78112%40googlegroups.com.

Re: [sage-devel] How to deal with cross-references to Sphinx documentation of other projects

[Markus Wageringel]

Yes, the objects.inv files are generated by Sphinx. This is the approach that 
Sage currently follows with pplpy. The documentation is compiled and installed 
by the spkg-postinst of pplpy.

Applying this approach to other packages however is not easily doable. When 
building the numpy documentation for example, numpy will simply download 
missing inventory files and thus connect to the internet.

I am not sure how other distributions work, but Homebrew for example does not 
include documentation files. Packages on PyPI also do not seem to include the 
objects.inv file. So in these cases, resolving cross-references can only work 
if we download missing inventory files or include them with Sage.


> Am 27.02.2020 um 04:06 schrieb Michael Orlitzky :
> 
> On 2/26/20 2:46 PM, Markus Wageringel wrote:
>> 
>> This raises the question of how Sage should deal with these
>> cross-references.
> 
> Presumably those objects.inv files are generated when the documentation
> is built? If the sage documentation is going to link to the numpy
> documentation (for example) and if we want it to work offline, then we
> should build the numpy documentation too. Then we'll have an objects.inv
> file handy when it comes time to build the sage docs, and everything
> will work out.
> 
> If we don't build the numpy documentation (and don't get it from a
> system package), then linking to it won't work offline anyway. Spending
> even more time building the numpy documentation would suck, but we
> should ultimately be convincing people to use their distribution
> packages for things like numpy, and building the documentation is
> essentially free in that case.
> 
> -- 
> 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/h3jkMGhKjBs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/8deec2f8-a389-63f2-722d-5c4a55798b69%40orlitzky.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9CBC66D1-3C37-442E-945D-8EB45339A80C%40gmail.com.

Re: [sage-devel] How to deal with cross-references to Sphinx documentation of other projects

[Markus Wageringel]

This is an interesting suggestion. How would this work with non-interactive 
builds like on the patchbots or in CI? Would the user be asked right before 
downloading, i.e. during the docbuild phase, or perhaps when running configure, 
so it can fail early?

> Am 27.02.2020 um 03:30 schrieb Kwankyu Lee :
> 
>  At the same time, Sage is trying to move away from Sage-the-distribution, so 
> that packaging third-party inventory files for offline use in Sage is 
> undesirable as well, not to mention the maintenance overhead this would 
> entail.
> 
> 3. Ask by default before downloading missing inventory files including 
> python3.inv and adding a docbuild option `--yes-download` to prevent asking. 
> 
> 
> 
> -- 
> 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/h3jkMGhKjBs/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> sage-devel+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/35dacff1-b715-445f-ae89-6aa4da22c212%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/35A48AC4-9410-4B96-8B69-4F622D14F65B%40gmail.com.

[sage-devel] How to deal with cross-references to Sphinx documentation of other projects

[Markus Wageringel]

This came up in #29231 , and #27164 
 is related.

Several packages included with Sage use Sphinx for their documentation 
(such as numpy, scipy, sympy, matplotlib, pplpy, cypari, cysignals). For 
the quality of our documentation, it would be nice to have more 
cross-references to the online documentation of some of those projects. 
Sphinx supports this via the intersphinx extension 
, 
which we already use for Python cross-references, for example, so that 
markup like :func:`map` is turned into a hyperlink to the corresponding 
Python documentation page.

The way this works is that every Sphinx project provides an inventory file 
`objects.inv` containing mappings of objects that can be cross-referenced. 
Those inventory files are then inspected during our documentation build in 
order to resolve missing references. For Python and pplpy, the inventory 
files exist locally in Sage, which are the only ones used by Sage so far, 
but for other projects they can only be found online. Intersphinx can be 
configured to use local inventory files or to download them.

It was brought up that building Sage should in principle work without an 
internet connection, so that downloading inventory files during the 
documentation build is suboptimal. At the same time, Sage is trying to move 
away from Sage-the-distribution, so that packaging third-party inventory 
files for offline use in Sage is undesirable as well, not to mention the 
maintenance overhead this would entail.

This raises the question of how Sage should deal with these 
cross-references. My suggestion would be to do one of the following:

1. Allow the documentation build to trigger internet connections to 
download inventory files. If a download fails, we could either raise an 
error, or ignore it and just not resolve cross-links. The former is the 
approach that projects like numpy, scipy and matplotlib take.

2. Add a docbuild option to optionally enable downloading inventory files, 
similar to the `--no-plot` docbuild option for example. This way, the 
documentation would by default build without internet connection and 
without resolving cross-references to other projects. However, the option 
could be enabled for building the documentation files that are put on our 
website, which is presumably where most people read the Sage documentation.

Comments and other suggestions are very welcome. Thanks.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e9ce9095-a07f-42d0-95c7-01f3ed16a740%40googlegroups.com.

[sage-devel] Re: Poll: make giacpy_sage a standard package

[Markus Wageringel]

Giacpy_sage provides C-bindings for Giac which is already a standard 
package. So making Giacpy_sage a standard package as well would allow to 
replace pexpect calls to Giac by C-calls, which is the overarching goal of 
#16688. Giac is currently used as fallback for symbolic integration where 
this change would be useful (see also #28913). In addition, Gröbner basis 
computations already use Giacpy_sage as alternative backend, so this would 
become more accessible if the package type is changed to standard.

Therefore,
+1 from me.


Am Dienstag, 4. Februar 2020 06:32:43 UTC+1 schrieb Simon King:
>
> Hi Samuel, 
>
> On 2020-02-03, Samuel Lelievre > 
> wrote: 
> > Please vote for making giacpy_sage a standard package. 
>
> Could you elaborate what giacpy is about, i.e., what functionality would 
> it add to SageMath resp. improve in SageMath? That question isn't 
> addressed on the ticket yet. 
>
> Best regards, 
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/efcae77d-6fc3-44eb-a65f-5aa14297ea4b%40googlegroups.com.

Re: [sage-devel] How to deal with unsorted output of dictionaries in doctests

[Markus Wageringel]

I have opened https://trac.sagemath.org/ticket/29136 
 proposing to change the default text 
display preference to "plain" for the text-based backends.


> Am 30.01.2020 um 22:17 schrieb Nils Bruin :
> 
> I do not think that's an issue at all. Presently, on the command line we 
> *literally* get
> 
> sage: pretty_print({1:2})
> \newcommand{\Bold}[1]{\mathbf{#1}}\left\{1 : 2\right\}
> 
> I don't think that satisfies anybody's idea of "pretty" printing. If you do 
> the same thing in the notebook, you get a nicely mathjax typeset expression. 
> We can't replicate that behaviour on the command line anyway, so going with 
> "plain" wouldn't break anything: commandline and notebook already behave very 
> differently.
> 
> It is the case that
> 
>   get_display_manager().preferences.text is None
> 
> holds in both at the moment, but we have that 
> 
>   get_display_manager()
> 
> prints as 'The Sage display manager using the IPython command line backend' 
> and 'The Sage display manager using the IPython notebook backend' 
> respectively, so they're already distinguishable. Setting different defaults 
> in these different cases doesn't seem like a problem to 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/F6865780-C57D-40C2-A633-93AA90F5668A%40gmail.com.

Re: [sage-devel] Error building Sage 9.0 on CentOS 7.5

[Markus Wageringel]

Rather than unsetting TERM, you could add set enable-meta-key off to your 
.inputrc file to solve this. I had the same problem here 
.


Am Freitag, 31. Januar 2020 23:26:17 UTC+1 schrieb Josh Bevan:
>
> I "unset TERM" and that worked, currently a hundred something tests deep 
> with no failures.
>
> Thanks again for your help!
> Josh
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a19edb5b-9a1a-45e4-8373-eb812e5abdd9%40googlegroups.com.

Re: [sage-devel] How to deal with unsorted output of dictionaries in doctests

[Markus Wageringel]

> Am 30.01.2020 um 23:10 schrieb Michael Orlitzky :
> 
> This is a good point, but it's a problem we already have. We don't make
> any promises about the precise message contained in e.g. a ValueError,
> but we still frequently test the contents. You just update it when you
> change the message. The doctest is more of a sanity check here, telling
> you that you've got two different answers and to go figure out which one
> is right. If the code is right, you update the doctest.

I agree a doctest is easily updated when things change, but errors could easily 
be introduced as well. Ideally a test is written in a way that it does not test 
more than necessary – and the iteration order of dictionaries usually does not 
need to be tested.

> The downside to sorting everything in the tests it that running the
> tests already takes several hours (8+ here). How many CPU hours do we
> collectively burn by sorting something 1293752893 times instead of
> updating the test once?

Although there are many tests outputting dictionaries, these are usually very 
small, so I do not expect this to have a big impact on running times. Besides, 
dictionaries are currently sorted via IPython during testing as well.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5318CC36-7274-4849-9CDF-616405786930%40gmail.com.

Re: [sage-devel] How to deal with unsorted output of dictionaries in doctests

[Markus Wageringel]

Rather than distinguishing the different backends, I was more worried about how 
to keep what related doctests currently give us. For example, in 
src/doc/fr/tutorial/latex.rst, pretty_print is advertised as a way to obtain 
nicely formatted MathJax output:

sage: pretty_print(x^12)
\newcommand{\Bold}[1]{\mathbf{#1}}x^{12}

I suppose this is exactly what is used in the notebook to format the output. If 
the default display mode was `plain`, I would not know how to rephrase this 
doctest other than changing the display mode before and after the test, which 
is suboptimal in the tutorials.

Admittedly though, with the command line backend, the same command outputs

sage: pretty_print(x^12)
\newcommand{\Bold}[1]{\mathbf{#1}}x^{12}

so arguably a dichotomy is already there. With display mode `plain`, we get

sage: pretty_print(x^12)
x^12

which is the same as just printing the object.

It seems generally difficult, if not impossible, to write tests for different 
backends, as we only use the doctest backend during doctests. Though, I assume 
that the MathJax output is sufficiently tested elsewhere, so changing the 
default behavior of pretty_print for the commandline and doctests should not be 
a problem after all.


> Am 30.01.2020 um 22:21 schrieb Nils Bruin :
> 
> On Thursday, January 30, 2020 at 1:17:14 PM UTC-8, Nils Bruin wrote:
> prints as 'The Sage display manager using the IPython command line backend' 
> and 'The Sage display manager using the IPython notebook backend' 
> respectively, so they're already distinguishable. Setting different defaults 
> in these different cases doesn't seem like a problem to me.
> 
> Oops, and as the documentation of display_manager says, in doctests, you get 
> back: 'The Sage display manager using the doctest backend', so there's a 
> third one! Perhaps we should try and keep that one aligned with the command 
> line, since those both communicate through character streams (whereas the 
> notebook one communicates through a message passing 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/B3C05557-4D6F-4B5F-9ABA-4493A5CDBB2E%40gmail.com.

Re: [sage-devel] How to deal with unsorted output of dictionaries in doctests

[Markus Wageringel]

Am Dienstag, 28. Januar 2020 00:41:55 UTC+1 schrieb Michael Orlitzky:
>
> The insertion order is part of the language as of python-3.7, and can't 
> be changed: 
>
> * https://mail.python.org/pipermail/python-dev/2017-December/151283.html 
> * https://docs.python.org/3.7/tutorial/datastructures.html#dictionaries 
>
> So while it sucks, I guess we should update all of the doctests to print 
> in that order. It was always a bad idea to rely on them being sorted, 
> and I don't think I agree with making the order part of the language, 
> but that's what we've got. 
>

While the order of dictionaries is insertion order now, functions in Sage 
or in libraries that return dictionaries usually do not make any promise 
about the order in which elements are inserted into the dictionary. Thus, 
when doctesting such a function, the order of the result is not specified 
and might easily change by a seemingly unrelated change in our code base. 
This is not a huge problem, as we can update any failing doctests, but we 
could also make the doctests more robust in the first place, by sorting the 
output.



>From the different options mentioned here, my preferred choices are

2c) `pretty_print(D, sort=True)` for clarity, or

2d) `dict(sorted(D.items()))` for simplicity, as this makes use of 
well-known functions and does not require any other changes.

As Nils explained, for 2c (and even independently) it would make sense to 
change the default display mode from `None` to `plain` in the command line, 
but this would lead to a small dichotomy between the command line and the 
notebook, which is why I am slightly hesistant about this. It would make it 
a bit more difficult to doctest the notebook behavior. Therefore, I am 
leaning toward 2d, which should be an uncontroversial change and is similar 
to the `sorted(...)` idiom already used in the doctests.
 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/01d7ee8c-7e7c-4426-be3f-24d9161bd58f%40googlegroups.com.

Re: [sage-devel] 9.1.beta0: build problem using Homebrew's openblas

[Markus Wageringel]

I manually set those CVXOPT_... variables in the spkg-install file for now and 
building cvxopt then succeeded.

Building Sage now almost completes, but the file src/sage/libs/readline.pyx 
fails to compile with these errors:


[1/1] gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g 
-fwrapv -O3 -Wall -Wno-unused -I./sage/cpython -Isage/cpython 
-I/Applications/SageMath/local/include -I/Applications/SageMath/src 
-I/Applications/SageMath/src/sage/ext 
-I/Applications/SageMath/local/include/python3.7m 
-I/Applications/SageMath/local/lib/python3.7/site-packages/numpy/core/include 
-Ibuild/cythonized -I/Applications/SageMath/local/include/python3.7m -c 
build/cythonized/sage/libs/readline.c -o 
build/temp.macosx-10.9-x86_64-3.7/build/cythonized/sage/libs/readline.o 
-fno-strict-aliasing -DCYTHON_CLINE_IN_TRACEBACK=1 -std=c99
build/cythonized/sage/libs/readline.c:1446:36: error: use of undeclared 
identifier 'rl_catch_signals'
  __pyx_t_1 = __Pyx_PyInt_From_int(rl_catch_signals); if 
(unlikely(!__pyx_t_1)) __PYX_ERR(0, 87, __pyx_L1_error)
   ^
build/cythonized/sage/libs/readline.c:1468:36: error: use of undeclared 
identifier 'rl_catch_sigwinch'
  __pyx_t_1 = __Pyx_PyInt_From_int(rl_catch_sigwinch); if 
(unlikely(!__pyx_t_1)) __PYX_ERR(0, 88, __pyx_L1_error)
   ^
build/cythonized/sage/libs/readline.c:1542:36: warning: implicit 
declaration of function 'rl_set_signals' is invalid in C99 
[-Wimplicit-function-declaration]
  __pyx_t_1 = __Pyx_PyInt_From_int(rl_set_signals()); if 
(unlikely(!__pyx_t_1)) __PYX_ERR(0, 104, __pyx_L1_error)
   ^
build/cythonized/sage/libs/readline.c:1604:36: warning: implicit 
declaration of function 'rl_clear_signals' is invalid in C99 
[-Wimplicit-function-declaration]
  __pyx_t_1 = __Pyx_PyInt_From_int(rl_clear_signals()); if 
(unlikely(!__pyx_t_1)) __PYX_ERR(0, 120, __pyx_L1_error)
   ^
build/cythonized/sage/libs/readline.c:1849:36: error: passing 'void' to 
parameter of incompatible type 'int'
  __pyx_t_1 = __Pyx_PyInt_From_int(rl_forced_update_display()); if 
(unlikely(!__pyx_t_1)) __PYX_ERR(0, 190, __pyx_L1_error)
   ^~
...


The Homebrew readline is version 8.0.1. In particular, the header file 
`/usr/local/opt/readline/include/readline/readline.h` does contain 
`rl_catch_signals`, `rl_catch_sigwinch` and `rl_clear_signals`.

The system readline in `/usr/include/readline/readline.h` does not contain 
these though, so it looks like that is used instead.


> Am 12.01.2020 um 10:58 schrieb Dima Pasechnik :
> 
> On Sun, Jan 12, 2020 at 12:10 AM Markus Wageringel
> mailto:markus.wagerin...@gmail.com>> wrote:
>> 
>> On macOS 10.13.6, trying to make use of #27870 using Homebrew's openblas, 
>> the build fails for me at cvxopt:
>> 
>>gcc -bundle -undefined dynamic_lookup -L/Applications/SageMath/local/lib 
>> -Wl,-rpath,/Applications/SageMath/local/lib -L/usr/local/opt/openssl/lib -L. 
>> -L/Applications/SageMath/local/lib 
>> -Wl,-rpath,/Applications/SageMath/local/lib -L/usr/local/opt/openssl/lib 
>> -L/Applications/SageMath/local/lib 
>> -Wl,-rpath,/Applications/SageMath/local/lib 
>> build/temp.macosx-10.9-x86_64-3.7/src/C/gsl.o -L/Applications/SageMath/local 
>> -L/Applications/SageMath/local -L/Applications/SageMath/local/lib -lm -lgsl 
>> -lopenblas -o 
>> build/lib.macosx-10.9-x86_64-3.7/cvxopt/gsl.cpython-37m-darwin.so
>>ld: library not found for -lopenblas
>>clang: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>>error: command 'gcc' failed with exit status 1
>>Running setup.py install for cvxopt: finished with status 'error'
>> 
>> As openblas and readline are keg-only, I ran configure as
>> 
>>./configure \
>>  LDFLAGS="-L/usr/local/opt/readline/lib -L/usr/local/opt/openblas/lib 
>> -L/usr/local/opt/mpfr/lib" \
>>  CPPFLAGS="-I/usr/local/opt/readline/include 
>> -I/usr/local/opt/openblas/include" \
>>  
>> PKG_CONFIG_PATH="/usr/local/opt/readline/lib/pkgconfig:/usr/local/opt/openblas/lib/pkgconfig"
>> 
>> but cvxopt does not seem to use this.
> 
> cvxopt really needs env.vars CVXOPT_BLAS_LIB_DIR, CVXOPT_BLAS_LIB,
> CVXOPT_LAPACK_LIB set, it does not use pkgconf.
> (but it should).
> We can propose an upstream fix for this, and meanwhile set these vars
> in spkg-install

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/BBB346E3-DBD1-44B4-AD7A-5D4B0B9D1BF5%40gmail.com.

Re: [sage-devel] macOS build failure (Singular/mpfr)

[Markus Wageringel]

That worked. The build has finished successfully. Thanks.


> Am 14.12.2019 um 12:47 schrieb Dima Pasechnik
> 
> as a quick fix, try
> 
> export LDFLAGS="-L/usr/local/lib" 
> make
> 
> 
> 
> On Sat, 14 Dec 2019, 11:37 Markus Wageringel,  <mailto:markus.wagerin...@gmail.com>> wrote:
> There is libmpfr.dylib in /usr/local/lib.
> 
> 
> Am Samstag, 14. Dezember 2019 12:28:49 UTC+1 schrieb Dima Pasechnik:
> where is mpfr.dylib ? in /usr/local/lib ?
> 
> also, on OSX  I always do
> 
> CC=clang CXX=clang++ FC=gfortran ./configure
> 
> to make sure the compilers are right.
> 
> 
> On Sat, 14 Dec 2019, 11:07 Markus Wageringel, > 
> wrote:
> Hi everyone,
> 
> trying to build 9.0.beta9 from scratch on macOS 13.6, the build fails for me 
> while building Singular. There seems to be a problem with linking to the 
> system mpfr. I have Homebrew's mpfr. The Sage and Singular config logs are 
> attached. Also, I am not sure if it is relevant, but I installed flint and 
> arb via brew from dimpase/science/ yesterday.
> 
> Any help in solving this would be appreciated. Thank you.
> 
> Markus
> 
> ...
> [singular-4.1.1p2.p0] /bin/bash ../../../libtool  --tag=CXX   --mode=link g++ 
> -std=gnu++11 
> -I/usr/local/Cellar/python@2/2.7.17/Frameworks/Python.framework/Versions/2.7/include/python2.7
>  -O2 -g  -pipe -fno-common -g0 -O3 -Wno-unused-function -Wno-trigraphs 
> -Wno-unused-parameter -Wunknown-pragmas -Wno-unused-variable 
> -fomit-frame-pointer -fwrapv -fvisibility=default -finline-functions 
> -fno-exceptions -fno-threadsafe-statics -funroll-loops -fno-rtti 
> -Qunused-arguments   -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
>  -F/usr/local/opt/python@2/Frameworks -u _PyMac_Error 
> /usr/local/opt/python@2/Frameworks/Python.framework/Versions/2.7/Python
> -module-export-dynamic -avoid-version -flat_namespace 
> -weak_reference_mismatches weak -undefined dynamic_lookup  
> -L/Applications/SageMath/local/lib 
> -Wl,-rpath,/Applications/SageMath/local/lib  -pipe -fno-common -g0 -O3 
> -Wno-unused-function -Wno-trigraphs -Wno-unused-parameter -Wunknown-pragmas 
> -Wno-unused-variable -fomit-frame-pointer -fwrapv -fvisibility=default 
> -finline-functions -fno-exceptions -fno-threadsafe-statics -funroll-loops 
> -Qunused-arguments  -rdynamic -flat_namespace -Wl,-bind_at_load 
> -Wl,-undefined,dynamic_lookup -o pyobject.la -rpath 
> /Applications/SageMath/local/libexec/singular/MOD pyobject_la-pyobject.lo  
> -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
>  -F/usr/local/opt/python@2/Frameworks -u _PyMac_Error 
> /usr/local/opt/python@2/Frameworks/Python.framework/Versions/2.7/Python
> -lreadline -lncurses -lmpfr
> [singular-4.1.1p2.p0] libtool: link: g++ -std=gnu++11 -Wl,-undefined 
> -Wl,dynamic_lookup -o .libs/pyobject.so -bundle  .libs/pyobject_la-pyobject.o 
>   -L/Applications/SageMath/local/lib -lreadline -lncurses -lmpfr  -O2 -g -g0 
> -O3 -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
>  -F/usr/local/opt/python@2/Frameworks -Wl,-rpath 
> -Wl,/Applications/SageMath/local/lib -g0 -O3 -Wl,-bind_at_load -Wl,-undefined 
> -Wl,dynamic_lookup -isysroot 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
>  -F/usr/local/opt/python@2/Frameworks
> [singular-4.1.1p2.p0] ld: library not found for -lmpfr
> [singular-4.1.1p2.p0] clang: error: linker command failed with exit code 1 
> (use -v to see invocation)
> [singular-4.1.1p2.p0] make[7]: *** [pyobject.la] Error 1
> [singular-4.1.1p2.p0] make[6]: *** [all-recursive] Error 1
> [singular-4.1.1p2.p0] make[5]: *** [all-recursive] Error 1
> [singular-4.1.1p2.p0] make[4]: *** [all] Error 2
> [singular-4.1.1p2.p0] make[3]: *** [all-recursive] Error 1
> [singular-4.1.1p2.p0] make[2]: *** [all] Error 2
> [singular-4.1.1p2.p0] 
> 
> [singular-4.1.1p2.p0] Error building singular-4.1.1p2.p0
> [singular-4.1.1p2.p0] 
> 
> 
> 
> -- 
> 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-...@googlegroups.com <>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/d5604d56-31d3-484b-9636-a547fb39c376%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/sage-devel/d5

Re: [sage-devel] macOS build failure (Singular/mpfr)

[Markus Wageringel]

There is libmpfr.dylib in /usr/local/lib.


Am Samstag, 14. Dezember 2019 12:28:49 UTC+1 schrieb Dima Pasechnik:
>
> where is mpfr.dylib ? in /usr/local/lib ?
>
> also, on OSX  I always do
>
> CC=clang CXX=clang++ FC=gfortran ./configure
>
> to make sure the compilers are right.
>
>
> On Sat, 14 Dec 2019, 11:07 Markus Wageringel,  > wrote:
>
>> Hi everyone,
>>
>> trying to build 9.0.beta9 from scratch on macOS 13.6, the build fails for 
>> me while building Singular. There seems to be a problem with linking to the 
>> system mpfr. I have Homebrew's mpfr. The Sage and Singular config logs are 
>> attached. Also, I am not sure if it is relevant, but I installed flint and 
>> arb via brew from dimpase/science/ yesterday.
>>
>> Any help in solving this would be appreciated. Thank you.
>>
>> Markus
>>
>> ...
>> [singular-4.1.1p2.p0] /bin/bash ../../../libtool  --tag=CXX   --mode=link 
>> g++ -std=gnu++11 -I/usr/local/Cellar/python@2/2.7.17/Frameworks/Python.
>> framework/Versions/2.7/include/python2.7 -O2 -g  -pipe -fno-common -g0 -O3 
>> -Wno-unused-function -Wno-trigraphs -Wno-unused-parameter -Wunknown-pragmas 
>> -Wno-unused-variable -fomit-frame-pointer -fwrapv -fvisibility=default -
>> finline-functions -fno-exceptions -fno-threadsafe-statics -funroll-loops 
>> -fno-rtti -Qunused-arguments   -isysroot /Applications/Xcode.app/Contents
>> /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -F/
>> usr/local/opt/python@2/Frameworks -u _PyMac_Error /usr/local/opt/python@2
>> /Frameworks/Python.framework/Versions/2.7/Python-module -export-
>> dynamic -avoid-version -flat_namespace -weak_reference_mismatches weak -
>> undefined dynamic_lookup  -L/Applications/SageMath/local/lib -Wl,-rpath,
>> /Applications/SageMath/local/lib  -pipe -fno-common -g0 -O3 -Wno-unused-
>> function -Wno-trigraphs -Wno-unused-parameter -Wunknown-pragmas -Wno-
>> unused-variable -fomit-frame-pointer -fwrapv -fvisibility=default -
>> finline-functions -fno-exceptions -fno-threadsafe-statics -funroll-loops 
>> -Qunused-arguments  -rdynamic -flat_namespace -Wl,-bind_at_load -Wl,-
>> undefined,dynamic_lookup -o pyobject.la -rpath /Applications/SageMath/
>> local/libexec/singular/MOD pyobject_la-pyobject.lo  -isysroot /
>> Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/
>> Developer/SDKs/MacOSX10.14.sdk -F/usr/local/opt/python@2/Frameworks -u 
>> _PyMac_Error /usr/local/opt/python@2/Frameworks/Python.framework/Versions
>> /2.7/Python-lreadline -lncurses -lmpfr
>> [singular-4.1.1p2.p0] libtool: link: g++ -std=gnu++11 -Wl,-undefined 
>> -Wl,dynamic_lookup 
>> -o .libs/pyobject.so -bundle  .libs/pyobject_la-pyobject.o   -L/
>> Applications/SageMath/local/lib -lreadline -lncurses -lmpfr  -O2 -g -g0 -O3 
>> -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
>> platform/Developer/SDKs/MacOSX10.14.sdk -F/usr/local/opt/python@2/
>> Frameworks -Wl,-rpath -Wl,/Applications/SageMath/local/lib -g0 -O3 
>> -Wl,-bind_at_load 
>> -Wl,-undefined -Wl,dynamic_lookup -isysroot /Applications/Xcode.app/
>> Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.
>> 14.sdk -F/usr/local/opt/python@2/Frameworks
>> [singular-4.1.1p2.p0] ld: library not found for -lmpfr
>> [singular-4.1.1p2.p0] clang: error: linker command failed with exit code 
>> 1 (use -v to see invocation)
>> [singular-4.1.1p2.p0] make[7]: *** [pyobject.la] Error 1
>> [singular-4.1.1p2.p0] make[6]: *** [all-recursive] Error 1
>> [singular-4.1.1p2.p0] make[5]: *** [all-recursive] Error 1
>> [singular-4.1.1p2.p0] make[4]: *** [all] Error 2
>> [singular-4.1.1p2.p0] make[3]: *** [all-recursive] Error 1
>> [singular-4.1.1p2.p0] make[2]: *** [all] Error 2
>> [singular-4.1.1p2.p0] 
>> 
>> [singular-4.1.1p2.p0] Error building singular-4.1.1p2.p0
>> [singular-4.1.1p2.p0] 
>> 
>>
>> -- 
>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/d5604d56-31d3-484b-9636-a547fb39c376%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/d5604d56-31d3-484b-9636-a547fb39c376%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4de68710-467f-442e-ac33-5d7cfe0c4845%40googlegroups.com.

[sage-devel] Re: Escape sequence in doctest output using Xterm/readline

[Markus Wageringel]

Thank you for the explanation. I confirm that adding set enable-meta-key off to 
my .inputrc file solves the problem.


Am Samstag, 16. November 2019 23:03:32 UTC+1 schrieb 
dic...@invisible-island.net:
>
> That 1034 stuff turns on *meta-mode*, which is not a new feature (about 
> twelve years).
> The ncurses FAQ *Alt-keys do not work in bash* 
>  
> gives some background.
> I'd expect unsetting TERM rather than setting it to some less featureful 
> terminal description would be a step backward.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5eb2e758-d08a-4d18-9dc0-239640727b78%40googlegroups.com.

[sage-devel] Escape sequence in doctest output using Xterm/readline

[Markus Wageringel]

On CentOS 7.7, I see a large number of doctest failures due to the escape 
sequence  appearing in the output. For example:

./sage -t --long src/sage/combinat/tableau.py
**
File "src/sage/combinat/tableau.py", line 2850, in sage.combinat.tableau.
Tableau.row_stabilizer
Failed example:
rs.order() == factorial(3)*factorial(2)
Expected:
True
Got:
True
**

This is a problem with readline in combination with xterm. A workaround is 
to unset $TERM before running the tests. A similar problem was described in 
#12263.

This can also be avoided by running configure with 
--with-system-readline=no, so that Sage builds readline 6.3. The system 
version is 6.2 according to:

sage: import readline
sage: readline._READLINE_LIBRARY_VERSION
6.2

This problem has only started appearing recently (probably when the system 
was upgraded from CentOS 7.6 to 7.7) as Sage always built its own readline 
before.

I am not sure whether this is something for Sage to solve, but maybe this 
information is useful in case someone has the same problem.

Markus

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5f097f3b-af2d-4e59-ad44-44c0824cfc0a%40googlegroups.com.

[sage-devel] Sporadic build failure of zope_interface-4.6.0 and entrypoints-0.3

[Markus Wageringel]

When building 9.0beta3 (or 9.0beta2) in parallel on two CentOS machines, I 
once got the following two build failures that I do not know how to 
resolve. Starting the build process again made the build complete 
successfully, so it looks like these packages do not list all their 
dependencies.

Installing zope_interface-4.6.0
Traceback (most recent call last):
  File "setup.py", line 26, in 
from setuptools import setup, Extension, Feature
  File 
"/amd/compute/mwagerin/git/sage_compute/python3/local/lib/python3.7/site-packages/setuptools/__init__.py"
, line 16, in 
import setuptools.version
  File 
"/amd/compute/mwagerin/git/sage_compute/python3/local/lib/python3.7/site-packages/setuptools/version.py"
, line 1, in 
import pkg_resources
  File 
"/amd/compute/mwagerin/git/sage_compute/python3/local/lib/python3.7/site-packages/pkg_resources/__init__.py"
, line 3126, in 
@_call_aside
  File 
"/amd/compute/mwagerin/git/sage_compute/python3/local/lib/python3.7/site-packages/pkg_resources/__init__.py"
, line 3110, in _call_aside
f(*args, **kwargs)
  File 
"/amd/compute/mwagerin/git/sage_compute/python3/local/lib/python3.7/site-packages/pkg_resources/__init__.py"
, line 3162, in _initialize_master_working_set
list(map(working_set.add_entry, sys.path))
  File 
"/amd/compute/mwagerin/git/sage_compute/python3/local/lib/python3.7/site-packages/pkg_resources/__init__.py"
, line 621, in add_entry
for dist in find_distributions(entry, True):
  File 
"/amd/compute/mwagerin/git/sage_compute/python3/local/lib/python3.7/site-packages/pkg_resources/__init__.py"
, line 1968, in find_on_path
for dist in factory(fullpath):
  File 
"/amd/compute/mwagerin/git/sage_compute/python3/local/lib/python3.7/site-packages/pkg_resources/__init__.py"
, line 2030, in distributions_from_metadata
if len(os.listdir(path)) == 0:
FileNotFoundError: [Errno 2] No such file or directory: 
'/amd/compute/mwagerin/git/sage_compute/python3/local/lib/python3.7/site-packages/mpmath-1.1.0-py3.7.egg-info'
Error: could not determine package name

Error installing zope_interface-4.6.0



Installing entrypoints-0.3
Traceback (most recent call last):
  File "setup.py", line 6, in 
from entrypoints import __version__ as v
  File 
"/export/compute/mwagerin/git/sage/python2/local/var/tmp/sage/build/entrypoints-0.3/src/entrypoints.py"
, line 19, in 
from backports import configparser
ImportError: No module named backports
Error: could not determine package name

Error installing entrypoints-0.3


The first occured with a Python 3 build, the other with a Python 2 build in 
case it matters.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6bb6547d-9041-46c2-b586-8b57fb33666c%40googlegroups.com.

[sage-devel] Re: A Sage interface for FGb (Gröbner bases)

[Markus Wageringel]

Hi David,

my bad, I had forgotten to update the gist. I have just updated it, see 
[1]. There I used Singular (not libSingular), which usually should not make 
much of a difference for this kind of computation. However, note that there 
are some concerning speed issues with Singular/libSingular in Sage which I 
mentioned at [2] and do not know how to solve. Therefore, it may be worth 
comparing with libSingular as well. The equivalent libSingular call would 
be something like this:

from sage.libs.singular.function_factory import ff
modStd = ff.modstd__lib.modStd
ff.setcores(4)
I = sage.rings.ideal.Cyclic(PolynomialRing(QQ, 'x', 7))
gb = modStd(I)

whereas with Singular:

singular.load('modstd')
singular.setcores(4)
I = sage.rings.ideal.Cyclic(PolynomialRing(QQ, 'x', 7))
J = singular.modStd(I).sage()

[1] https://gist.github.com/mwageringel/213a4a980e338ec8ea5a75482b1bcb2b
[2] https://groups.google.com/d/msg/sage-devel/iO1SzoW0kcw/NJYUMSPOCgAJ

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b8afe92a-ef37-4eb8-a75e-25d9e5047efc%40googlegroups.com.

Re: [sage-devel] docker images "latest" and "develop" are old

[Markus Wageringel]

There also appears to be a problem with the credentials, causing the last 
step, pushing the image to DockerHub, to silently fail. For example, this 
is the log for the last run on the develop branch [1], which last ran for 
8.8.rc1.

$ sh .ci/push-dockerhub.sh sagemath
+ sh .ci/push-dockerhub.sh sagemath
+ '[' -z develop ]
+ '[' -z  -o -z  ]
+ echo 'DOCKER_USER/SECRET_DOCKER_PASS variables have not been configured 
in your Continuous Integration setup. Not pushing built images to Docker 
Hub.'
DOCKER_USER/SECRET_DOCKER_PASS variables have not been configured in your 
Continuous Integration setup. Not pushing built images to Docker Hub.
Job succeeded

I am not sure why this has not run for any more recent updates to the 
develop branch, though. The sagemath:develop image at [2] is up to date at 
least. Perhaps, the develop branch in the gitlab mirror just does not get 
updated regularly.


[1] https://gitlab.com/sagemath/sage/-/jobs/231098209
[2] https://gitlab.com/sagemath/dev/trac/container_registry


Am Freitag, 26. Juli 2019 16:28:02 UTC+2 schrieb E. Madison Bray:
>
> On Thu, Jul 25, 2019 at 10:49 PM Vincent Delecroix 
> <20100.d...@gmail.com > wrote: 
> > 
> > Dear all, 
> > 
> > According to the page [docker] the images with tag "latest" and 
> > "develop" are supposed to be the latest stable and development 
> > versions. However sagemath/sagemath-dev:latest is stuck at 8.7 
> > while 8.8 is released since July 7th (and the corresponding 
> > docker image is available on docker hub). Similarly, 
> > sagemath/sagemath-dev:develop is 8.8.beta5 while we are now 
> > at 8.9.beta3 (8.9.beta2 is available on docker but not 
> > 8.9.beta3). 
> > 
> > Shouldn't "latest" and "develop" be automatically updated? 
> > 
> >   [docker] https://hub.docker.com/u/sagemath/sagemath 
>
> According to one of the build scripts [1], if the "master" branch is 
> built, it will be tagged as "latest".  I'm not sure about "develop". 
> Apparently, although the build for the 8.8 *tag* completed 
> successfully [2], the one for "master" (at 8.8) failed sort of 
> randomly [3], due to a problem we've been seeing where `make` is 
> taking longer and longer (and longer than it should) so the build 
> times out.  Need to investigate why it's taking so much longer. 
>
> In general, it would certainly be welcome to have more volunteers 
> monitoring and debugging issues with the CI pipeline, since getting 
> this working smoothly would be a huge benefit.  But we haven't had 
> enough resources or people looking at it... 
>
> [1] 
> https://gitlab.com/sagemath/sage/blob/b5c9cf037cbce672101725f269470135b9b2c5c4/.ci/update-env.sh#L37
>  
> [2] https://gitlab.com/sagemath/sage/pipelines/68209174 
> [3] https://gitlab.com/sagemath/sage/pipelines/68212724 
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f942b790-1f4d-4e01-8c5f-8ce4033e180c%40googlegroups.com.

[sage-devel] Re: Possible to use current Sage version in travis-ci?

[Markus Wageringel]

Usually, the latest beta should be available as sagemath/sagemath:develop 
at DockerHub. However, for some reason this tag has not been updated in a 
while, so it still points to 8.8.beta5. See also 
https://groups.google.com/forum/#!topic/sage-devel/hHWlOluXtos.

It is also possible to use the docker image 
registry.gitlab.com/sagemath/dev/trac/sagemath:develop from gitlab which is 
up-to-date with the latest beta. Though, I am not sure whether this is 
officially supported.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5fd126d6-726d-420f-8b69-e0f4ac1a6229%40googlegroups.com.

[sage-devel] Re: How to use spkg-install in a travis-ci script?

[Markus Wageringel]

I think it would be good to keep the install script for Travis-CI as close 
as possible to what you would normally do to install a package in Sage, 
that is, create an updated tarball of your repository and copy it to 
upstream/, update the checksums and then install it with sage -i. This way, 
Sage will handle the details of running the spkg-install script. You can 
set a custom docker entrypoint to avoid running everything inside a Sage 
subshell, see for example here 
,
 
though I used pip for installing the package.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/11a16baa-5537-4167-9f3d-796297c717d0%40googlegroups.com.

Re: [sage-devel] giacpy_sage fails to install

[Markus Wageringel]

Thanks for the explanation. This is now #28082 
.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/80615bfa-aa50-474b-b900-23c177969852%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: giacpy_sage fails to install

[Markus Wageringel]

Oh, I do that for developing. Yet, although I am looking forward to using 
Python 3, I prefer to have a reliable stable install as well. I had some 
trouble with compiling the betas a few times in the past when I ended up 
without a working copy of Sage. The full compilation process takes hours on 
my laptop, so I usually try to avoid it.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e95cbead-3cca-467e-b242-f678b47c9f2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] giacpy_sage fails to install

[Markus Wageringel]

I have just tried to upgrade my main Sage install from 8.7 to 8.8, but the 
optional package Giacpy_sage fails to build. The logs mention several 
errors reported by gcc – the log file is attached. This is on OS X 10.13.6 
with Clang 10.0.0, but I have observed this problem on a Linux machine as 
well (where I also tried a clean install, but the package still does not 
build). This is odd, as Giacpy_sage has not been changed since 8.7.

Best,
Markus

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5f4ace6f-e0dd-46d5-81e4-750a2ed2800a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Found local metadata for giacpy_sage-0.6.7
Using cached file /Applications/SageMath/upstream/giacpy_sage-0.6.7.tar.gz
giacpy_sage-0.6.7

Setting up build directory for giacpy_sage-0.6.7
Finished extraction
No patch files found in ../patches

Host system:
Darwin markus-2.local 17.7.0 Darwin Kernel Version 17.7.0: Wed Apr 24 21:17:24 
PDT 2019; root:xnu-4570.71.45~1/RELEASE_X86_64 x86_64

C compiler: gcc
C compiler version:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Package 'giacpy_sage' is currently not installed
No legacy uninstaller found for 'giacpy_sage'; nothing to do
Deleting /Applications/SageMath/local/lib/python*/site-packages/giacpy-*
Deleting /Applications/SageMath/local/lib/python*/site-packages/giacpy.so
Deleting /Applications/SageMath/local/lib/python*/site-packages/giacpy_sage*
Installing giacpy_sage-0.6.7
/Applications/SageMath/local/lib/python2.7/site-packages/Cython/Compiler/Main.py:367:
 FutureWarning: Cython directive 'language_level' not set, using 2 for now 
(Py2). This will change in a later release! File: 
/Applications/SageMath/local/var/tmp/sage/build/giacpy_sage-0.6.7/src/giacpy_sage.pxd
  tree = Parsing.p_module(s, pxd, full_module_name)
Warning: This package has a badly-behaved setup.py which outputs
more than the package name for 'setup.py --name'; using the last
line as the package name: giacpy_sage
Installing package giacpy_sage using pip2
Ignoring indexes: https://pypi.org/simple
Created temporary directory: 
/private/var/folders/f1/dnhtvscx21sc9_bnlkbxhjmrgn/T/pip-ephem-wheel-cache-2SXDAj
Created temporary directory: 
/private/var/folders/f1/dnhtvscx21sc9_bnlkbxhjmrgn/T/pip-req-tracker-qjDBgf
Created requirements tracker 
'/private/var/folders/f1/dnhtvscx21sc9_bnlkbxhjmrgn/T/pip-req-tracker-qjDBgf'
Created temporary directory: 
/private/var/folders/f1/dnhtvscx21sc9_bnlkbxhjmrgn/T/pip-install-W47tqA
Processing /Applications/SageMath/local/var/tmp/sage/build/giacpy_sage-0.6.7/src
  Created temporary directory: 
/private/var/folders/f1/dnhtvscx21sc9_bnlkbxhjmrgn/T/pip-req-build-axb0ZG
  Added 
file:///Applications/SageMath/local/var/tmp/sage/build/giacpy_sage-0.6.7/src to 
build tracker 
'/private/var/folders/f1/dnhtvscx21sc9_bnlkbxhjmrgn/T/pip-req-tracker-qjDBgf'
  Running setup.py 
(path:/private/var/folders/f1/dnhtvscx21sc9_bnlkbxhjmrgn/T/pip-req-build-axb0ZG/setup.py)
 egg_info for package from 
file:///Applications/SageMath/local/var/tmp/sage/build/giacpy_sage-0.6.7/src
Running command python setup.py egg_info
running egg_info
creating pip-egg-info/giacpy_sage.egg-info
writing pip-egg-info/giacpy_sage.egg-info/PKG-INFO
writing top-level names to pip-egg-info/giacpy_sage.egg-info/top_level.txt
writing dependency_links to 
pip-egg-info/giacpy_sage.egg-info/dependency_links.txt
writing manifest file 'pip-egg-info/giacpy_sage.egg-info/SOURCES.txt'
reading manifest file 'pip-egg-info/giacpy_sage.egg-info/SOURCES.txt'
writing manifest file 'pip-egg-info/giacpy_sage.egg-info/SOURCES.txt'
  Source in 
/private/var/folders/f1/dnhtvscx21sc9_bnlkbxhjmrgn/T/pip-req-build-axb0ZG 
has version 0.6.7, which satisfies requirement giacpy-sage==0.6.7 from 
file:///Applications/SageMath/local/var/tmp/sage/build/giacpy_sage-0.6.7/src
  Removed giacpy-sage==0.6.7 from 
file:///Applications/SageMath/local/var/tmp/sage/build/giacpy_sage-0.6.7/src 
from build tracker 
'/private/var/folders/f1/dnhtvscx21sc9_bnlkbxhjmrgn/T/pip-req-tracker-qjDBgf'

[sage-devel] Re: issues (memory leak + slowness) with multivariate polynomials

[Markus Wageringel]

If I understand the documentation correctly, both cases should call the 
same Singular function (`groebner` in this case), with the only difference 
that one is called through the C interface and the other via the Pexpect 
interface. When I enable the protocol by passing `prot=True`, I get the 
exact same output, except that one prints faster than the other, which 
suggests that in both cases the same computation is run by Singular.

Actually, I was planning to add an option to Sage for calling the Singular 
function `modStd` for the modular approach you mention, when I found this 
speed difference. None of the current options in Sage seem to allow to make 
use of modular computations, except when using Giac.


Am Samstag, 15. Juni 2019 21:34:03 UTC+2 schrieb Bill Hart:
>
> I would guess that `libsingular' is the C++ kernel of Singular which does 
> not implement all strategies for GB's over Q. There are additional 
> strategies implemented both in Singular library code and in the Singular 
> interpreter. Presumably the `singular' interface is using the interpreter, 
> if not a Singular library, which makes use of more advanced strategies. In 
> particular there is a library for a modular approach.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9c034d11-15e0-4ae1-a689-751e039285be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: issues (memory leak + slowness) with multivariate polynomials

[Markus Wageringel]

If I compute a Gröbner basis using libSingular, it is much slower than 
using the Singular interface. Could this be related to the memory leaks or 
is it a different issue?

sage: I = sage.rings.ideal.Katsura(PolynomialRing(QQ, 'x', 9))
sage: %time gb1 = I.groebner_basis(algorithm='singular')
CPU times: user 1.34 s, sys: 47.5 ms, total: 1.38 s
Wall time: 13 s
sage: I = sage.rings.ideal.Katsura(PolynomialRing(QQ, 'x', 9))
sage: %time gb2 = I.groebner_basis(algorithm='libsingular')
CPU times: user 49.2 s, sys: 122 ms, total: 49.4 s
Wall time: 49.4 s
sage: gb1 == gb2
True

This defaults to the Singular function `groebner`, but choosing others like 
`std` or `slimgb` gives similar timings.

Over finite fields, the above issue does not seem to occur – the 
libSingular computation is slightly faster than Singular, as expected. 
However, there seems to be a different issue with the Singular interface: 
repeating the same computation causes a significant slowdown. This does not 
happen using libSingular.

sage: I = sage.rings.ideal.Katsura(PolynomialRing(GF(2^31-1), 'x', 10))
sage: %time gb1 = I.groebner_basis(algorithm='singular')
CPU times: user 1.86 s, sys: 110 ms, total: 1.97 s
Wall time: 18.4 s
sage: I = sage.rings.ideal.Katsura(PolynomialRing(GF(2^31-1), 'x', 10))
sage: %time gb2 = I.groebner_basis(algorithm='singular')
CPU times: user 1.89 s, sys: 117 ms, total: 2 s
Wall time: 1min 13s
sage: gb1 == gb2
True

This was tested using Sage 8.7 on a MBP 8,1 with OS X 10.13.6. I observed 
similar results on other machines as well.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/745e9776-a3b3-4040-b677-bb5b08e2d628%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: A Sage interface for FGb (Gröbner bases)

[Markus Wageringel]

Am Freitag, 7. Dezember 2018 13:07:45 UTC+1 schrieb Bill Hart:
>
> How many physical cores do you have on the machine (not logical cores), 
> and how many CPU sockets and what is the cache structure? (I assume it is 
> at least 16 physical cores, but I'm asking more because this sort of thing 
> often happens because of shared caches.)
>

It has 2 CPU sockets, each having 8 physical cores with 2 threads each. As 
for the cache:

L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 20480K

Does this answer the question? Also, here is a specification: 
https://ark.intel.com/products/64584/Intel-Xeon-Processor-E5-2660-20M-Cache-2-20-GHz-8-00-GT-s-Intel-QPI-
 

-- 
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: A Sage interface for FGb (Gröbner bases)

[Markus Wageringel]

Am Donnerstag, 6. Dezember 2018 11:41:23 UTC+1 schrieb Bill Hart:

> All the other systems are using modular methods here, so Roman use the 
> modstd library (the command is modStd) in Singular to get those timings. 
> Indeed cyclic7 over Q takes about 20s on my laptop in Singular using this 
> approach. 
>

Thanks for the hint. With that, I get the following times over ℚ.

ℚ | singular (4)  singular (16)
  cyclic7 |28.79  21.27
  cyclic8 |  1109.03 623.98
 katsura9 |28.07  25.14
katsura10 |   329.86 172.15
alea6 |  3053.702549.42
eco12 |  4879.151888.11
 jason210 |   122.07 106.33
noon9 |  2339.981502.74


Am Donnerstag, 6. Dezember 2018 20:00:52 UTC+1 schrieb parisse:

> From giac, call gbasis with the list of polynomial and the list of the 
> first block indets.  
>

That worked. Thanks.
 

The timings on Q do not reflect the timings of native giac, there must be 
> some misconfiguration or something wrong with the sage interface. Higher 
> timings with 16 threads instead of 4 for a modular algorithm is suspicious.
>

While there will be some overhead due to the conversion from and to Sage, 
it is the same in both cases. In fact, I observe similar times with the 
native Giac that is installed into the Sage environment, when applied to 
the Giac input file cyclic8 you linked above [1]: 0m27.309s using 4 threads 
and 1m43.493s using 16. Indeed, CPU usage rarely surpasses 400% during the 
computation. I am not sure what could be wrong here. Perhaps it is 
something related to the patches of the Giac in Sage [2]?

[1] 
https://www-fourier.ujf-grenoble.fr/~parisse/giac/examples/groebner/cyclic8
[2] https://github.com/sagemath/sage/tree/8.5.beta6/build/pkgs/giac/patches

-- 
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: A Sage interface for FGb (Gröbner bases)

[Markus Wageringel]

Am Samstag, 24. November 2018 23:11:26 UTC+1 schrieb parisse:
>
>
> Giac supports double revlex ordering, this is the order used by the 
> eliminate command of Giac. Geogebra has many examples of eliminate commands 
> there https://dev.geogebra.org/trac/browser/trunk/geogebra/giac/src/test
>

Nice. It would probably be good to have this function in the Sage interface 
for giac, as well. Is it also possible to obtain the full Gröbner basis 
with respect to the revlex/revlex block order, but without elimination?



Meanwhile, Roman Pearce's website [5] is back online and I used those 
polynomial systems to compare the Sage interfaces libsingular, giacpy_sage 
and fgb_sage. I created a gist of the code [6].

Versions of libraries used:
• Sage 8.5.beta4
• libSingular-4.1.1
• giacpy_sage-0.6.6, giac-1.4.9.45.p4
• fgb_sage-0.1, fgb-20150719 (14538, 14539)

Primes used: singular: 2^31-1, giac: 16777213, fgb: 65521.

Machine: CentOS 7.5.1804, Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz, 32 
cores, 196 G memory.
Number of threads in parentheses. Computation time in seconds.

ℤ/p   | singular (1) | giac (4)  giac (16)| fgb (4)  
 fgb (16)
  cyclic8 |62.01 | 7.71  4.88 | 1.86
  1.38
  cyclic9 | 11519.16 |   258.85191.30 |   112.31
 55.37
katsura11 |   107.91 |12.62 11.10 | 4.04
  2.43
katsura12 |  1090.37 |67.07 60.25 |23.09
 12.59
 bayes148 | 7.19 |92.63 92.15 |   571.28
471.59
 gametwo7 |   934.69 |   122.65116.37 |20.78
 14.30
 jason210 | 2.67 |23.71 23.39 |24.58
 22.44
   mayr42 |   124.74 |   169.94166.56 |   139.12
111.08
yang1 |49.79 |  [3]   [3] |   257.96
177.65

ℚ | singular (1) | giac (4)  giac (16)| fgb (1)
  cyclic7 |  [1] |10.71 10.62 | 4.20
  cyclic8 |  [2] |   120.44205.57 |77.22
 katsura9 |19.19 |27.30 27.23 | 3.04
katsura10 |   236.62 |   241.32238.23 |18.58
alea6 | 35724.62 |   578.94548.39 |   [4] 331.64
eco12 |  [1] |  4748.24   4811.32 |   102.06
 jason210 |13.43 |65.24 83.82 |49.38
noon9 |   132.82 |  3146.97   3159.49 |   136.55

I am a bit surprised about some of the Singular results being a lot worse 
than reported in [5], cyclic7 in particular. Perhaps starting this 
computation with some different options can help here.

[1] Aborted after 13.5 hours.
[2] Skipped.
[3] Error, problem too large.
[4] Excessive memory usage of about 300 G; computed on a different machine.
[5] http://www.cecm.sfu.ca/~rpearcea/mgb.html
[6] https://gist.github.com/mwageringel/213a4a980e338ec8ea5a75482b1bcb2b

-- 
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: A Sage interface for FGb (Gröbner bases)

[Markus Wageringel]

Thanks for the feedback everyone.

Am Donnerstag, 22. November 2018 09:53:43 UTC+1 schrieb parisse:
>
> Did you make some comparisons with Giac ?
>
> Some benchmarks from Roman Pearce and my own tests, about 2 years old.
>

I have not done any comparisons, mainly because I cannot do anything about 
the performance of FGb anyway. Moreover, to my knowledge, Giac does not 
support elimination orders (at least the Sage interface does not), which 
made it less suitable for my use cases.

I remember having seen those benchmarks before, but I cannot find them 
anymore. If you send a copy of the polynomial systems, I can make some 
rough comparisons of the options available within Sage.

Markus

-- 
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] A Sage interface for FGb (Gröbner bases)

[Markus Wageringel]

Hi everyone.

I created a Sage wrapper for the C interface of FGb, which makes it easy to 
call FGb from within Sage. The sources are available on Github [1] and can 
be installed as a Python package into Sage:

[1] https://github.com/mwageringel/fgb_sage


FGb is a C-library by J. C. Faugère for computing Gröbner bases and 
supposedly it is one of the faster implementations that exist. It is 
included with Maple [2]. FGb is closed source, but comes with a C interface 
that is freely distributed for academic use. Some of the features:

• The computations run in parallel. (This only seems to work for 
computations over finite fields.)
• Elimination/block orders are supported.
• It runs on Linux and Mac. (There seem to be some issues, though. I could 
not get FGb to work on my Ubuntu machine. It fails with an "Illegal 
instruction" error.)


In my Sage interface, I implemented just two functions: computing Gröbner 
bases and elimination ideals. Supposedly, the FGb C-library supports other 
functionality like computing Hilbert polynomials, but that part of the 
library is not documented very well, so it does not make sense to try to 
create wrappers for that. The focus is finding a Gröbner basis which, once 
computed, can be used by Sage for further computations.

I just wanted to share this. Maybe it is useful for someone.

Markus

[2] https://www-polsys.lip6.fr/~jcf/FGb/Maple/index.html

-- 
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] Build problem when copying __pycache__, Sage 8.5.beta4

[Markus Wageringel]

When I try to compile Sage 8.5.beta4 using `make distclean && make build` 
on OS X 10.13.6, I get an error as below. It fails at copying the directory 
"src/bin/__pycache__". Manually copying over the directory solves the 
problem, so this is probably easy to fix, but I am not sure where this `cp` 
command is invoked.

Markus

...
[sagelib-8.5.beta4] Discovered Python/Cython sources, time: 0.10 seconds.
[sagelib-8.5.beta4] Building interpreters for fast_callable
[sagelib-8.5.beta4] sage/rings/complex_double.pyx: cannot find cimported 
module 'gmpy2'
[sagelib-8.5.beta4] sage/rings/complex_number.pyx: cannot find cimported 
module 'gmpy2'
[sagelib-8.5.beta4] sage/rings/integer.pyx: cannot find cimported module 
'gmpy2'
[sagelib-8.5.beta4] sage/rings/complex_mpc.pyx: cannot find cimported 
module 'gmpy2'
[sagelib-8.5.beta4] sage/rings/rational.pyx: cannot find cimported module 
'gmpy2'
[sagelib-8.5.beta4] sage/rings/real_double.pyx: cannot find cimported 
module 'gmpy2'
[sagelib-8.5.beta4] sage/rings/real_mpfr.pyx: cannot find cimported module 
'gmpy2'
[sagelib-8.5.beta4] warning: Replacing library search directory in linker 
command:
[sagelib-8.5.beta4]   "/usr/local/Cellar/openssl/1.0.2o_2/lib" -> 
"/Applications/SageMath/local/lib"
[sagelib-8.5.beta4] 
[sagelib-8.5.beta4] Executing 0 commands (using 1 thread)
[sagelib-8.5.beta4] Time to execute 0 commands: 0.12 seconds.
[sagelib-8.5.beta4] Total time spent compiling C/C++ extensions: 0.34 
seconds.
[sagelib-8.5.beta4] if [ "$UNAME" = "CYGWIN" ]; then
 \
[sagelib-8.5.beta4] sage-rebase.sh "$SAGE_LOCAL" 2>/dev/null;  
  \
[sagelib-8.5.beta4] fi
[sagelib-8.5.beta4] 
[sagelib-8.5.beta4] real 0m10.015s
[sagelib-8.5.beta4] user 0m6.071s
[sagelib-8.5.beta4] sys 0m2.857s
cp /Applications/SageMath/src/bin/__pycache__ 
/Applications/SageMath/local/bin/__pycache__
cp: /Applications/SageMath/src/bin/__pycache__ is a directory (not copied).
make[3]: *** [/Applications/SageMath/local/bin/__pycache__] Error 1
make[2]: *** [all-build] Error 2

real 0m10.581s
user 0m6.451s
sys 0m3.018s
***
Error building Sage.

The following package(s) may have failed to build (not necessarily
during this run of 'make all-build'):

The build directory may contain configuration files and other potentially
helpful information. WARNING: if you now run 'make' again, the build
directory will, by default, be deleted. Set the environment variable
SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.

-- 
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.
*** ALL ENVIRONMENT VARIABLES BEFORE BUILD: ***
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.jwRjYTvKvs/Render
CLICOLOR=1
COLORFGBG=0;15
COLORTERM=truecolor
CONFIGURED_CC=gcc
CONFIGURED_CXX=g++
CONFIGURED_FC=gfortran
CONFIGURED_OBJC=gcc
CONFIGURED_OBJCXX=g++
DISPLAY=/private/tmp/com.apple.launchd.5OhOL9vEfz/org.macosforge.xquartz:0
GROOVY_HOME=/usr/local/opt/groovy/libexec
HOME=/Users/markus
INFOPATH=/Applications/Macaulay2-1.11/share/info
ITERM_PROFILE=Default
ITERM_SESSION_ID=w0t0p0:F1D3D88F-E15A-4177-B7BC-FC309450877D
LANG=de_DE.UTF-8
LOGNAME=markus
LSCOLORS=ExFxCxDxBxegedabagacad
MAKE=make
MAKEFLAGS= V=1
MAKELEVEL=1
MANPATH=/Applications/Macaulay2-1.11/share/man:
MFLAGS=
PATH=/Applications/SageMath/build/bin:/Applications/SageMath/src/bin:/Applications/SageMath/local/bin:/Applications/Macaulay2-1.11/bin:/usr/local/opt/python@2/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/usr/local/MacGPG2/bin:/opt/X11/bin:/usr/local/git/bin:~/.local/bin:/Applications/LilyPond.app/Contents/Resources/bin
PWD=/Users/markus/git/sage/build/make
PYTHONPATH=/Applications/SageMath/local
SAGE_EXTCODE=/Applications/SageMath/local/share/sage/ext
SAGE_KEEP_BUILT_SPKGS=yes
SAGE_LOCAL=/Applications/SageMath/local
SAGE_LOGS=/Applications/SageMath/logs/pkgs
SAGE_ORIG_PATH=/Applications/Macaulay2-1.11/bin:/usr/local/opt/python@2/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/usr/local/MacGPG2/bin:/opt/X11/bin:/usr/local/git/bin:~/.local/bin:/Applications/LilyPond.app/Contents/Resources/bin
SAGE_ORIG_PATH_SET=True
SAGE_PYTHON_VERSION=2
SAGE_ROOT=/Applications/SageMath
SAGE_SHARE=/Applications/SageMath/local/share
SAGE_SPKG_INST=/Applications/SageMath/local/var/lib/sage/installed
SAGE_SRC=/Applications/SageMath/src
SAGE_VERSION=8.5.beta4
SBT_OPTS= -Dsbt.jse.engineType=Node -Dsbt.jse.command=/usr/local/bin/node 
-Dscala.color
SHELL=/bin/bash
SHLVL=4
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.FQXo0QN0qR/Listeners
TERM=xterm-256color-italic