[sage-devel] Re: feedback on construction functor for symmetric functions

['Travis Scrimshaw' via sage-devel]

Hi Martin,
   I plan to look closely at this this week. Unfortunately I cannot offer 
anything quick now.

Best,
Travis


On Monday, February 12, 2024 at 2:42:52 AM UTC+9 Martin R wrote:

> Apart from that, I think the last bit I need to do is to make the 
> TensorProductFunctor inherit from MultivariateConstructionFunctor, to make 
> coercion work for things like
>
> sage: h = SymmetricFunctions(ZZ).h()
> sage: T = tensor([h, h])
> sage: T.base_ring()
> Integer Ring
> sage: 1/2*T.an_element()
>
> (which currently raises TypeError: unsupported operand parent(s) for *: 
> 'Rational Field' and 'Symmetric Functions over Integer Ring in the 
> homogeneous basis # Symmetric Functions over Integer Ring in the 
> homogeneous basis')
>
> Am I on the right track?
>
> Martin
> On Sunday 11 February 2024 at 12:34:44 UTC+1 Martin R wrote:
>
>> At https://github.com/sagemath/sage/pull/37220, I implemented a (simple 
>> minded) construction functor for symmetric functions.
>>
>> The only major user visible change should be that
>>
>> sage: sZ = SymmetricFunctions(ZZ).s()
>> sage: sQ = SymmetricFunctions(QQ).s()
>> sage: sZ[1,1] + sQ[2]
>> s[1,1] + s[2]
>>
>> now works.  This, and a little bit more, is what I need for my lazy 
>> symmetric functions project.
>>
>> Under the hood, the pull request replaces `corresponding_basis_over` with 
>> a proper construction functor which, however, follows the same spirit: 
>> every basis of symmetric functions has to provide a description on how to 
>> create it, by storing the appropriate method names.
>>
>> There is a todo note by Darij Grinberg from 2013 that this is an ugly 
>> hack, and I agree, but nobody came up with anything better in the last 11 
>> years, so we might as well go with the idea which is working, at least for 
>> the moment.
>>
>> There is one more uglyness I have to mention: I describe the functor as a 
>> functor on the category of commutative rings, which is not true in 
>> general.  For example, for Macdonald polynomials, the functor really is 
>> from the category of commutative rings with two distinguished elements.  I 
>> am guessing that creating a category RingsWithDistinguishedElements is a 
>> bit much, and I wouldn't know how to do it.
>>
>> Comments (and, of course, also a review) would be greatly appreciated!
>>
>> Martin
>>
>

-- 
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/5f537ee8-c7a1-4199-bfcd-341336fd293bn%40googlegroups.com.

[sage-devel] Re: morphisms between multivariate polynomial rings

['Travis Scrimshaw' via sage-devel]

Hi Martin,
   That is coming from this:

sage: type(m)


Although I don't think we have a specific "all morphisms should inherit 
from this ABC (or generic base class)" specification. It might be easy to 
get something to work for it.

Are you thinking of the difficulty of determining a consistent way of 
setting coercions between polynomial rings? That's the only thing I know 
that is problematic.

Best,
Travis
On Sunday, February 11, 2024 at 1:08:43 AM UTC+9 Martin R wrote:

> I was a bit surprised about the following:
>
> sage: k = ZZ["q"].hom(QQ["q"])
> sage: isinstance(k, Morphism)
> True
> sage: m = ZZ["q,t"].hom(QQ["q,t"])
> sage: isinstance(m, Morphism)
> False
>
> However, I vaguely recall a discussion about morphisms between 
> multivariate polynomial rings being problematic.  Does my memory trick me?
>
> Martin
>
>

-- 
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/9e2d9d6c-042c-40cf-9871-ff2f7e7647a7n%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Miguel, can you add the project to the wiki page (or tell me the 
information here), even if it is not fully prepared? It will help increase 
our chances of being selected for GSoC again.

For everyone, there is a new 90 hour option for GSoC project lengths this 
year.

Best,
Travis

On Monday, February 12, 2024 at 3:36:12 AM UTC+9 Matthias Koeppe wrote:

> On Sunday, February 11, 2024 at 7:10:59 AM UTC-8 mmarco wrote:
>
> if i understand what you mean correctly, 1) would go along making it 
> easier from the sage part to implement tactics like polyrith (which right 
> now calls the sagecell server to prove equalities between expressions using 
> groebner basis)?
>
>
> Yes. 
>  
>
> In particular I would like to not depend on an internet connection, and an 
> online service, to do that kind of thing.
>
>
> Exactly, which is another motivation for improving the usability of Sage 
> as a library (-> modularization, pip-installability).
>  
>
> Are there other cases where similar things could be done (that is, 
> concrete computations in Sagemath that could be used as certificates for 
> Lean proofs)?
>
>  
> Yes, this is natural and well understood in polyhedral geometry (where 
> Sage has excellent facilities), linear optimization (where Sage has 
> reasonable interfaces) and its extensions, and graph theory / algebraic 
> topology. 
> More generally, the prospect of uses in Lean could inspire developing a 
> style of computation in Sage where not only an answer is computed but also 
> (ideally at low extra cost) a certificate that allows users to check the 
> answer. We have that for some true/false computations (methods of the form 
> "is_...(..., certificate=True)") but not very much for other 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/dddc6923-8cab-4e2b-ae75-8639b1e909b1n%40googlegroups.com.

Re: [sage-devel] Re: Help with matroids (and more generally?), PR #36492

['Travis Scrimshaw' via sage-devel]

Question for humans: I'm planning on merging this into sage so that 
other developers can help grow it and it's not just me working on it. Would 
it be better to first wait for any bugs that people might notice and then 
add it into sage? Or should I just go ahead and start merging it in and any 
bugs can be fixed while it's in sage itself?


 The review process is designed to catch bugs. Specifically, the reviewer 
should try to make sure the code is bug-free. Part of this is done by 
writing doctests. Of course, we cannot always be perfect about this, and we 
can fix things later. I would just create the PR for adding the code into 
Sage (assuming it is in the appropriate stage for this).

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/543fd01e-9735-461f-a499-51f416b07b8an%40googlegroups.com.

Re: [sage-devel] Unify error for trying to invert non-invertible elements

['Travis Scrimshaw' via sage-devel]

You're misunderstanding what a catch-all means. It means *any* type (of 
error) is reasonable. To put it mathematically, catch-all means union (of 
sets), but the Python doc means difference (of sets).

An assertion is slightly different. It can (in principle) be turned off and 
is just used for internal checking. While there is large overlap, it is not 
quite the same (e.g., if code is assuming a certain conjecture, it should 
not use assert to check validity of assumptions).

Best,
Travis


On Friday, February 9, 2024 at 1:44:23 PM UTC+9 dmo...@deductivepress.ca 
wrote:

> Description of RunTimeError from docs.python.org: "Raised when an error 
> is detected that doesn’t fall in any of the other categories. The 
> associated value is a string indicating what precisely went wrong."
>
> It is for exceptions that cannot be categorized, so I believe it is indeed 
> just a catch-all error (but must have a description), and there is no 
> expectation that such an error is particularly serious. (A situation where 
> "an assumption that I never expected to be violated fails" can raise 
> AssertionError.)
>
> On Thursday, February 8, 2024 at 10:14:33 PM UTC-5 David Roe wrote:
>
>> On Thu, Feb 8, 2024 at 8:18 PM 'Travis Scrimshaw' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>>
>>> For RuntimeError, I would make it sound like it tells you there is 
>>> serious error occurring as it doesn't fall into any other error categories. 
>>> This actually makes it the opposite of a catchall error.
>>>
>>
>> The main scenario when I use a RuntimeError is when an assumption that I 
>> never expected to be violated fails.  I agree with Travis that catchall is 
>> not the right description for this error type.
>> 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/9f55e934-d805-4153-9e4b-d633eacf975an%40googlegroups.com.

[sage-devel] Re: Help needed with UniqueRepresentation (of SymmetricFunctions)

['Travis Scrimshaw' via sage-devel]

Martin's solution is the correct one as it should be preparsing the input 
before it gets to the __init__(), which is then used as the key. This also 
is needed for HallLittlewood and Macdonald.

Best,
Travis

PS - Sorry for not responding sooner about this.

On Tuesday, February 6, 2024 at 4:16:21 PM UTC+9 Martin R wrote:

> Thank you for the explanation.
>
> I would be very surprised about `R.=S.jack()`, because the 
> *coefficients* are (usually regarded as) rational functions in `t`, and the 
> *monomials* are Jack symmetric functions.
>
> I found the following alternative solution at 
> https://doc.sagemath.org/html/en/reference/structure/sage/structure/unique_representation.html
> :
>
> class Jack(UniqueRepresentation):
> @staticmethod
> def __classcall__(cls, Sym, t='t'):
> return super().__classcall__(cls, Sym, Sym.base_ring()(t))
> 
> def __init__(self, Sym, t):
>
> I think I like it better.  Is there anything wrong with it?
> On Monday 5 February 2024 at 19:17:20 UTC+1 Nils Bruin wrote:
>
>> I second that response. More specifically, what you're running into is:
>>
>> sage: S.jack(t=t) == S.jack(t='t')
>> False
>>
>> which is indeed within UniqueRepresentation design parameters: returned 
>> values are cached on construction parameters 't' and '"t"' hash to 
>> different values. If you need better processing, you'd need to normalize 
>> the input parameters further before calling the UniqueRepresentation 
>> constructor. In your case, I think jack.Jack (which is what ends up being 
>> called) actually does expect a string. Perhaps this keyword should be 
>> renamed to "names" to comply with uses elsewhere? e.g., would 
>> R.=S.jack() make sense? If so, then the following should probably be 
>> made to work:
>>
>> sage: preparse("R.=S.jack()")
>> "R = S.jack(names=('t',)); (t,) = R._first_ngens(1)"
>> On Monday 5 February 2024 at 05:57:40 UTC-8 Martin R wrote:
>>
>>> At https://github.com/sagemath/sage/pull/37220 I am trying to provide a 
>>> construction functor for symmetric functions. I am hitting the following 
>>> bug, which I hope is easy to fix if one knows the right magic:
>>>
>>> sage: P. = QQ[]
>>> sage: S = SymmetricFunctions(P)
>>> sage: S.jack().P() == S.jack(t=t).P()
>>> False
>>>
>>> Can someone help me out?
>>>
>>> Martin
>>>
>>

-- 
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/63adb36b-d809-47d0-a98f-6cf3f70508acn%40googlegroups.com.

Re: [sage-devel] Unify error for trying to invert non-invertible elements

['Travis Scrimshaw' via sage-devel]

I would be vague about a TypeError versus a ValueError. These are used in 
various ways by different authors over different periods. It can also be 
very hard to make this rigorous. For example, for something accepting 
integer inputs, then 2/2 fails the isinstance() check but shouldn't throw 
an error. Likewise 1/2 is a bad value that cannot be tested by the 
isinstance() check alone. Actually, I might consider putting them together 
and letting the programmer decide which is most appropriate (of course, 
there are clear cases, such as a list compared to a number).

The ArithmeticError and ZeroDivisionError are fine with me.

I think NotImplementedError is obvious and should be stated in such a way: 
"the input is for a feature not yet implemented"

For RuntimeError, I would make it sound like it tells you there is serious 
error occurring as it doesn't fall into any other error categories. This 
actually makes it the opposite of a catchall error.

Best,
Travis


On Thursday, February 8, 2024 at 11:15:34 AM UTC+9 Kwankyu Lee wrote:

> A method (or function) takes objects as input and computes an output.  The 
> INPUT block defines coarsely  the intended class of mathematical objects. 
>
> TypeError: the type (that can be checked by isinstance(obj, class)) of the 
> input object does not belong to the intended class of mathematical objects
> ValueError: the particular input object is not suitable as input
> ArithmeticError: the particular input object is not suitable for 
> arithmetic (sum, product, quotient, and the like) operation 
> ZeroDivisionError: the method performs division but the input is zero
> NotImplementedError: there is no problem with the input object but the 
> method is incapable to compute appropriate output.
> RuntimeError: The method somehow cannot perform the computation. Perhaps a 
> catchall error.
>
>
> I may add the above to the developer guide. Any comments? 
>

-- 
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/fc6d3662-1d8e-41a4-98ec-4509e2547b71n%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   I have submitted the application.

However, we can continue to add projects (and mentors) at any point. So if 
you are interested or have any features that you want to request, please 
either add it to the wiki page, post it here, or email me.

Best,
Travis


On Tuesday, February 6, 2024 at 11:54:08 AM UTC+9 Travis Scrimshaw wrote:

> Hi Linden,
>Thank you. I added the project at the "standard" length 350 hours.
>
> Best,
> Travis
>
> On Monday, February 5, 2024 at 7:24:38 PM UTC+9 Linden Disney wrote:
>
>> I have a proposal for a project I would be willing to mentor (detailed 
>> below for completeness), but I'm unsure about how best to estimate the 
>> length (I did GSoC 2021 but estimates of length weren't around then). The 
>> initial coding would not be too challenging, but the mathematical research 
>> which is within scope may be harder (but certainly more interesting). 
>>
>> Title: Poincare normal form of Riemann matrices.
>> Areas: Algebra, Algebraic Geometry.
>> Skills: Knowledge of abstract algebra and Riemann surfaces desirable. 
>> Length: ? 
>> Difficulty: Medium-Easy, becoming harder if desired by tackling the 
>> research questions. 
>>
>> Description: Riemann surfaces are key objects in many areas of maths, 
>> from mathematical physics to algebraic and arithmetic geometry, with modern 
>> usage of Sage typically focusing around computing the Riemann matrix and 
>> calculating the associated theta function. The project would involve an 
>> implementation of Poincare reduction of the Riemann matrix which allows the 
>> theta function to be factorised, following the paper of Martens (
>> http://www.jstor.org/stable/43737152), which in turn will require some 
>> matrix methods to be implemented. There is scope for an enterprising 
>> applicant to make this into a research paper in two directions, either by 
>> analysing the improvement to complexity from computing with factorised 
>> theta functions, or by developing an algorithm to go from one reduction to 
>> a complete reduction. 
>>
>> On Monday, February 5, 2024 at 12:49:41 AM UTC Travis Scrimshaw wrote:
>>
>>> I have added it. (For reference on editing the pages, you login using 
>>> your trac credentials from the upper left corner.)
>>>
>>> Best,
>>> Travis
>>>
>>>
>>> On Monday, February 5, 2024 at 5:38:52 AM UTC+9 Martin R wrote:
>>>
 I would like to propose the exact same project I had for last year 
 again, but I am currently at a conference and additionally don't see how I 
 could edit the page.

 Martin

 On Sunday 4 February 2024 at 05:19:17 UTC+1 Travis Scrimshaw wrote:

> Sorry for the multiple messages.
>
> For potential mentors, there is no commitment required at this time.
>
> You can also decide later to add a project and/or be a mentor.
>
> Best,
> Travis
>
> On Sunday, February 4, 2024 at 1:17:54 PM UTC+9 Travis Scrimshaw wrote:
>
>> For the potential projects, you can either edit the corresponding 
>> wiki page in Matthias's link or directly post them here (you do not need 
>> to 
>> be the mentor).
>>
>> Also, I would like to have a list of potential mentors. Any SageMath 
>> developer can be a mentor for a GSoC project; so if you are willing to 
>> be a 
>> mentor (typically just a few hours a week), please directly email me, 
>> post 
>> it here, or put your name down as a project mentor. (You do not need to 
>> have a specific project in mind either.)
>>
>> Best,
>> Travis
>>
>> On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw 
>> wrote:
>>
>>> Thank you for doing that. I updated my projects and removed all of 
>>> those with named mentors as they have not agreed at present (AFAIK) to 
>>> be a 
>>> potential mentor.
>>>
>>> I was expecting to be the main administrator for GSoC again this 
>>> year. We will discuss this on the mentors list.
>>>
>>> For the proposal, what we need from the community is a list of 
>>> projects they are willing to mentor. There is no commitment at this 
>>> time. 
>>> However, it is important for our GSoC proposal that it contains a list 
>>> of 
>>> new projects each year.
>>>
>>> Best,
>>> Travis
>>>
>>>
>>> On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe 
>>> wrote:
>>>
 To get the process started for this year, I have created the page 
 https://wiki.sagemath.org/GSoC/2024 by copying last year's page, 
 removing a completed project and adding a new project that I hope to 
 mentor 
 this summer.

 The deadline for our project to apply as a GSoC mentoring 
 organization is rapidly approaching: 
 https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc

 Do we have any volunteers for the 

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Hi Linden,
   Thank you. I added the project at the "standard" length 350 hours.

Best,
Travis

On Monday, February 5, 2024 at 7:24:38 PM UTC+9 Linden Disney wrote:

> I have a proposal for a project I would be willing to mentor (detailed 
> below for completeness), but I'm unsure about how best to estimate the 
> length (I did GSoC 2021 but estimates of length weren't around then). The 
> initial coding would not be too challenging, but the mathematical research 
> which is within scope may be harder (but certainly more interesting). 
>
> Title: Poincare normal form of Riemann matrices.
> Areas: Algebra, Algebraic Geometry.
> Skills: Knowledge of abstract algebra and Riemann surfaces desirable. 
> Length: ? 
> Difficulty: Medium-Easy, becoming harder if desired by tackling the 
> research questions. 
>
> Description: Riemann surfaces are key objects in many areas of maths, from 
> mathematical physics to algebraic and arithmetic geometry, with modern 
> usage of Sage typically focusing around computing the Riemann matrix and 
> calculating the associated theta function. The project would involve an 
> implementation of Poincare reduction of the Riemann matrix which allows the 
> theta function to be factorised, following the paper of Martens (
> http://www.jstor.org/stable/43737152), which in turn will require some 
> matrix methods to be implemented. There is scope for an enterprising 
> applicant to make this into a research paper in two directions, either by 
> analysing the improvement to complexity from computing with factorised 
> theta functions, or by developing an algorithm to go from one reduction to 
> a complete reduction. 
>
> On Monday, February 5, 2024 at 12:49:41 AM UTC Travis Scrimshaw wrote:
>
>> I have added it. (For reference on editing the pages, you login using 
>> your trac credentials from the upper left corner.)
>>
>> Best,
>> Travis
>>
>>
>> On Monday, February 5, 2024 at 5:38:52 AM UTC+9 Martin R wrote:
>>
>>> I would like to propose the exact same project I had for last year 
>>> again, but I am currently at a conference and additionally don't see how I 
>>> could edit the page.
>>>
>>> Martin
>>>
>>> On Sunday 4 February 2024 at 05:19:17 UTC+1 Travis Scrimshaw wrote:
>>>
 Sorry for the multiple messages.

 For potential mentors, there is no commitment required at this time.

 You can also decide later to add a project and/or be a mentor.

 Best,
 Travis

 On Sunday, February 4, 2024 at 1:17:54 PM UTC+9 Travis Scrimshaw wrote:

> For the potential projects, you can either edit the corresponding wiki 
> page in Matthias's link or directly post them here (you do not need to be 
> the mentor).
>
> Also, I would like to have a list of potential mentors. Any SageMath 
> developer can be a mentor for a GSoC project; so if you are willing to be 
> a 
> mentor (typically just a few hours a week), please directly email me, 
> post 
> it here, or put your name down as a project mentor. (You do not need to 
> have a specific project in mind either.)
>
> Best,
> Travis
>
> On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw wrote:
>
>> Thank you for doing that. I updated my projects and removed all of 
>> those with named mentors as they have not agreed at present (AFAIK) to 
>> be a 
>> potential mentor.
>>
>> I was expecting to be the main administrator for GSoC again this 
>> year. We will discuss this on the mentors list.
>>
>> For the proposal, what we need from the community is a list of 
>> projects they are willing to mentor. There is no commitment at this 
>> time. 
>> However, it is important for our GSoC proposal that it contains a list 
>> of 
>> new projects each year.
>>
>> Best,
>> Travis
>>
>>
>> On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:
>>
>>> To get the process started for this year, I have created the page 
>>> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, 
>>> removing a completed project and adding a new project that I hope to 
>>> mentor 
>>> this summer.
>>>
>>> The deadline for our project to apply as a GSoC mentoring 
>>> organization is rapidly approaching: 
>>> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>>>
>>> Do we have any volunteers for the administrator role?
>>>
>>>

-- 
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/82f856f0-f93a-4f82-b8e6-c015f7245f08n%40googlegroups.com.

Re: [sage-devel] Unify error for trying to invert non-invertible elements

['Travis Scrimshaw' via sage-devel]

Dave, I agree that it is quite possible that not all of them are correct 
non-invertible elements in a ring. Of course, we would go through an 
examine them more individually as David suggested.

I was originally thinking ValueError as well, but, as Martin pointed out, 
ArithmeticError is a bit more specific. So that gets my vote.

Best,
Travis


On Tuesday, February 6, 2024 at 11:12:30 AM UTC+9 David Roe wrote:

> I agree that there are cases that shouldn't be changed to an 
> ArithmeticError, and that grepping for "invertible" isn't sufficient.  But 
> I think with a narrower scope this change is a good idea: if the error 
> arises from attempting to invert a non-invertible element of a ring.
>
> So +1 from me, with a manual check that the change seems appropriate.
> David
>
> On Mon, Feb 5, 2024 at 7:54 PM Dave Morris  
> wrote:
>
>> -1 from me.
>>
>> Looking at just a few uncovered some that I think are definitely not 
>> ArithmeticError.
>>
>> Examples:
>> There is an occurrence of ValueError('{} is not invertible') in 
>> the lift_isometry method of cliffordalgebra.py.  Lifting an isometry is 
>> clearly not an arithmetic operation.  ValueError is correct here.
>> There is an occurrence of TypeError('the A-basis is defined only 
>> when 2 is invertible') in the method to find an `A`-basis of an 
>> Iwahori-Hecke algebra.  Finding such a basis is clearly not an arithmetic 
>> operation.  Perhaps this should be a ValueError instead of a TypeError, 
>> though.
>> RuntimeError("morphism is not invertible").  I think that finding 
>> the inverse of a morphism between two objects of a category is clearly not 
>> an arithmetic operation.  Perhaps this should be a ValueError rather than a 
>> RuntimeError.
>>
>> If you want to unify, I think ValueError might work.  But I think they 
>> all need to be inspected, not just assume a single error type fits.
>>
>> > On Feb 5, 2024, at 4:44 AM, 'Martin R' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>> > 
>> > Dear all,
>> > 
>> > currently, when trying to invert a non-invertible element, one of the 
>> following errors is raised (found using `grep -r --include=*.{py,pyx} 
>> --color -nH --null -e "Error(.*invertible" *`):
>> > • 21 ValueError('{} is not invertible')
>> > • 11 ZeroDivisionError("element is not invertible")
>> > • 10 TypeError('the A-basis is defined only when 2 is invertible')
>> > • 8 ArithmeticError("self must be invertible to have a 
>> multiplicative order")
>> > • 2 RuntimeError("morphism is not invertible")
>> > • 2 NotImplementedError("matrix must be invertible")
>> > 
>> > Travis and I would like to propose to unify these to 
>> "ArithmeticError".  If nobody objects, I would prepare a PR within the next 
>> few days.
>> > 
>> > Best wishes,
>> > 
>> > Martin
>> > 
>> > 
>> > -- 
>> > 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/d0637584-4908-4101-8e1b-74ec0477ff84n%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/4A0E1F77-27A7-4DF3-BB18-636853BF4CC0%40deductivepress.ca
>> .
>>
>

-- 
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/d600a383-43a9-4105-8d81-cd2ec1db3dd1n%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

I have added it. (For reference on editing the pages, you login using your 
trac credentials from the upper left corner.)

Best,
Travis


On Monday, February 5, 2024 at 5:38:52 AM UTC+9 Martin R wrote:

> I would like to propose the exact same project I had for last year again, 
> but I am currently at a conference and additionally don't see how I could 
> edit the page.
>
> Martin
>
> On Sunday 4 February 2024 at 05:19:17 UTC+1 Travis Scrimshaw wrote:
>
>> Sorry for the multiple messages.
>>
>> For potential mentors, there is no commitment required at this time.
>>
>> You can also decide later to add a project and/or be a mentor.
>>
>> Best,
>> Travis
>>
>> On Sunday, February 4, 2024 at 1:17:54 PM UTC+9 Travis Scrimshaw wrote:
>>
>>> For the potential projects, you can either edit the corresponding wiki 
>>> page in Matthias's link or directly post them here (you do not need to be 
>>> the mentor).
>>>
>>> Also, I would like to have a list of potential mentors. Any SageMath 
>>> developer can be a mentor for a GSoC project; so if you are willing to be a 
>>> mentor (typically just a few hours a week), please directly email me, post 
>>> it here, or put your name down as a project mentor. (You do not need to 
>>> have a specific project in mind either.)
>>>
>>> Best,
>>> Travis
>>>
>>> On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw wrote:
>>>
 Thank you for doing that. I updated my projects and removed all of 
 those with named mentors as they have not agreed at present (AFAIK) to be 
 a 
 potential mentor.

 I was expecting to be the main administrator for GSoC again this year. 
 We will discuss this on the mentors list.

 For the proposal, what we need from the community is a list of projects 
 they are willing to mentor. There is no commitment at this time. However, 
 it is important for our GSoC proposal that it contains a list of new 
 projects each year.

 Best,
 Travis


 On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:

> To get the process started for this year, I have created the page 
> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, 
> removing a completed project and adding a new project that I hope to 
> mentor 
> this summer.
>
> The deadline for our project to apply as a GSoC mentoring organization 
> is rapidly approaching: 
> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>
> Do we have any volunteers for the administrator role?
>
>

-- 
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/cee28f9e-255e-410f-b82d-55e8acc553d7n%40googlegroups.com.

Re: [sage-devel] Sphinx directives in upper case?

['Travis Scrimshaw' via sage-devel]

I think it is more confusing to mix the two. I vote for keeping everything 
all uppercase since everything else that is analogous uses all uppercase 
letters.

Best,
Travis

On Wednesday, January 31, 2024 at 9:20:58 PM UTC+9 TB wrote:

> On 25/01/2024 7:06, Kwankyu Lee wrote:
>
> Hi, 
>
> Our developer guide dictates to write Sphinx directives in upper case. So 
> for example, ".. MATH::" instead of ".. math::". By the way, it seems that 
> Sphinx community seems to regard lower case as norm. So my question is: why 
> do we insist upper case? Could anyone point to a discussion thread that 
> decided on this?
>
> More than 13 years ago we have 
> https://github.com/sagemath/sage/issues/10077 and 
> https://github.com/sagemath/sage/issues/10078 that have comments about 
> the case. Some further history might stem from stropping 
> ... For those looking 
> in the docs, one place is here 
> 
> .
>
>
> On 25/01/2024 10:18, Kwankyu Lee wrote:
>
> In my humble opinion,  except  
>
> ".. SEEALSO::", "..WARNING::", ".. TODO::", ".. NOTE::", ".. RUBRIC::", ".. 
> PLOT::", "..TOPIC::", which seek for reader's attention, 
>
> we should use lower case (by default) for all other directives, following 
> Sphinx community's trend. In particular, ".. MATH::" is only distracting.
>
> No strong opinion from me, except maybe for having consistency within a 
> given file. The INPUT and OUTPUT blocks are related, but they are not 
> directives. Do you think they should be?
>
>
> Regards,
>
> TB
>
>

-- 
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/e3057ac7-1c23-4bc3-ab17-1bce7570369cn%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Sorry for the multiple messages.

For potential mentors, there is no commitment required at this time.

You can also decide later to add a project and/or be a mentor.

Best,
Travis

On Sunday, February 4, 2024 at 1:17:54 PM UTC+9 Travis Scrimshaw wrote:

> For the potential projects, you can either edit the corresponding wiki 
> page in Matthias's link or directly post them here (you do not need to be 
> the mentor).
>
> Also, I would like to have a list of potential mentors. Any SageMath 
> developer can be a mentor for a GSoC project; so if you are willing to be a 
> mentor (typically just a few hours a week), please directly email me, post 
> it here, or put your name down as a project mentor. (You do not need to 
> have a specific project in mind either.)
>
> Best,
> Travis
>
> On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw wrote:
>
>> Thank you for doing that. I updated my projects and removed all of those 
>> with named mentors as they have not agreed at present (AFAIK) to be a 
>> potential mentor.
>>
>> I was expecting to be the main administrator for GSoC again this year. We 
>> will discuss this on the mentors list.
>>
>> For the proposal, what we need from the community is a list of projects 
>> they are willing to mentor. There is no commitment at this time. However, 
>> it is important for our GSoC proposal that it contains a list of new 
>> projects each year.
>>
>> Best,
>> Travis
>>
>>
>> On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:
>>
>>> To get the process started for this year, I have created the page 
>>> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, 
>>> removing a completed project and adding a new project that I hope to mentor 
>>> this summer.
>>>
>>> The deadline for our project to apply as a GSoC mentoring organization 
>>> is rapidly approaching: 
>>> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>>>
>>> Do we have any volunteers for the administrator role?
>>>
>>>

-- 
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/162019c3-ba9c-4f9f-9a5c-b469b156cb58n%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

For the potential projects, you can either edit the corresponding wiki page 
in Matthias's link or directly post them here (you do not need to be the 
mentor).

Also, I would like to have a list of potential mentors. Any SageMath 
developer can be a mentor for a GSoC project; so if you are willing to be a 
mentor (typically just a few hours a week), please directly email me, post 
it here, or put your name down as a project mentor. (You do not need to 
have a specific project in mind either.)

Best,
Travis

On Sunday, February 4, 2024 at 1:09:07 PM UTC+9 Travis Scrimshaw wrote:

> Thank you for doing that. I updated my projects and removed all of those 
> with named mentors as they have not agreed at present (AFAIK) to be a 
> potential mentor.
>
> I was expecting to be the main administrator for GSoC again this year. We 
> will discuss this on the mentors list.
>
> For the proposal, what we need from the community is a list of projects 
> they are willing to mentor. There is no commitment at this time. However, 
> it is important for our GSoC proposal that it contains a list of new 
> projects each year.
>
> Best,
> Travis
>
>
> On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:
>
>> To get the process started for this year, I have created the page 
>> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, 
>> removing a completed project and adding a new project that I hope to mentor 
>> this summer.
>>
>> The deadline for our project to apply as a GSoC mentoring organization is 
>> rapidly approaching: 
>> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>>
>> Do we have any volunteers for the administrator role?
>>
>>

-- 
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/b8badb42-659e-46a4-8ac7-13225dc1af1bn%40googlegroups.com.

[sage-devel] Re: Google Summer of Code: Organization application deadline Feb 6!

['Travis Scrimshaw' via sage-devel]

Thank you for doing that. I updated my projects and removed all of those 
with named mentors as they have not agreed at present (AFAIK) to be a 
potential mentor.

I was expecting to be the main administrator for GSoC again this year. We 
will discuss this on the mentors list.

For the proposal, what we need from the community is a list of projects 
they are willing to mentor. There is no commitment at this time. However, 
it is important for our GSoC proposal that it contains a list of new 
projects each year.

Best,
Travis


On Sunday, February 4, 2024 at 7:19:44 AM UTC+9 Matthias Koeppe wrote:

> To get the process started for this year, I have created the page 
> https://wiki.sagemath.org/GSoC/2024 by copying last year's page, removing 
> a completed project and adding a new project that I hope to mentor this 
> summer.
>
> The deadline for our project to apply as a GSoC mentoring organization is 
> rapidly approaching: 
> https://developers.google.com/open-source/gsoc/timeline#february_6_-_1800_utc
>
> Do we have any volunteers for the administrator role?
>
>

-- 
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/e7cf5e21-a7ac-4522-b110-fe52fa2ff12an%40googlegroups.com.

[sage-devel] Re: Help with matroids (and more generally?), PR #36492

['Travis Scrimshaw' via sage-devel]

Hi John,
   None of the above. I think maintaining good programming practices is 
important for the codebase and it is a good thing to teach contributors who 
might not understand. Hence, we should spend the time having them get it 
into a format that is acceptable for Sage. In the end, it should play nice 
with the current matroid code, but I don't think that is a requirement for 
a new feature.

Best,
Travis

On Wednesday, November 22, 2023 at 8:27:31 AM UTC+9 John H Palmieri wrote:

> This post concerns https://github.com/sagemath/sage/pull/36492. The main 
> topic of that PR is matroids about which I know almost nothing, so I am not 
> the right person to review it. The structure of the PR perhaps opens up 
> broader questions. The author has some new code, along with a PDF 
> documenting it, and it is currently not designed to be incorporated into 
> the existing sage.matroids module, but as more of a standalone piece of 
> code.
>
> - Should we have a "contrib" directory where we can easily include efforts 
> like this?
> - Should this particular code be instead included in our thematic 
> tutorials? (If so, it needs someone to shepherd it through the process.)
> - Or should this code be folded into the existing `sage.matroids` stuff?
>
> -- 
> John
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9e9e36be-68d2-4771-b5a3-1527321f673bn%40googlegroups.com.

Re: [sage-devel] Operator Product Expansions in Lie conformal algebras

['Travis Scrimshaw' via sage-devel]

We should look at that closely sometime Reimundo. I have very strong doubts 
that it is the category formalism as that really should not be playing any 
role in creating and manipulating elements. It only comes into play when 
dealing with multiple (distinct) parents. It might also be that you need to 
directly implement some shortcuts rather than relying on some general 
machinery or you are using the wrong data structures.

Best,
Travis


On Friday, October 20, 2023 at 8:56:44 AM UTC+9 Reimundo Heluani wrote:

> There was a very large PR with a full implementation of vertex operator 
> algebras including some non-linearly generated. It got caught in review, 
> then 
> the pandemic and then the birth of a baby in the middle of it. That PR got 
> broken into several pieces, some for LCAs, another for vertex algebras, 
> then 
> another for examples and another with the main application I had at the 
> time 
> for computing classical limits and Poisson vertex algebras. 
>
> The rebasing mechanism and maintaining such a large PR for review was 
> impossible https://github.com/sagemath/sage/issues/29610
>
> I don't think that compiles not even close. The biggest problem is that 
> for 
> any serious computation Python and the overhead of all the category 
> formalism 
> of Sage makes these packages useless. Mathematica Thielemann's package was 
> orders of magnitude faster. I coded a C++ version of this that I was 
> hoping to 
> use as backend for sage. But adhering to the category formalism is 
> not-trivial. 
>
> R. 
>
> On Oct 18, Sam DeHority wrote:
> >Hi,
> >
> >Sage has a LieConformalAlgebras module which is able to compute OPEs, or
> >equivalently \lambda-brackets when those brackets close under OPEs. There
> >isn't, however, a "free" Lie Conformal Algebra which allows for OPEs of 
> fields
> >build from normally ordered products using the noncommutative Wick 
> formula.
> >
> >Is there any interest in expanding the LieConformalAlgebras package to 
> support
> >more general OPEs?
> >
> >--
> >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 [1]sage-devel+...@googlegroups.com.
> >To view this discussion on the web visit [2]
> https://groups.google.com/d/msgid/
> >sage-devel/d73a91f8-4082-493e-9580-b978547825c4n%40googlegroups.com.
> >
> >References:
> >
> >[1] mailto:sage-devel+...@googlegroups.com
> >[2] 
> https://groups.google.com/d/msgid/sage-devel/d73a91f8-4082-493e-9580-b978547825c4n%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/22640cd8-e1f8-40b0-aefd-4fd0bb9b8793n%40googlegroups.com.

Re: [sage-devel] change_ring for ideals

['Travis Scrimshaw' via sage-devel]

Then I will write a PR that implements the generic version I described.

This is now #36472, but I am getting a problem with large looping in 
p-adics that I cannot figure out. I haven't run other tests, but I think 
the only issues are localized to that code.

Best,
Travis

On Monday, October 16, 2023 at 3:53:05 PM UTC+9 Dima Pasechnik wrote:

>
>
> On Mon, 16 Oct 2023, 05:03 'Travis Scrimshaw' via sage-devel, <
> sage-...@googlegroups.com> wrote:
>
>> Hi everyone,
>>Is there some reason why a generic change_ring() was not implemented 
>> for all ideals? This leads to a bug with univariate Laurent polynomials:
>>
>
> I guess it was not implemented because the backend used here is not 
> Singular (where it's built-in)
>
>
>
>> sage: L. = LaurentPolynomialRing(QQ)
>> sage: I = L.ideal(0)
>> sage: I + I
>>
>> ---
>> AttributeErrorTraceback (most recent call 
>> last)
>> ...
>> AttributeError: 'Ideal_1poly_field' object has no attribute 'change_ring'
>>
>> I imagine that just calling "return 
>> self.ring().parent().ideal(self.gens())" would work in general (and I think 
>> should for that matter).
>>
>> This was noticed on PR #36368, where the author is working around it by 
>> implementing this for the class in question.
>>
>> Best,
>> Travis
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-devel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-devel+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/f373c92a-1f68-42ab-aec0-a22305173bacn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/f373c92a-1f68-42ab-aec0-a22305173bacn%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/d69d4e8d-b761-4351-b017-6b7ee274d3d8n%40googlegroups.com.

[sage-devel] change_ring for ideals

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   Is there some reason why a generic change_ring() was not implemented for 
all ideals? This leads to a bug with univariate Laurent polynomials:

sage: L. = LaurentPolynomialRing(QQ)
sage: I = L.ideal(0)
sage: I + I
---
AttributeErrorTraceback (most recent call last)
...
AttributeError: 'Ideal_1poly_field' object has no attribute 'change_ring'

I imagine that just calling "return 
self.ring().parent().ideal(self.gens())" would work in general (and I think 
should for that matter).

This was noticed on PR #36368, where the author is working around it by 
implementing this for the class in question.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f373c92a-1f68-42ab-aec0-a22305173bacn%40googlegroups.com.

Re: [sage-devel] Re: New package creation - advice/help requested

['Travis Scrimshaw' via sage-devel]

Not so much, but because people working in matroids usually need more 
speed, it tends to mean more Cython code. Compare how your implementation 
is done with the matroids in Sage. (For instance, you can have a category 
(even with Cython), but there are a number of categories that are more 
meant to serve a programming role, through abstraction and avoiding 
combinatorial explosion of classes, than a mathematical one. Matroids would 
be such an example.)

Best,
Travis


On Wednesday, July 5, 2023 at 4:16:50 PM UTC+9 Aram Dermenjian wrote:

> In essence, yes we're expecting to change much of the code as the 
> structure will be changing in addition to fixes to some major bugs in the 
> code. Moreover, I'm working on this with two (undergraduate) interns that I 
> have and so they're newer to programming so I wanted them to work in a more 
> "sandbox" environment before fully integrating it into sage.
>
> I hadn't heard about a push to get more cython. Is this becoming more 
> standard? 
>
> Aram
>
> On Mon, 3 Jul 2023 at 01:56, 'Travis Scrimshaw' via sage-devel <
> sage-...@googlegroups.com> wrote:
>
>> Hi Aram,
>>Can you explain a bit more why you aren't just integrating it into 
>> Sage now? Are you're expecting to have major API changes? There would 
>> likely be a push to change to using more Cython, but it doesn't need to be 
>> feature complete to be a part of Sage and internal/implementation details 
>> are easy to change.
>>
>> Best,
>> Travis
>>
>> On Friday, June 30, 2023 at 1:27:30 AM UTC+9 Matthias Koeppe wrote:
>>
>>> On Thursday, June 29, 2023 at 3:01:58 AM UTC-7 Aram Dermenjian wrote:
>>>
>>> it seems the method I was using to create a new package is no longer 
>>> valid. For example, when I try and do an install, I get the following error:
>>>
>>>  SetuptoolsDeprecationWarning: setup.py install is deprecated. Use 
>>> build and pip and other standards-based tools.
>>>
>>>
>>> It's not an error. If you already use "pip install" to install your 
>>> package, no action is needed.
>>> But you may want to learn about pyproject.toml (see the setuptools docs)
>>>
>>> -- 
>> 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/e5495aae-4978-41df-bc4b-f1cce649dbe7n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/e5495aae-4978-41df-bc4b-f1cce649dbe7n%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/074e5725-03a6-4626-9e55-f4c08f00524cn%40googlegroups.com.

[sage-devel] Re: issue with division in fraction field of univ poly

['Travis Scrimshaw' via sage-devel]

When I first tried Ben's OP code, it worked as there. Then when trying 
Nil's code, I get the same output as Ben, but when I immediate after run

sage: D2 / D1
...Same traceback as above...
ZeroDivisionError: fraction field element division by zero

Now in a fresh Sage session, I immediately get the zero division error for 
D2 / D1, but then running Nil's code, I now get:

sage: Kp = parent(1/D1)
sage: r = Kp(D2)
sage: s = Kp(1/D1)
sage: r.numerator().gcd(s.denominator())
a*x^3 + (-a)*x^2*y + (-a^2 + 3*a - 1)*x*y^2 + (2*a^2 - 3*a + 1)*y^3
sage: r * s
ZeroDivisionError
sage: r.numerator().gcd(s.denominator())
0

So I think Nil's correctly identified the main symptom, but Ben's diagnosis 
is almost correct. It is not something being cached but an internal 
property being changed in some place where it believes it is safe to mutate 
it. I have created a new issue 
https://github.com/sagemath/sage/issues/35886 and put some additional 
observations.

Best,
Travis
On Wednesday, June 28, 2023 at 1:42:35 AM UTC+9 Ben Hutz wrote:

> I'm not getting 0 with that code:
>
> sage: K. = Frac(QQ['a'])
> sage: P. = ProjectiveSpace(K, 1)
> sage: D2=-x^5 + (-3*a^2 + 7*a - 2)/a*x^4*y + (6*a^2 - 12*a + 4)/a*x^3*y^2 
> + (3*a^4 - 19*a^3 + 29*a^2 - 14*a + 2)/(a^2)*x^2*y^3 + (-8*a^4 + 30*a^3 - 
> 37*a^2 + 18*a - 3)/(a^2)*x*y^4 + (4*a^4 - 12*a^3 + 13*a^2 - 6*a + 
> 1)/(a^2)*y^5
> sage: D1=-x^3 + x^2*y + (a^2 - 3*a + 1)/a*x*y^2 + (-2*a^2 + 3*a - 1)/a*y^3
>
> sage: K=parent(1/D2)
> sage: r=K(D1)
> sage: s=K(1/D2)
> sage: r.numerator().gcd(s.denominator())
> a*x^3 + (-a)*x^2*y + (-a^2 + 3*a - 1)*x*y^2 + (2*a^2 - 3*a + 1)*y^3 
>
>
> However, if I run 
> sage: K. = Frac(QQ['a'])
> sage: P. = ProjectiveSpace(K, 1)
> sage: f = x^2 + (a + 1/a - 3)*x*y - (2*a + 1/a - 3)*y^2
> sage: phi = DynamicalSystem_projective([f,x^2])
> sage: phi.dynatomic_polynomial(2)
> 0
>
> and *then* run the code I get zero.
>
> sage: K. = Frac(QQ['a'])
> sage: P. = ProjectiveSpace(K, 1)
> sage: D2=-x^5 + (-3*a^2 + 7*a - 2)/a*x^4*y + (6*a^2 - 12*a + 4)/a*x^3*y^2 
> + (3*a^4 - 19*a^3 + 29*a^2 - 14*a + 2)/(a^2)*x^2*y^3 + (-8*a^4 + 30*a^3 - 
> 37*a^2 + 18*a - 3)/(a^2)*x*y^4 + (4*a^4 - 12*a^3 + 13*a^2 - 6*a + 
> 1)/(a^2)*y^5
> sage: D1=-x^3 + x^2*y + (a^2 - 3*a + 1)/a*x*y^2 + (-2*a^2 + 3*a - 1)/a*y^3
>
> sage: K=parent(1/D2)
> sage: r=K(D1)
> sage: s=K(1/D2)
> sage: r.numerator().gcd(s.denominator()) 
> 0
>
>
> So I still find that weird. Is there something being oddly cached?
> On Monday, June 26, 2023 at 4:04:18 PM UTC-5 Nils Bruin wrote:
>
>> With your data, we get:
>>
>> sage: K=parent(1/D2)
>> sage: r=K(D1)
>> sage: s=K(1/D2)
>> sage: r.numerator().gcd(s.denominator())
>> 0
>>
>> and I think that's the zero which leads to the division-by-zero error. Of 
>> course, a 0 returned as gcd is just a bug. It doesn't look like the 
>> coercion framework is really involved here.
>>
>>

-- 
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/111d5aa6-6a17-4acf-8576-e676db709192n%40googlegroups.com.

[sage-devel] Re: New package creation - advice/help requested

['Travis Scrimshaw' via sage-devel]

Hi Aram,
   Can you explain a bit more why you aren't just integrating it into Sage 
now? Are you're expecting to have major API changes? There would likely be 
a push to change to using more Cython, but it doesn't need to be feature 
complete to be a part of Sage and internal/implementation details are easy 
to change.

Best,
Travis

On Friday, June 30, 2023 at 1:27:30 AM UTC+9 Matthias Koeppe wrote:

> On Thursday, June 29, 2023 at 3:01:58 AM UTC-7 Aram Dermenjian wrote:
>
> it seems the method I was using to create a new package is no longer 
> valid. For example, when I try and do an install, I get the following error:
>
>  SetuptoolsDeprecationWarning: setup.py install is deprecated. Use 
> build and pip and other standards-based tools.
>
>
> It's not an error. If you already use "pip install" to install your 
> package, no action is needed.
> But you may want to learn about pyproject.toml (see the setuptools docs)
>
>

-- 
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/e5495aae-4978-41df-bc4b-f1cce649dbe7n%40googlegroups.com.

Re: [sage-devel] Voting: Block-scoped optional tag and the keyword

['Travis Scrimshaw' via sage-devel]

(A)

Travis


On Monday, July 3, 2023 at 2:42:10 AM UTC+9 G. M.-S. wrote:

>
> My choice is (A).
>
> Guillermo
>
> On Thu, 29 Jun 2023 at 04:40, Kwankyu Lee  wrote:
>
>> Hi,
>>
>> We spent six days for the preliminary discussion in the sage-devel thread
>>
>> https://groups.google.com/g/sage-devel/c/OUnoroIf0qc
>>
>> about choosing the keyword triggering block-scoped optional tag needed in 
>>
>> https://github.com/sagemath/sage/issues/35750
>>
>> We now start the voting with the four candidates (A), (B), (C), (D). The 
>> voting will end 7th July 23:59 KST (Korea Standard Time). During the 
>> voting, discussions can continue in the linked places but please only your 
>> vote (and, if you will, short comment) to this thread.
>>
>> (A) "needs"
>>
>> sage: # needs sage.rings.number_field
>> sage: QQbar(I)^2
>> -1
>> sage: QQbar(I)^10 # long time
>> 1
>>
>> sage: # needs sage.rings.finite_rings
>> sage: F = GF(7)
>> sage: F(1) + QQbar(1)  # needs sage.rings.number_field
>> ...
>>
>> (B) "requires"
>>
>> sage: # requires sage.rings.number_field
>> sage: QQbar(I)^2
>> -1
>> sage: QQbar(I)^10  # long time
>> 1
>>
>> sage: # requires sage.rings.finite_rings
>> sage: F = GF(7)
>> sage: F(1) + QQbar(1)  # requires sage.rings.number_field
>> ...
>>
>> (C) "uses"
>>
>> sage: # uses sage.rings.number_field
>> sage: QQbar(I)^2
>> -1
>> sage: QQbar(I)^10  # long time
>> 1
>>
>> sage: # uses sage.rings.finite_rings
>> sage: F = GF(7)
>> sage: F(1) + QQbar(1)  # uses sage.rings.number_field
>> ...
>>
>> (D) "standard"
>>
>> sage: # use standard feature - sage.rings.number_field
>> sage: QQbar(I)^2
>> -1
>> sage: QQbar(I)^10  # long time
>> 1
>>
>> sage: # use standard feature - sage.rings.finite_rings
>> sage: F = GF(7)
>> sage: F(1) + QQbar(1)  # standard - sage.rings.number_field
>> ...
>>
>> Please just focus on the keyword. Don't worry about minor details or 
>> punctuations: the keyword would be recognized, the rest would be ignored 
>> noise, in the implementation.
>>
>> Thanks for your attention. Happy voting :-)
>>
>  
>

-- 
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/14588592-fadb-4c30-a32b-d44c3f161a68n%40googlegroups.com.

Re: [sage-devel] Re: Modularation doctests

['Travis Scrimshaw' via sage-devel]

On Friday, June 16, 2023 at 10:18:57 AM UTC+9 Matthias Koeppe wrote:

On Thursday, June 15, 2023 at 6:03:41 PM UTC-7 Travis Scrimshaw wrote:

 Perhaps this is the core question (for me): What do you expect most/casual 
users to download and install?

It may be the wrong question because it seems to assume there is one 
population of such users.


This is an important question because it determines a lot about how we 
package and present the software. If we expect users to be technically 
savvy and tacitly understand they can ignore "# module - sage.*" doctests, 
then we can just go ahead and plaster them everywhere. If we expect people 
to peck at their keyboards with two fingers and copy/paste examples, then 
we should make sure the doc is very clean.


The population of current Sage users and developers can continue to install 
the monolithic Sage. 
Or, in the modularized terminology, they install the distribution 
"sagemath-standard".


What is going to be "Sage" then? What is my product to tell people about at 
a SageDays?


But the point why I have been working so intensely on the modularization 
project is to open parts of Sage to new populations of users and developers 
who are at home in the Python world. In particular those who find that they 
cannot use the monolithic Sage for their needs and therefore go looking for 
other projects that do not impose such constraints.

As William said, it could be a magnitude more, but it easily could be 0. 
Yes Sage is a lot to download (although if we cut out the documentation and 
continue to use system packages, I think we cut this down immensely), but 
Sage just exists in its own Python (plus some other stuff) bubble. I have 
some doubts that this will move the needle much at the cost of putting up 
development barriers, or at least increasing the learning curve, for 
non-expert-programmer-mathematicians (I might even put myself in this 
category).
 
Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/deeb3419-4aae-457a-b65c-377b553fd5a3n%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

['Travis Scrimshaw' via sage-devel]

On Friday, June 16, 2023 at 10:49:49 AM UTC+9 Kwankyu Lee wrote:

The Sage distribution will continue to exist. There will be no user-visible 
change coming from the modularization project for the users of the Sage 
distribution.


That is simply not true right now. The # optional sage.* doctests as a 
user-visible change.


Matthias means that all pieces (the sage library and external packages that 
the sage library depends on) are all there and available to a sage user 
after the modularization project.


It depends on what you mean by "there" because it is not been explained I 
think how a user should install and work with Sage afterwards. I agree it 
is clearly all available, but depending on how we tell a user to install, 
there could very well be changes.
 

That is why you (and most of us) didn't notice and care much about the 
modularization project up to now, until those massive `# optional ...` tags 
start to appear in the code you care about.


I've been following along with different pieces to see how it's going. You 
are right, in part I am bringing this up now because it is is affecting 
code I care about (and regularly use to promote Sage), but it is also 
starting to come with policy implications due to its scale that are not 
easy to revert.


I don't think we can dismiss `# optional ...` tags from the sage library if 
we embrace the modularization efforts of the sage library, as Matthias is 
trying to convince us. It is more productive to find ways to do it in more 
pleasing way.

I concur.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8c8e2626-1517-43a9-89d0-03920712c0f2n%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

['Travis Scrimshaw' via sage-devel]

Hi William,
   That is interesting. Although my take on that is following Matthias's 
proposal, they will just use one (or more) part of Sage as a Python 
library. So if they switch, in effect they will still be dropping Sage. I 
don't see Sage as having its own custom language other than some small 
syntactic sugar items (although I guess the ^ for ** is a big one for 
people switching to Python), but it does sit within its own environment 
(which has its pros and cons IMO). It is slightly annoying to bring 
everything into that environment, but I feel that we can get a bit of a 
smoother user experience this way.

I guess some of it comes down to what our target audience is. Even if we 
were just a normal Python package and just do "from sage import *", I think 
Sage would have a hard time competing against things like NumPy and 
matplotlib for those first year courses. They are currently too broadly 
used in many fields/industries, so universities will want to emphasize 
those. However, Sage is better equipped to do the more specialized math 
courses and research based computations. I don't think we have spent nearly 
enough time making our own set of teaching tools to compete; mostly that 
has been split off/overtaken by the Jupyter notebooks or in the libraries 
we build off of. I think we would need to have more of an influence in 
industry jobs to bring more universities around to saying "start Python, 
then do 'from sage.all import *'."

Perhaps this is the question that I am looking for an answer for, "What is 
Sage (after modularization)?"

Best,
Travis


On Friday, June 16, 2023 at 8:23:01 AM UTC+9 William Stein wrote:

> Hi Sage Devs,
>
> As further motivation for this discussion of "Modularization project:
> I. The goals", here is a quote from a discussion just now (with
> permission) from Eric Deeds, who is the vice chair for Life Sciences
> Math Courses and Professor of Integrative Biology and Physiology at
> UCLA:
>
> "I think we may also switch to using Python with libraries, rather
> than SageMath since Python is much more widely used."
>
> At UCLA they currently use SageMath (the full environment and
> language) with about 3K students per year, and are considering
> switching from Sage to normal Python, since sage is its own custom
> language and environment, which isn't exactly the Python language,
> etc. This is motivation for modularization of sage, since there is
> substantial functionality in Sage, e.g., "plotting vector fields",
> which they would like to use still. Of course, I did explain how it
> is possible to use normal Python and import sage via "from sage.all
> import ...". However, properly supporting using Sage from Python like
> any other Python citizen would be even better, and that's something
> that would result from the project Matthias is spearheading.
>
> -- William
>
> On Mon, Jun 12, 2023 at 4:54 PM Nathan Dunfield  
> wrote:
> >
> > On Monday, June 12, 2023 at 2:58:18 PM UTC-4 Matthias Koeppe wrote:
> >
> > What parts of Sage does SnapPy use?
> >
> >
> > Primarily the various rings/fields, including matrices over them and 
> basic linear algebra. Specifically, interval arithmetic 
> (Real/ComplexIntervalField), polynomial rings (in several variables, 
> including Laurent polynomials), number fields, and the basic rings ZZ, QQ, 
> GF, RealField, ComplexField, etc. Also, the ptolemy submodule uses Sage for 
> groebner_basis calculations. I suspect most of what we use would be part of 
> any initial pip-installable version of the Sage library. Right now, in the 
> stand-alone apps we backstop some of Sage's functionality (e.g. arbitrary 
> precision floats) with CyPari, which is itself an example of part of Sage 
> being modularized.
> >
> > Best,
> >
> > Nathan
> >
> > --
> > 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/4b14371d-b528-4b43-b350-5920259c88e1n%40googlegroups.com
> .
>
>
>
> -- 
> William (http://wstein.org)
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/91a2c3b6-a018-4931-890f-ce3ce5ced8b8n%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

['Travis Scrimshaw' via sage-devel]

On Monday, June 12, 2023 at 10:53:38 AM UTC+9 Matthias Koeppe wrote:

On Sunday, June 11, 2023 at 6:20:03 PM UTC-7 Travis Scrimshaw wrote:

My understanding of William's goal (please correct me if I am wrong) was to 
put everything together so nobody was trying to build a better wheel. To 
me, by splitting everything up into these small pieces, it seems contrary 
to that goal as how is someone suppose to know the piece they want already 
exists?


The Sage distribution will continue to exist. There will be no user-visible 
change coming from the modularization project for the users of the Sage 
distribution.


That is simply not true right now. The # optional sage.* doctests as a 
user-visible change.


My reading is that your main goal is to make Sage pip-installable, but that 
seems independent of breaking Sage up into smaller parts. Even breaking up 
Sage into smaller portions for more 'precise' dependencies for these 
supposed downstream Python developers won't really fix B and C.


It works the other way around. B and C (applied to individual Cython/Python 
modules) were/are _obstacles_ to making modularized pip-installable 
distributions.


I don't follow. Separating the components of Sage won't fix B/C, nor will 
fixing B/C split Sage into smaller components (which will actually make the 
dependency web worse).

Best,
Travis

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

Re: [sage-devel] Re: Modularation doctests

['Travis Scrimshaw' via sage-devel]

On Thursday, June 15, 2023 at 12:23:55 AM UTC+9 Matthias Koeppe wrote:

On Wednesday, June 14, 2023 at 8:01:29 AM UTC-7 Tobias Diez wrote:

On Wednesday, 14 June 2023 at 05:37:15 UTC+8 Matthias Koeppe wrote:

- Some # optional annotations reduce the barrier for contributors, by 
clearly signaling to developers "it's OK and definitely not your fault if 
you don't understand this doctest". 


[...] As a (new) user, reading "# optional - sage.symbolic" makes me more 
think "wtf. what is this? how do I install this sage.symbolic thing so that 
I can run use this example?!" than "oh, yes, this test depends on another 
part of sage, that I have not yet encountered, so I don't need to try to 
understand this example". 


This is a documentation / user education issue, which is addressed by 
writing documentation and educating the educators first.


I don't think the answer should be "read this long, technical document' to 
understand."  Even if it is a short and easy to understand, how would a 
random casual user who just heard about Sage know to even look for it? It 
seems like you want to make the people who are doing Sage outreach do more 
selling and explaining to people (who probably won't even remember such a 
minor point when they first start playing around with things). Some of it 
can be fixed by changing the nomenclature "optional" to something else as 
that suggests something a user should *add* to the installation.

Perhaps this is the core question (for me): What do you expect most/casual 
users to download and install?

Let me expand on this more. Right now, us developers distinguish between 
sage-the-library and sage-the-distribution internally, but when we go to 
"sell" our product, there is but one Sage (to rule them all). There is no 
outward facing sign that a user needs to care about the technical 
implementation details, but I feel they shouldn't. They can treat Sage as a 
black-box until they have a reason not to (e.g., trying to fix a bug or 
prove some code is correct). I think we need to keep this end-user 
experience in the forefront of our minds.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8edaf240-b378-437d-9a61-d9f37a7cd9a0n%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

['Travis Scrimshaw' via sage-devel]

I strongly disagree with your conclusion that this is a bug, much less a 
severe one. My understanding of William's goal (please correct me if I am 
wrong) was to put everything together so nobody was trying to build a 
better wheel. To me, by splitting everything up into these small pieces, it 
seems contrary to that goal as how is someone suppose to know the piece 
they want already exists? For instance, the backend libraries all have 
existed on their own, and they aren't going to change.

What you seem to be proposing is a large maintenance burden as we have to

1) Write code that keeps the modularization both "upstream" and 
"downstream" within Sage's ecosystem.
1b) Write code in nonstandard ways to break certain dependencies that are 
there in practice.
2) Write doctests with tags (at various levels, e.g., individual, block, 
module) that will need to be updated.
2) Test the code with all of the different dependencies so we don't break 
(1) and (2).

My reading is that your main goal is to make Sage pip-installable, but that 
seems independent of breaking Sage up into smaller parts. Even breaking up 
Sage into smaller portions for more 'precise' dependencies for these 
supposed downstream Python developers won't really fix B and C. I agree 
with Dima that splitting off some of the smaller pieces into 
pip-installable projects that Sage then depends on is a good thing to do, 
but I think this is better down with a bottom-up approach by taking it away 
piece by piece.

I also would like to see an increase in the number of developers and users. 
Yet, we are still primarily math software with an eye towards research, 
which means we will always have a somewhat limited developer base. I am 
hoping you could answer the following questions in detail with your next 
post.

I) How do you expect the amount of work the average developer will have to 
put in to add a new component (e.g., a Python module on a new linear 
optimization routine) to Sage? To fix a small bug? A larger bug (say, 
requiring changing 3 or 5 files)?
II) Related to (I), but what automated tools do you expect to produce and 
when will they be available? What extend will they reduce the developer 
overhead? How accessible with their output be to read?
III) How do you expect this to bring new developers in? Do you have any 
evidence (including anecdotal) that this would increase the number of 
developers? (Since switching to GH, I have not noticed much of a change in 
the number of developers or the amount of contributions. I recall this 
being one of the claimed benefits to the switch. This feels like it should 
have had a larger impact than the proposed modularization.) Why would these 
larger-Python-ecosystem developers even contribute their code to Sage 
rather than just do their own off-shoot/one-off projects (that we wouldn't 
know about)?
IV) How would a user know what components are out there? Why don't we need 
to first have a better package-manager/distribution-platform/etc. first 
(which includes all of the downstream Sage pip-packages) before we try to 
split Sage up? I would expect this to be a requirement for modularization. 
Or are you still expecting people just to install one "Sage" thing and 
never have to worry about anything else?
V) How are we going to make sure code doesn't bitrot? In particular, who is 
responsible for fixing code that breaks "downstream"? Right now, that is 
clearly the work of the author(s), but could the following situation 
happen? Suppose we have a base Sage module A, then Bob writes his own 
separate library B that depends on A that we then include as part of the 
main "Sage" distribution. I make a change to A that breaks B. Who should 
fix it? What if Bob is no longer maintaining B?

There are many things I would like to see with your proposal included into 
Sage, and thank you for undertaking such a huge project. I have some 
reservations about the benefits over the costs, and I think it would be 
beneficial to have a more detailed plan before proceeding further.

Best,
Travis

On Friday, June 9, 2023 at 4:48:15 PM UTC+9 Matthias Koeppe wrote:

> On Friday, June 9, 2023 at 12:40:52 AM UTC-7 Dima Pasechnik wrote:
>
> some other examples of such pip-installable spin-offs of parts of 
> Sage, some with binary wheels, some without, are pplpy, cysignals, 
> primecountpy 
> (more of this should come)
>
>
> Yes! Making sure that all of these have (automatically built) binary 
> wheels would be very important work.
>  
>
> At some point we should consider fully switching to gmpy2 to provide 
> interfaces for gmp, mpfr, etc.
>
>
> Indeed. This idea is tracked in 
> https://github.com/sagemath/sage/issues/35559 and if this can be done 
> without sacrificing performance, this would be a welcome simplification.
>
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

[sage-devel] Re: Modularation doctests

['Travis Scrimshaw' via sage-devel]

Hi Matthias,

Happy to see that you are curious regarding the modularization project, but 
I don't think it's a good approach to start this discussion with claims 
that sound authoritative ("nobody will actually maintain", "does not 
scale", "nearly all end users", etc.) and a policy proposal. 


Yes, you're right. I do not have any hard analytic data to support what 
users want and are doing, and that observation is based solely on my years 
of experience with working with Sage, going to and speaking at SageDays, 
and convincing people to start using Sage. However, there is clear evidence 
that the current approach is not scaling by the amount of work that is 
going in and frequent updates/fixed that is needed to be done. Currently, 
only you are the one doing this. Some of that is the lack of discussion 
(which I would like to have seen given the large scale nature of this 
change, which is implicitly setting policy by default). You can disagree 
with my conclusions and proposal, but I want to actually talk about that 
rather than having dismissive comments. Can you provide any specific 
counterpoints and your expectations? What you posted on the other thread 
does not address any of these.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/84fbc2ed-00c8-4ca6-8aa7-d4c74e8c2455n%40googlegroups.com.

[sage-devel] Modularation doctests

['Travis Scrimshaw' via sage-devel]

Dear everyone,
   I would first like to thank the people who are working to improve the 
Sage development and build process. However, I am starting to become 
concerned about what is being done about the modularization of SageMath. 
Specifically, it is involving the patchbombs (e.g., 
https://github.com/sagemath/sage/pull/35742) with labeling doctests that 
nobody will actually maintain beyond possibly Matthias. Furthermore, the 
large amount of optional labels, especially with no actual optional 
packages, is starting to scare some users. I tell them they can ignore it, 
but I feel that is not giving off a good impression. It is even more 
confounding for people who are starting to develop (e.g., the GSoC 
students).

In short, the current approach to modularization and doctests does not 
scale. I also feel the cost-benefit ratio is too high.

I think we need a new approach, something that is both hidden from the 
end-user (who will essentially never care about anything that is supposed 
to be in the "standard" distribution of Sage) and allows developers much 
more ease to actually develop (including Matthias who will largely be the 
one who will have to fix these).

My proposal is that we *only* have top-of-the-file indicators for doctests 
unless there is a very compelling reason not to. That is, always do

# sage.doctest: optional - sage.modules sage.rings.finite_rings

at the beginning of files. This will hide what should be unnecessary 
details from nearly all end users (for example, who really would not 
install symbolics with Sage on a general install?), make the public 
documentation cleaner, reduce the maintenance for modularization, be an 
easy paradigm for all developers, and have a specific location for all 
relevant information regarding dependencies.

I think there is general consensus that we should make Sage better in terms 
of being a distribution (albeit with some personal reservations with ending 
up at the "grass is greener on the other side" feeling). Yet, I really do 
not see the benefit to having such optional markings localized to 
individual doctests, which often then have to propagate to subsequent ones.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/247a2ac0-47c4-4126-afc0-fc95cf0cba56n%40googlegroups.com.

[sage-devel] Re: Ideals in LaurentPolynomialRing

['Travis Scrimshaw' via sage-devel]

Dear Enrique,
   I am having a bit of trouble understanding exactly what computations are 
slow and fast from your description. As Nils said, can you give us some 
explicit code (with some comments about which parts are slow)?

Best,
Travis

On Tuesday, May 30, 2023 at 3:28:39 AM UTC+9 Nils Bruin wrote:

> Dear Enrique,
>
> From what you write I get the impression you may be talking about a 
> regression in performance relative to earlier versions of sage. If you want 
> to make an actionable item out of this, you'll probably have to file a 
> ticket with explicit code on it that can be profiled; preferably with an 
> indication why you think the performance could be significantly improved. 
> That doesn't guarantee someone will work on it but it at least gives them a 
> place to start if they want to, including you yourself! You could file it 
> as an "enhancement" or even as a "bug" if you can convincingly show it's a 
> regression. In the latter case you would probably end up identifying a 
> version in which performance was significantly better. A git diff on some 
> of the relevant files could then perhaps very quickly show what's happening.
>
>
>
> On Monday, 29 May 2023 at 09:07:07 UTC-7 enriqu...@gmail.com wrote:
>
>> Some time ago I had some computations on ideals in Laurent polynomial 
>> rings, namely looking for minimal associated primes. Basically, I converted 
>> any generator into a polynomial, study the ideal in the polynomial ring, 
>> and forget the prime ideals containing monomials. From some time ago, it is 
>> much easier since it can be done directly in the ring of Laurent 
>> polynomials. 
>> Yesterday these computations on an ideal with 80 generators were really 
>> slow, but for some reason I checked that if the generators were converted 
>> to elements in the associated polynomial ring, and then the ideal in the 
>> Laurent polynomial ring is constructed, then those computations were solved 
>> really fast. 
>> I checked the code but I was not able to isolate the reason. Best, 
>> Enrique.
>>
>

-- 
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/0783cb4b-1485-4b98-b651-99bb4e6677dbn%40googlegroups.com.

[sage-devel] SageMath is part of GSoC 2023!

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   We were accepted as a mentor organization this year for Google's Summer 
of Code!

For those who were not previously added as a mentor last year (and want to 
be this year), please email me or respond here.

Best,
Travis

PS - Sorry for being slightly delayed on the announcement here.

-- 
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/cbfcc346-3b35-47a6-a4c1-9c1882db2812n%40googlegroups.com.

[sage-devel] Re: SkewTableaux are not hashable?

['Travis Scrimshaw' via sage-devel]

Fixed in https://github.com/sagemath/sage/pull/35138

Best,
Travis


On Wednesday, February 15, 2023 at 12:31:54 PM UTC+9 Travis Scrimshaw wrote:

> Hi Martin,
>This happens because it overrides __eq__. It probably would be better 
> to replace it by a __richcmp__ anyways, which might even fix this problem. 
> It has a few easy solutions. I will try to do a PR today for it.
>
> Best,
> Travis
>
> On Wednesday, February 15, 2023 at 3:06:58 AM UTC+9 Martin R wrote:
>
>> sage: hash(SkewTableau([[1]]))
>>
>> ---
>> TypeError Traceback (most recent call 
>> last)
>> Cell In [48], line 1
>> > 1 hash(SkewTableau([[Integer(1)]]))
>>
>> TypeError: unhashable type: 'SkewTableaux_with_category.element_class'
>>
>> It inherits from ClonableList, I would have thought that this 
>> automatically provides a hash.  But of course:
>>
>> # __hash__ is not properly inherited if comparison is changed
>> # see > >
>>
>> :-(
>>
>> Martin
>>
>

-- 
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/6e8b8d5d-09a5-4a8b-a6dc-07affad9b11dn%40googlegroups.com.

[sage-devel] Ticket (now issue/PR) tag

['Travis Scrimshaw' via sage-devel]

To the github transition team,

Is there a sphinx tag for issues to replace :trac:`12345`?

Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0c1e254a-5e05-46e5-8dfb-bd9eef1a88cfn%40googlegroups.com.

[sage-devel] Re: SkewTableaux are not hashable?

['Travis Scrimshaw' via sage-devel]

Hi Martin,
   This happens because it overrides __eq__. It probably would be better to 
replace it by a __richcmp__ anyways, which might even fix this problem. It 
has a few easy solutions. I will try to do a PR today for it.

Best,
Travis

On Wednesday, February 15, 2023 at 3:06:58 AM UTC+9 Martin R wrote:

> sage: hash(SkewTableau([[1]]))
> ---
> TypeError Traceback (most recent call last)
> Cell In [48], line 1
> > 1 hash(SkewTableau([[Integer(1)]]))
>
> TypeError: unhashable type: 'SkewTableaux_with_category.element_class'
>
> It inherits from ClonableList, I would have thought that this 
> automatically provides a hash.  But of course:
>
> # __hash__ is not properly inherited if comparison is changed
> # see 
>
> :-(
>
> Martin
>

-- 
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/346e2dd4-bca2-4e12-9e33-e66de840a805n%40googlegroups.com.

[sage-devel] Re: The definition of one blankline

['Travis Scrimshaw' via sage-devel]

Okay, so mostly this ticket is just noise by me as the specification is 
highly misleading. It is really looking for an end-of-line character \n at 
the end of the file, which does not give a blankline. It would be good if 
we could somehow explain this somewhere, especially in how the linter 
fails. Although I guess we don't have much choice about that... *sigh*

Best,
Travis


On Monday, February 13, 2023 at 4:33:36 PM UTC+9 Travis Scrimshaw wrote:

> Hi everyone,
>To me, the title seems obvious, but I hold a different opinion than the 
> linter that has become an enforced code style. I want to see what the 
> consensus of the community is on this.
>
> Paraphrasing slightly from https://www.flake8rules.com/rules/W391.html, 
> there should be one and exactly one blank line. Not zero, not two.
>
> To me, a blank line at the end of a file would be
>
> "
> blah
>
> "
>
> In particular, there is a "\n" at the end of "blah" with nothing else 
> beyond it exact the EOF character. However, our linter is currently trying 
> to enforce that files end as
>
> "
> blah
> "
>
> In particular, immediately after "blah" is the EOF. In my mind, this is 
> zero blanklines. Otherwise I see no way to obtain zero blanklines as per 
> the specification.
>
> My 2 cents, I enjoy having that blankline as additional separation of the 
> code from the bottom of my screen, although it is a bit of a more 
> historical artifact from what I found by reading SE and SO. If we agree 
> that we want to keep enforcing the current linter specification (which I 
> don't recall we agreed to as a community, but I do really appreciate all of 
> the work Frédéric has done to standardize the code) but also agree that it 
> is not enforcing one blankline, can we change the output somehow to not 
> suggest a contradiction?
>
> Best,
> Travis
>
>
>
>

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

[sage-devel] The definition of one blankline

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   To me, the title seems obvious, but I hold a different opinion than the 
linter that has become an enforced code style. I want to see what the 
consensus of the community is on this.

Paraphrasing slightly from https://www.flake8rules.com/rules/W391.html, 
there should be one and exactly one blank line. Not zero, not two.

To me, a blank line at the end of a file would be

"
blah

"

In particular, there is a "\n" at the end of "blah" with nothing else 
beyond it exact the EOF character. However, our linter is currently trying 
to enforce that files end as

"
blah
"

In particular, immediately after "blah" is the EOF. In my mind, this is 
zero blanklines. Otherwise I see no way to obtain zero blanklines as per 
the specification.

My 2 cents, I enjoy having that blankline as additional separation of the 
code from the bottom of my screen, although it is a bit of a more 
historical artifact from what I found by reading SE and SO. If we agree 
that we want to keep enforcing the current linter specification (which I 
don't recall we agreed to as a community, but I do really appreciate all of 
the work Frédéric has done to standardize the code) but also agree that it 
is not enforcing one blankline, can we change the output somehow to not 
suggest a contradiction?

Best,
Travis



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

Re: [sage-devel] Re: positively reviewed tickets on trac - do they need PRs?

['Travis Scrimshaw' via sage-devel]

It's a logical bug that didn't have a doctest; it was found when doing a 
computation further down (beyond the use-cases it was tested for). It would 
be much easier just to change it for the ticket/issue/PR/etc. It wasn't 
long after setting a positive review, but we did find it in the transition 
window.

Travis


On Thursday, February 9, 2023 at 4:56:40 PM UTC+9 dim...@gmail.com wrote:

>
>
> On Thu, 9 Feb 2023, 06:46 'Travis Scrimshaw' via sage-devel, <
> sage-...@googlegroups.com> wrote:
>
>> So we don't have PR for all of the positive reviewed tickets. They are 
>> just going to be merged? What happens if we found a problem with one of the 
>> +rev tickets and want to change something?
>>
>
> I hope Volker checks the respective issue on GitHub, whether it says 
> "positive review", or not.
>
>
>
>> Best,
>> Travis
>>
>>
>> On Thursday, February 9, 2023 at 8:43:28 AM UTC+9 Volker Braun wrote:
>>
>>> But also: Please don't merge branches into develop until it is 
>>> absolutely necessary for the github transition (issue templates or ci setup)
>>>
>>> On Tuesday, February 7, 2023 at 6:23:54 PM UTC+1 Dima Pasechnik wrote:
>>>
>>>> We have positively reviewed tickets on trac - do we need to do 
>>>> anything, or just wait for the release manager to merge them? 
>>>>
>>>> Dima 
>>>>
>>> -- 
>> 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/009d68e2-ef36-4cf3-ba5d-2af3b9f7a1afn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/009d68e2-ef36-4cf3-ba5d-2af3b9f7a1afn%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/61cf909b-0ef2-4ce2-a715-7bf9ed7cfce4n%40googlegroups.com.

[sage-devel] Re: GH Notifications

['Travis Scrimshaw' via sage-devel]

No, not that. I have set that up, but I want email notifications via GH 
anytime someone does, say, @tscrim or modifies an issue/PR I am involved 
in. I have subscribed myself and changed my GH settings to send emails. 
However, there are other repos I am involved with that I do *not* want 
emails from. All I see is an all-or-nothing for getting emails. I don't 
want to ignore GH notifications from certain repos, but I don't want to get 
emails from them either. Of course I can setup an email filter to look for 
"Sage", but I would much rather do this on the GH side.

Travis


On Thursday, February 9, 2023 at 5:04:36 PM UTC+9 Kwankyu Lee wrote:

> The "Watch" menu at the upper right corner does what you want?
>
> On Thursday, February 9, 2023 at 3:54:07 PM UTC+9 Travis Scrimshaw wrote:
>
>> I liked getting emails from trac when changes to tickets I cared about 
>> happened. However, I only want emails from notifications related to 
>> SageMath. I see that there is a routing to chose which account it will go 
>> to. Yet, I don't see a way to say "only from Sage I want email 
>> notifications".
>>
>> Is there any way to do this or do I have to set up an email filter?
>>
>> Travis
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/04cb4596-9619-4387-b5b1-684274c44fcdn%40googlegroups.com.

[sage-devel] GH Notifications

['Travis Scrimshaw' via sage-devel]

I liked getting emails from trac when changes to tickets I cared about 
happened. However, I only want emails from notifications related to 
SageMath. I see that there is a routing to chose which account it will go 
to. Yet, I don't see a way to say "only from Sage I want email 
notifications".

Is there any way to do this or do I have to set up an email filter?

Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/86daa446-adbc-43f0-bbbd-d120b10f5ce5n%40googlegroups.com.

[sage-devel] Re: positively reviewed tickets on trac - do they need PRs?

['Travis Scrimshaw' via sage-devel]

So we don't have PR for all of the positive reviewed tickets. They are just 
going to be merged? What happens if we found a problem with one of the +rev 
tickets and want to change something?

Best,
Travis


On Thursday, February 9, 2023 at 8:43:28 AM UTC+9 Volker Braun wrote:

> But also: Please don't merge branches into develop until it is absolutely 
> necessary for the github transition (issue templates or ci setup)
>
> On Tuesday, February 7, 2023 at 6:23:54 PM UTC+1 Dima Pasechnik wrote:
>
>> We have positively reviewed tickets on trac - do we need to do
>> anything, or just wait for the release manager to merge them?
>>
>> Dima
>>
>

-- 
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/009d68e2-ef36-4cf3-ba5d-2af3b9f7a1afn%40googlegroups.com.

[sage-devel] Re: Sage GSoC2023 Ideas Page

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   I know things are a bit hectic with the transition right now. However, 
the deadline for submitting our GSoC proposal is tomorrow (at least for 
me). I would appreciate it if you could add a project (you don't have to 
agree to be a mentor) or let me know if you are willing to mentor a project 
(you do not need to have a specific project in mind/written). The GSoC 
rules this year seem to indicate that the duration of the project is 
somewhat variable, and as such, can be more focused on implementing more 
targeted features. Let me know if you have any questions.

Best,
Travis


On Tuesday, January 31, 2023 at 11:42:48 AM UTC+9 Travis Scrimshaw wrote:

> Hi everyone,
>The deadline for SageMath to submit its GSoC organization application 
> is February 7th, 18:00 UTC. If you are interested in mentoring a project, 
> please post it to the ideas page:
>
> https://wiki.sagemath.org/GSoC/2023
>
> Best,
> Travis
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/83d8f2c9-0bd5-446e-8e83-a71196c6c41fn%40googlegroups.com.

[sage-devel] Re: Sage GSoC2023 Ideas Page

['Travis Scrimshaw' via sage-devel]

Hi Martin,
   I think that would be a good project. I can put in a quick sketch on the 
ideas page. It doesn't need to be anything fully thought out (that is 
really for the applicant to do in some sense).

Thanks,
Travis


On Thursday, February 2, 2023 at 6:17:30 PM UTC+9 axio...@yahoo.de wrote:

> I would be interested in continuing our work on combinatorial species, but 
> I am away until the 6th of February, and it is not clear to me whether it 
> would make a good project.  What do you think?  Are improvements to 
> existing code welcome?
>
> Martin
>
> On Tuesday, 31 January 2023 at 03:42:48 UTC+1 Travis Scrimshaw wrote:
>
>> Hi everyone,
>>The deadline for SageMath to submit its GSoC organization application 
>> is February 7th, 18:00 UTC. If you are interested in mentoring a project, 
>> please post it to the ideas page:
>>
>> https://wiki.sagemath.org/GSoC/2023
>>
>> Best,
>> Travis
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e9688e4f-a90b-4187-8cef-f027182a7e30n%40googlegroups.com.

[sage-devel] Sage GSoC2023 Ideas Page

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   The deadline for SageMath to submit its GSoC organization application is 
February 7th, 18:00 UTC. If you are interested in mentoring a project, 
please post it to the ideas page:

https://wiki.sagemath.org/GSoC/2023

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/991d6ac2-06a1-46a2-b920-d60879468fabn%40googlegroups.com.

Re: [sage-devel] Re: containment in a set different from containment in a set - help needed

['Travis Scrimshaw' via sage-devel]

> I must admit that I do not understand the philosophy.
>

Which part? 

>
> But apart from that: for classes inheriting from ClonableArray, which have 
> to implement equality (because there is no coercion to a common parent), do 
> they have to implement _richcmp_ or __richcmp__ or _eq_ or __eq__?  (The 
> amount of magic in python / sagemath is extremely confusing to me.)
>

Double underscore stuff is usually Python (sometimes Cython; or mimicked 
with __richcmp__). Single underscores tend to be hooks that Sage (or a 
particular class) has set up to either avoid inheritance issues and/or 
allow more flexibility in subclasses.

Best,
Travis


> On Tuesday, 13 December 2022 at 01:09:52 UTC+1 Travis Scrimshaw wrote:
>
>> +1 on what Nils said; I only find it slightly surprising initially. 
>> Compare this with comparing a list to a Partition as well. Equality is a 
>> bit different as a programming concept than a mathematical one. When you 
>> implement a custom __eq__, then you are separating that class from the 
>> coercion-based equality.
>>
>> +1 on removing the parent from the hash of ClonableArray and its family 
>> tree.
>>
>> Best,
>> Travis
>>
>> On Tuesday, December 13, 2022 at 1:56:46 AM UTC+9 Nils Bruin wrote:
>>
>>> On Monday, 12 December 2022 at 00:22:30 UTC-8 axio...@yahoo.de wrote:
>>>
 Ah, thank you so much!

 Just to make sure that I understand the philosophy: if two elements are 
 supposed to compare equal, they should have parents which can be coerced 
 to 
 a common parent, right?  For example, the following (which is current 
 behaviour) is not really what we want:

 sage: A = SetPartitions(3)([[1,2],[3]])
 sage: B = SetPartition([[1,2],[3]])
 sage: A == B
 True
 sage: coercion_model.common_parent(A, B)

>>> TypeError: no common canonical parent for objects with parents: 'Set 
 partitions of {1, 2, 3}' and 'Set partitions'

>>>
 I think that is a bit surprising, but if SetPartitions don't really 
>>> occur much in binary operations I think it will be a hardly visible quirk. 
>>> One has to be careful generalizing principles about how to implement 
>>> coercion/equality/hashing because we a;ready know that some of the things 
>>> we want lead to inconsistencies.
>>>
>>> When in doubt, the safe thing is definitely to NOT install coercions (it 
>>> can always be done later), so I'd hesitate to recommend to change the 
>>> behaviour above. I think you'd want at least a practical use case to 
>>> justify it.
>>>
>>> Note that the relevant conversions: A.parent()(B) and B.parent()(A) do 
>>> work.
>>>
>>> It seems to me the converse implication, if for two elements the 
>>> coercion framework is happy to find a common parent in which they compare 
>>> equal, then they should be equal in the first place, sounds a little more 
>>> probable, but I suspect one can get problematic situations from that too.
>>>
>>

-- 
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/5bb18894-a83f-4f3e-b3dd-b90687aaacc6n%40googlegroups.com.

Re: [sage-devel] Re: containment in a set different from containment in a set - help needed

['Travis Scrimshaw' via sage-devel]

+1 on what Nils said; I only find it slightly surprising initially. Compare 
this with comparing a list to a Partition as well. Equality is a bit 
different as a programming concept than a mathematical one. When you 
implement a custom __eq__, then you are separating that class from the 
coercion-based equality.

+1 on removing the parent from the hash of ClonableArray and its family 
tree.

Best,
Travis

On Tuesday, December 13, 2022 at 1:56:46 AM UTC+9 Nils Bruin wrote:

> On Monday, 12 December 2022 at 00:22:30 UTC-8 axio...@yahoo.de wrote:
>
>> Ah, thank you so much!
>>
>> Just to make sure that I understand the philosophy: if two elements are 
>> supposed to compare equal, they should have parents which can be coerced to 
>> a common parent, right?  For example, the following (which is current 
>> behaviour) is not really what we want:
>>
>> sage: A = SetPartitions(3)([[1,2],[3]])
>> sage: B = SetPartition([[1,2],[3]])
>> sage: A == B
>> True
>> sage: coercion_model.common_parent(A, B)
>>
> TypeError: no common canonical parent for objects with parents: 'Set 
>> partitions of {1, 2, 3}' and 'Set partitions'
>>
>
>> I think that is a bit surprising, but if SetPartitions don't really occur 
> much in binary operations I think it will be a hardly visible quirk. One 
> has to be careful generalizing principles about how to implement 
> coercion/equality/hashing because we a;ready know that some of the things 
> we want lead to inconsistencies.
>
> When in doubt, the safe thing is definitely to NOT install coercions (it 
> can always be done later), so I'd hesitate to recommend to change the 
> behaviour above. I think you'd want at least a practical use case to 
> justify it.
>
> Note that the relevant conversions: A.parent()(B) and B.parent()(A) do 
> work.
>
> It seems to me the converse implication, if for two elements the coercion 
> framework is happy to find a common parent in which they compare equal, 
> then they should be equal in the first place, sounds a little more 
> probable, but I suspect one can get problematic situations from that too.
>

-- 
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/b91b40db-760e-4df4-bbb8-7e1c144f9f56n%40googlegroups.com.

Re: [sage-devel] Re: GAPError when using .molien_series()

['Travis Scrimshaw' via sage-devel]

The entire computation in PermutationGroup.molien_series() all appears to 
be done in libgap. Sage's wrapper around characters is never really invoked 
at all AFAICS. Here is a curious data point:

sage: PG = PermutationGroup(["(1,2,3,4,5,6,7)","(5,6,7)"])
sage: g = PG._libgap_()
sage: pi = g.NaturalCharacter()
sage: pi += g.TrivialCharacter() * len(PG.fixed_points())
sage: pi2 = libgap.VirtualCharacter(g.CharacterTable(), pi)
sage: pi2.MolienSeries()
( 1-z^3+z^6-z^9+z^12-z^15+z^18 ) / ( 
(1-z^7)*(1-z^5)*(1-z^4)*(1-z^3)^2*(1-z^2)*(1-z) )
sage: PG.molien_series()
(-x^18 + x^15 - x^12 + x^9 - x^6 + x^3 - 1)/(x^25 - x^24 - x^23 - x^22 + 
x^21 + 2*x^20 + x^19 - x^17 - x^16 - x^15 - x^13 + x^12 + x^10 + x^9 + x^8 
- x^6 - 2*x^5 - x^4 + x^3 + x^2 + x - 1)

I just ran the code in PG.molien_series() directly first, and then calling 
it now works.

Best,
Travis

On Friday, December 9, 2022 at 8:49:55 PM UTC+9 dim...@gmail.com wrote:

> On Fri, Dec 9, 2022 at 2:55 AM 'Travis Scrimshaw' via sage-devel
>  wrote:
> >
> > By running the code in molien_series() directly in Sage, I can do the 
> computation, but not by calling the method. So it seems to be something 
> within Sage with the interface with libgap.
>
> not really, it's just the character tables in Sage that need work, for
> a proper conversion to use libgap - they cause the issue with
> moilen_series.
> The following (avoiding Sage's characters all together) works just fine:
>
> sage: p=PermutationGroup(["(1,2,3,4,5,6,7)","(5,6,7)"])
> sage: 
> ms=libgap(p).PermutationCharacter([1..7],libgap.OnPoints).MolienSeries();
> ms
> ( 1-z^3+z^6-z^9+z^12-z^15+z^18 ) / (
> (1-z^7)*(1-z^5)*(1-z^4)*(1-z^3)^2*(1-z^2)*(1-z) )
> sage: type(ms)
> 
> sage: ms.sage()
> (x_1^18 - x_1^15 + x_1^12 - x_1^9 + x_1^6 - x_1^3 + 1)/(-x_1^25 +
> x_1^24 + x_1^23 + x_1^22 - x_1^21 - 2*x_1^20 - x_1^19 + x_1^17 +
> x_1^16 + x_1^15 + x_1^13 - x_1^12 - x_1^10 - x_1^9 - x_1^8 + x_1^6 +
> 2*x_1^5 + x_1^4 - x_1^3 - x_1^2 - x_1 + 1)
> sage: type(ms.sage())
> 
>
> I'm working on https://trac.sagemath.org/ticket/26902 (fixing
> character tables would be a part of it) - and it needs more hands.
> Dima
> >
> > Best,
> > Travis
> >
> >
> > On Friday, December 9, 2022 at 8:55:15 AM UTC+9 guru@gmail.com 
> wrote:
> >>
> >> Hi,
> >> i ran into a bug while trying to compute the molien series of a 
> permutation group.
> >>
> >> SageMath version 9.3, Release Date: 2021-05-09, Using Python 3.7.10.
> >> Operating system: Windows 11, 64-bit
> >>
> >> It works fine for most permutation groups but calling:
> >>
> >> PermutationGroup(["(1,2,3,4,5,6,7)","(5,6,7)"]).molien_series()
> >>
> >> gives an GAP Error which doesn't make sense to me in the given context.
> >>
> >> GAPError: Error, ^ cannot be used here to compute roots (use `RootInt' 
> instead?)
> >>
> >> Similar examples which also produce the same bug are:
> >>
> >> PermutationGroup(["(1,2,3,4,5,7)","(5,6,7)"]).molien_series()
> >> PermutationGroup(["(1,2,3,4,7)","(5,6,7)"]).molien_series()
> >> PermutationGroup(["(1,2,3,4,7)","(5,7,8)"]).molien_series()
> >>
> >> Thanks for looking into it.
> >> Kind regards,
> >> Jonas
> >>
> >>
> > --
> > 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/2c1fcce4-946f-43cd-9ae4-a04c73434192n%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/42c6be87-614e-4a21-9273-91948f0c6216n%40googlegroups.com.

Re: [sage-devel] Re: containment in a set different from containment in a set - help needed

['Travis Scrimshaw' via sage-devel]

Let me mostly rephrase what Nils said above with a bit more of specific 
information. I would say this issue comes from a "feature" of 
ClonableArray. The default hashing of ClonableArray is to also hash in the 
parent and have elements in different parents not (by default) compare 
equal. A coercion needs to get involved for "natural" equality (i.e., 
ignoring the parent), which is a general issue within Sage.

Best,
Travis


On Monday, December 5, 2022 at 6:03:53 PM UTC+9 Nils Bruin wrote:

> On Sunday, 4 December 2022 at 23:45:00 UTC-8 j...@aims.ac.za wrote:
>
>> Note sage 9.2 (debian package) gives an error (sage 9.7 does not):
>>
>>  
> Probably the following ticket then (Scrimshaw/Chapoton):
>  
> https://trac.sagemath.org/ticket/15216 
>
>
>

-- 
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/d16d8237-e625-4256-80df-97a23528b79dn%40googlegroups.com.

[sage-devel] Re: GAPError when using .molien_series()

['Travis Scrimshaw' via sage-devel]

By running the code in molien_series() directly in Sage, I can do the 
computation, but not by calling the method. So it seems to be something 
within Sage with the interface with libgap.

Best,
Travis


On Friday, December 9, 2022 at 8:55:15 AM UTC+9 guru@gmail.com wrote:

> Hi, 
> i ran into a bug while trying to compute the molien series of a 
> permutation group. 
>
> SageMath version 9.3, Release Date: 2021-05-09,  Using Python 3.7.10. 
> Operating system: Windows 11, 64-bit
>
> It works fine for most permutation groups but calling: 
>
> PermutationGroup(["(1,2,3,4,5,6,7)","(5,6,7)"]).molien_series()
>
> gives an GAP Error which doesn't make sense to me in the given context. 
>
> GAPError: Error, ^ cannot be used here to compute roots (use `RootInt' 
> instead?)
>
> Similar examples which also produce the same bug are:
>
> PermutationGroup(["(1,2,3,4,5,7)","(5,6,7)"]).molien_series()
> PermutationGroup(["(1,2,3,4,7)","(5,6,7)"]).molien_series()
> PermutationGroup(["(1,2,3,4,7)","(5,7,8)"]).molien_series()
>   
> Thanks for looking into it. 
> Kind regards, 
> Jonas
>
>
>

-- 
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/2c1fcce4-946f-43cd-9ae4-a04c73434192n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

No, it is not. The generic fraction field can only reduce something up to a 
unit since the gcd is defined up to a unit. I agree it looks funny, but I 
don't see a sensible way to code to get a negative sign in the numerator. 
Compare with

sage: ~F(-q+1)
1/(-q + 1)
sage: ~F(q-1)
1/(q - 1)
sage: -1 / F(-q+1)
(-1)/(-q + 1)
sage: -1 / F(q-1)
(-1)/(q - 1)

Of course, there are two distinct elements here, but which ones are the 
"correct" way to print stuff? Not to mention if we are doing something in a 
more general integral domain (or polynomials with a completely different 
implementation).

Something could be done when the denominator is a unit not equal to one 
though. Possibly only in the printing however (i.e., not in the reduce() 
method and its internal representation) in order to reduce the amount of 
computations when manipulating such elements.

Best,
Travis


On Wednesday, September 21, 2022 at 10:22:30 PM UTC+9 axio...@yahoo.de 
wrote:

> sage: R. = QQ[]
> sage: F = R.fraction_field()
> sage: ~F(-1)
> 1/(-1)
> sage: 1/F(-1)
> -1
> sage: R. = QQ[]
> sage: F = R.fraction_field()
> sage: ~F(-1)
> -1
>

-- 
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/8b17a45a-c067-45b6-a2e5-5cbd80f8d6f6n%40googlegroups.com.

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

['Travis Scrimshaw' via sage-devel]

-1

On Thursday, September 22, 2022 at 11:50:56 AM UTC+9 dev@gmail.com 
wrote:

> +1 for Github
>
> 在2022年9月22日星期四 UTC+8 06:01:46 写道：
>
>> +1 for Github
>>
>> Op wo 21 sep. 2022 19:23 schreef David Roe :
>>
>>> 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+...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/CAChs6_%3DyvZ869L66E1tFmziWDirbawSEABf_uc_j9Dy8VBFW8w%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/1c0794e1-d4e8-4592-bcfe-cbcdd9496654n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 4:14:26 PM UTC+9 Matthias Koeppe wrote:

> On Tuesday, September 13, 2022 at 12:10:28 AM UTC-7 Travis Scrimshaw wrote:
>
>> How is the workflow that our current developers sometimes use irrelevant? 
>>> Granted, this is a less used feature, but I believe it makes it harder to 
>>> share branches privately. It has been useful for me in the past to have 
>>> this (e.g., some hacked together code meant only to be shared with 
>>> collaborators).
>>>
>>
> I think you'll have to explain what workflow is what you are talking 
> about, and what your concern is.
>

Let's say I want to solve the really hard problem of 2 + 2 for a paper we 
are writing. So I write a branch that does the computation by repeatedly 
adding 1: doing the computation 2 + 1 + 1. We don't plan to include this 
into Sage as it is a horrible hack nor make it public because it will lead 
to a proof of the Riemann Hypothesis (don't want to be scooped). Now you 
also want to run computations or build some code off of it. How do you get 
the code? We do not want to do a PR. With our current setup, I could push 
the branch to the server, email you the branch name, and you could pull it. 
Using GH, my understanding is we would have to share a repo and/or setup 
push/pull rights, which seems more complicated (and what if I want to get 
stuff back from you too?).

Does that clarify things? Admittedly I don't use it that often (and I am 
willing to deal with such issues as they might arise later), but I don't 
know about other practitioners at-large.

-- 
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/05414f99-c449-4951-9f76-1d73175932c8n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 3:30:19 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 10:25:57 PM UTC-7 Travis Scrimshaw wrote:
>
>> whereas with trac, things are highly concentrated on tickets, which are a 
 single point of reference. Using the GH/GL model, we have all of these 
 forks

>>>
>>> Irrelevant because in the proposed workflow you never look at another 
>>> developer's fork.
>>>
>>
>> This is not true. You do not have a central point for branch access. Now 
>> because of PRs that get attached to the main project, they do become 
>> centralized.
>>
>
> Yes, in the proposed workflow everything goes through PRs. 
>
> Yes, GitHub, like git, can also be used for other development workflows, 
> but such other workflows are not part of the proposal. Hence irrelevant.
>
> How is the workflow that our current developers sometimes use irrelevant? 
Granted, this is a less used feature, but I believe it makes it harder to 
share branches privately. It has been useful for me in the past to have 
this (e.g., some hacked together code meant only to be shared with 
collaborators).
 

-- 
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/3fb68342-7efb-42d6-8163-89905bb557e3n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 3:36:18 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 10:36:06 PM UTC-7 Travis Scrimshaw wrote:
>
>> Last I remember, using https instead of ssh meant I had to input my UN/PW 
>> every time I did a push or a pull
>>
>
>
> https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git
>  
>
I was not aware of that. I don't remember that being there when I first 
started using git and GH (some 10+ years ago I think). Perhaps I should 
have checked this more thoroughly. Nevertheless, good to know.

-- 
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/6f3dc6ec-036d-4941-a684-8e726753b0dfn%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 3:42:58 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 10:30:39 PM UTC-7 Travis Scrimshaw wrote:
>
>> Please, Travis, the high activity that you see here is in response to the 
>>> requests for having a fleshed out plan before a discussion can even happen. 
>>> So we fleshed out the plan. 
>>> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>>>
>>> Maybe I am reading too much into some of the other things that have been 
>> happening, but I got the impression that things are being written as "this 
>> is happening".
>>
>
> Yes, you are mistaken. The description of the proposed workflow has 
> "*Proposed* Workflow" in the heading.
>
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b#proposed-workflow-on-github-with-transition-guide-from-trac
> It is the draft of the transition guide to the proposed workflow.
> Of course, the transition guide itself is written from the perspective of 
> how to work with the workflow -- and working with the workflow only makes 
> sense after it has been adopted.
>

>From a number of trac tickets (mainly #30363) and the GitHub UN link thread 
coming across more as a demand to me with the imposed deadline, it gave off 
this impression. Sorry for the overstatement. 

-- 
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/664781bf-19a2-41d4-9c2d-600062d16176n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 2:10:12 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 8:39:50 PM UTC-7 Travis Scrimshaw wrote:
>
>> But people nowadays who start with GitHub never have to go through 
>>> archaic setup steps such as those that we document at 
>>> https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh,
>>>  
>>> which --- even when it is working --- is major friction for the project.
>>>
>>
>> I think it has been just far too long since you uploaded your ssh key to 
>> GH. The server cannot magically know your ssh public key. Yes, we don't 
>> have https support, but other than the most casual of contributors will use 
>> that for push/pull. I highly doubt anyone will use that feature with any 
>> serious commits.
>>
>
> You are guessing wrong. I do not use ssh with GitHub. It works perfectly 
> with https.
>

Last I remember, using https instead of ssh meant I had to input my UN/PW 
every time I did a push or a pull (or maybe it gave me 5 minutes when I 
didn't have to do it). I always felt that was clunky and after having done 
that for a week, I got sick and tired of it and Googled how to store that 
and got to the ssh approach. I figured most other people who make regular 
contributions would enjoy that convenience as well.

I am curious why you use https instead of ssh. Can you explain 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/effa7e51-d7aa-4d65-ad4d-24a68ae15386n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

>
>
> What happens when Bob works on a ticket, but then stops (say, it doesn't 
>> find a reviewer in time). Now Alice wants to make changes on top of that 
>> branch. How does Alice do that? I am particularly thinking about when this 
>> is *not* meant to be a PR review commit (say, it is working with a more 
>> substantial change or just cherry-picking some of the commits). When she is 
>> done, does she do a new PR? After doing quite a bit of digging, I finally 
>> found the answer:
>>
>>
>> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
>>
>
> Yes, this is one of the links in our document 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>

It was buried a bit in there though. I am wanting to avoid "see the fine 
print" type statements.

-- 
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/cbca0c73-c011-450d-b1d8-c111df6a7b87n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

On Tuesday, September 13, 2022 at 1:39:38 PM UTC+9 Matthias Koeppe wrote:

> On Monday, September 12, 2022 at 8:39:50 PM UTC-7 Travis Scrimshaw wrote:
>
>> First off, we need to slow down significantly as we do not have an 
>> general clear consensus about doing this move.
>>
>
> Please, Travis, the high activity that you see here is in response to the 
> requests for having a fleshed out plan before a discussion can even happen. 
> So we fleshed out the plan. 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
>
> Maybe I am reading too much into some of the other things that have been 
happening, but I got the impression that things are being written as "this 
is happening". Some of it probably is a mixing of a discussion about 
"should we do the move" versus "how we do the move (should we agree to 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/5db45a5a-7607-41b3-81fe-607a957c2162n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

>
>
> The downside (that will always remain to me) with GH/GL is anything with 
>> their web interface is highly decentralized, 
>>
>
> No, no such thing.
>

The fact that PRs and issues are on two completely different pages is 
already decentralized. There is no clear single place for discussion, with 
multiple PRs that can have their own threads.

>  
>
>> whereas with trac, things are highly concentrated on tickets, which are a 
>> single point of reference. Using the GH/GL model, we have all of these forks
>>
>
> Irrelevant because in the proposed workflow you never look at another 
> developer's fork.
>

This is not true. You do not have a central point for branch access. Now 
because of PRs that get attached to the main project, they do become 
centralized. However, I cannot easily share or get a branch from another 
developer that is not linked by a PR.

>
> (which we have to tell newbies are not the same as branches and should not 
>> be used as such).
>>
> There is also more manual things we have to type and sync subject to human 
>> (typo) error. This is likely manageable to me compared to some of the other 
>> benefits (although I will personally experience none of those). Despite 
>> this, I still have reservations about the increased pains of development 
>> from trying to fit a mostly square peg into a round hole, and subsequently 
>> am still opposed to the move
>>
>
> Sorry, this is just a rant based on nothing
>

Matthias, your dismissive attitude is not helpful. I am even starting to 
come around that this move could have benefits that outweigh the costs.

The linking of issues to PRs is something that a human has to manually type 
in, right? (Just today I mistyped a ticket number on trac.) For trac 
tickets, you would have had to not realized you were on the wrong page, 
which is far less subtle. My opposition also based on how easy it is to 
share and manage different branches and communication of things involving a 
single issue.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/32822474-46cd-4965-a777-a949cf541e1an%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

>
>
> But people nowadays who start with GitHub never have to go through archaic 
>>> setup steps such as those that we document at 
>>> https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh,
>>>  
>>> which --- even when it is working --- is major friction for the project.
>>>
>>
>> I think it has been just far too long since you uploaded your ssh key to 
>> GH. The server cannot magically know your ssh public key. 
>>
>
> You are missing that the new contributors will already have set up their 
> GitHub for virtual everything else that they work on. There is no 
> additional such cost for starting to work on a new project that's also 
> hosted on GitHub. 
> This is a just tiny bit of the big network effects that will come.
>

This is true, they do have to do it for our separate project. However, your 
characterization that the current setup is archaic is false unless you want 
to call what GH does archaic too. I also don't agree that it is a major 
friction point; all of my experience/feedback has been people have the most 
trouble getting user names to access trac and dealing with our coding/doc 
standards.

-- 
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/68256bda-39ec-473a-9afb-3f026132377en%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

>
> A few people are yelling 
>>
>
> Travis, this is inappropriate
>  
>
Matthias, then let me rephrase, a few people are speaking somewhat 
forcefully and frequently.
 

-- 
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/2f42b729-f346-4050-93ed-29e5c3af6c3cn%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

First off, we need to slow down significantly as we do not have an general 
clear consensus about doing this move. A few people are yelling we should 
move to GH, and a lot of the same people are acting like has been decided 
when it has not. We should make a formal vote once a more concrete proposal 
has been placed forward.

On Tuesday, September 13, 2022 at 4:36:04 AM UTC+9 Matthias Koeppe wrote:

> On Saturday, September 10, 2022 at 7:39:10 AM UTC-7 Travis Scrimshaw wrote:
>
>> [] There are lots of technical issues and questions I have that 
>>> [I cannot] easily find after skimming through things for a few minutes.
>>>
>>
> Everything about GitHub has excellent documentation, and we have an 
> executive summary now at 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b, with 
> pointers to the relevant bits.
>

This is still does not contain much of any details about the collaboration 
process. It is basically contains the simple single-author--single-reviewer 
model (that is easy to find) and a thesaurus of terms.

What happens when Bob works on a ticket, but then stops (say, it doesn't 
find a reviewer in time). Now Alice wants to make changes on top of that 
branch. How does Alice do that? I am particularly thinking about when this 
is *not* meant to be a PR review commit (say, it is working with a more 
substantial change or just cherry-picking some of the commits). When she is 
done, does she do a new PR? After doing quite a bit of digging, I finally 
found the answer:

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

So there is a mechanism for it, but it is not as straightforward as before. 
How do we deal with the PR pollution?

 
>
>> It stays there even if the user GitHub account is closed (the latter 
>>> triggers an automatic closure of the PR, but the underlying
>>> branch remains in the repo, it can be worked on just the same using git)
>>>
>>
>> Which repo? Either way, this seems like a regression compared to our 
>> current setup, where if a user quits, then branch, ticket, and everything 
>> remains.
>>
>
> No, this is an imaginary problem. The branch of the pull request persists 
> in the sagemath repo (see 
> https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b, 
> which explains the name of the branch) even if the user and their repo 
> disappears.
>

Okay, thanks. The extra information clarifies things.

>
> Getting the login credentials was the biggest barrier; everything else is 
 mostly straightforward and based on very simple git commands.  

>>>
 Right now, I find there are way too many practical questions and 
 barriers for how we develop that make moving to Git**b a much bigger pain 
 that people will think it is.

>>>  
>>> Travis, many people nowadays never used git without GitHub or GitLab. 
>>> For such a person it's a major pain to 
>>> learn our workflow.
>>>
>>
>> Do you really believe that everyone is using the web interface to make 
>> edits to the code and not using some form of git locally (either command 
>> line or GUI based)? 
>>
> The web interface has major problems, such as not being able to run tests 
>> locally, in addition to being unwieldy with a project on the scale of Sage. 
>> Honestly, people really don't use "git pull", "git push", "git commit" when 
>> working with *Git*hub?
>>
>
> Nothing like this is being proposed. No, GitHub is not a replacement for 
> git. Yes, you will continue to use git commands to pull, push, commit.
>
> But people nowadays who start with GitHub never have to go through archaic 
> setup steps such as those that we document at 
> https://doc.sagemath.org/html/en/developer/trac.html#trac-authentication-through-ssh,
>  
> which --- even when it is working --- is major friction for the project.
>

I think it has been just far too long since you uploaded your ssh key to 
GH. The server cannot magically know your ssh public key. Yes, we don't 
have https support, but other than the most casual of contributors will use 
that for push/pull. I highly doubt anyone will use that feature with any 
serious commits.

It seems like there are just as many one-time setup costs needing to be 
done from the proposal document that require more explanation of what they 
do. I think you are making a distinction without a difference here.
 

> And people can use modern IDEs, in particular VS Code, which have 
> excellent integration with GitHub: see for example 
> https://code.visualstudio.com/docs/editor/github 
>

This is a good reason for switching (not that I use any of them).
 

> And yes, there's also a command-line interface to GitHub, see 
> https://trac.sagemath.org/ticket/34523, which does everything that "git 
> trac" can do and much more.
>

That isn't a good argument for me: I have always wanted to throw fire and 
holy water on those commands. ;) However, they did make it 

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

> Just to give a different perspective, from someone who is not a Sage 
> developer but is a Sage donor, the only reason I give money to Sage every 
> month is because I happened to see your appeal on GitHub.


Thank you very much for your donations.
 

>   If you had no GitHub presence at all, I likely would not be a donor.  
> Not because I would not want to support Sage in that scenario, but because 
> I would not know you needed money and there would not be a button I could 
> just press to give you some (and I am not the only one, according to 
> https://github.com/sponsors/sagemath there are 25 of us and you currently 
> receive about $3000/year in donations made through GitHub).


> I think the same principle applies to attracting donations of time rather 
> than money, and these are much more important to the health of an open 
> source project.  The pool of potential Sage contributors you might attract 
> on GitHub is vastly larger than the pool of people who are motivated enough 
> to figure out how to make contributions via trac.  Yes, you will get plenty 
> of junk PRs you have to deal with on GitHub, but that does not require a 
> lot of effort and I think it would be well worth it for the sake of the 
> non-junk PRs you might get (whose main value is not the code but the person 
> behind it who might submit more PRs in the future if you make it easy for 
> them to do so).  Indeed, I can even imagine myself fixing the occasional 
> bug I come across in Sage if all I had to do was submit a PR on GitHub, and 
> there are surely many Sage users who might become Sage contributors if the 
> activation cost were low enough. 
>

If I knew that you could easily access trac, I would ask you for feedback 
on what you find about our current development process. It might be good to 
have a bit more outside opinion for this (in particular, without any help). 
Even just sketching how you think the process would go and where you had 
some struggles would be useful. Then we could explain about any of the 
specifics and see how you think it compares to PRs on GH. Only if you have 
time.

>
> I also think Aram Dermenjian made an excellent point -- in today's world 
> the value of being able to point to contributions to projects on GitHub 
> vastly exceeds the value of being able to point to a contribution you made 
> on trac (regardless of the merits of the contribution or the project 
> itself).  This does not apply just to professional software developers, it 
> also applies to students who might be your best source of future Sage 
> developers.
>

Indeed, this is a good point.

Best,
Travis
 

>
> In any case, I hope you can all come to an agreement that everyone is 
> happy with (or at least can live with)!
> On Saturday, September 10, 2022 at 7:31:48 AM UTC-4 dim...@gmail.com 
> wrote:
>
>>
>>
>> On Sat, 10 Sep 2022, 10:56 Jan Groenewald,  wrote:
>>
>>> Hi
>>>
>>> https://trac.edgewall.org/wiki/TracUsers
>>> In 2020, 21, 22, _only_ Edgewall & Trac-hacks (the trac people), and 
>>> sagemath are listed as trac users bothering to update their details.
>>>
>>> I don't know how accurate the below articles are, but found them 
>>> intersting to read. Would be interested in 
>>> comments from anyone who knows where they are inaccurate:
>>>
>>> https://kinsta.com/blog/gitlab-vs-github/#gitlab-vs-github-key-differences
>>> https://www.zdnet.com/article/github-vs-gitlab-the-key-differences/
>>> https://www.incredibuild.com/blog/gitlab-vs-github-comparison (Flow and 
>>> CI sections)
>>> https://radixweb.com/blog/github-vs-gitlab#difference
>>> I can't tell which workflow is better for sagemath. Remember feature 
>>> parity betweenm them will also change every few months!
>>>
>>> Also see what they say about themselves/each other:
>>> https://about.gitlab.com/devops-tools/github-vs-gitlab/
>>> https://resources.github.com/devops/tools/compare/
>>>
>>> It does look like github might offer more contributors. (Of high and low 
>>> quality? Perhaps the slight hurdle to logging in to gitlab the first time 
>>> is a good thing...)
>>>
>>> I'd be happy to assist with self-hosting (so gitlab) and perhaps sponsor 
>>> a container (even a separate machine for CI) but I think the sagemath 
>>> project would probably be better off on git**b. I'm also hesitant to invest 
>>> my time in learning trac/gitolite. The bus problem Dima mentioned with 
>>> self-hosting is valid. But nice to have it as an option for a quick exit 
>>> (from either git**b) when whatever happens to the companies...
>>>
>>
>> migration gitlhub->gitlab is easy, and the latter can be selfhosted on 
>> opensource code, so a migration to selfhosted gitlab should not be a 
>> problem, if needed.
>>
>>
>>>
>>> I don't think the move is so urgent though, but it should probably 
>>> happen in the next year or so.
>>>
>>
>> I don't see how the current ssh keys issue is not urgent. I think it is 
>> very urgent.
>> And in general, as I said, potential contributors 

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

['Travis Scrimshaw' via sage-devel]

>
>
> I really dislike Github's decentralized approach with PR and having to 
>> have separate clones of the repo within each user. My understanding is if 
>> two people have different fixes, then they individually submit PRs that are 
>> not explicitly linked with each other, much less with a specific bug report 
>> issue. It is not so uncommon that people end up working on competing 
>> proposals or on the same branch, both of which are not natural using 
>> Githubs PR system (I am not even entirely sure how I should do this either; 
>> Do I have to clone from their repo? Is it the same remote? Where is the 
>> documentation on this? Can I still access the branch if someone deletes 
>> their account?). How do other projects at the scale of Sage deal with this?
>
>
> It seems you never reviewed a non-trivial PR on GitHub, no?
>

Not at the scale of some of the tickets for Sage (most of it has been 
fairly small patches), and that is the problem. It is not at all clear how 
I should do that unlike our current setup.
 

> Well, you can go and have a look how e.g. CPython does it, or SciPy. 
>

Thank you for the pointer. You wouldn't happen to have specific cases that 
would make for good examples of the behaviors I mentioned above?

>
> The PR process and the underlying structure is very well-documented.
>

The basics, yes. I didn't see examples of anything beyond "contributor 
contributes code, then reviewer with project repo permissions reviews and 
merges it."
 

> A PR creates a branch in the git repo of the "main"
> project. This is really not much different from what we do on trac, except 
> that the branch name
> satisfied different rules.
>

There is a big difference you aren't even mentioning: You need to fork the 
repo locally to your UN, which has some additional setup that needs to be 
done.

Have a look at 
> https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
>

That sure looks like what you do when you are a developer for the project, 
and you get the PRs. It doesn't talk about what to do with someone else"s 
repo. The key title words are "*your* repository."

>
> E.g. using https://github.com/scipy/scipy/pull/14786 as an example, the 
> underlying branch in the repo of scipy is
> named pull/14786. 
>
> To examine it locally on your machine you can use plain git to fetch it, 
> or you can use GitHub's
> tool called cli (its functionality is close to what git-trac does, not 
> sure if you use or used git-trac, though).
>

It is not clear that if I can pull the branch from origin. There are lots 
of technical issues and questions I have that are not documented, or at 
least that I can easily find after skimming through things for a few 
minutes.

It stays there even if the user GitHub account is closed (the latter 
> triggers an automatic closure of the PR, but the underlying
> branch remains in the repo, it can be worked on just the same using git)
>

Which repo? Either way, this seems like a regression compared to our 
current setup, where if a user quits, then branch, ticket, and everything 
remains.

>
> Besides, nobody forces you to use a PR to review something. You can open 
> an issue, and ask for a specific branch somewhere (in a fork, or even in a 
> completely unrelated git branch hosted outside of GitHub) to be reviewed, 
> and only do a PR once the branch in question is stabilized.
>

At the end of the day, all paths lead to PRs. A rose by any other name 
still has thorns one needs to be careful of. 

Honestly, I doubt we are loosing that many quality contributors by not 
>> using Github's system since we can have people with GH login's to access 
>> trac.
>>
>
> except that this is broken now, (along with automatic management of ssh 
> keys in general) and one needs
> a tricky manual process (modifying a special gitolite git repo used by 
> trac) by one of trac admins
> to add/modify ssh keys.
> (and I am not even sure whether this manual process does not lead to an 
> eventual breakage of the ssh keystore, it's all tied up
> with trac in a rather arcane way).
>

This is a definite problem. 

>
> Getting the login credentials was the biggest barrier; everything else is 
>> mostly straightforward and based on very simple git commands.  
>>
>
>> Right now, I find there are way too many practical questions and barriers 
>> for how we develop that make moving to Git**b a much bigger pain that 
>> people will think it is.
>>
>  
> Travis, many people nowadays never used git without GitHub or GitLab. For 
> such a person it's a major pain to 
> learn our workflow.
>

Do you really believe that everyone is using the web interface to make 
edits to the code and not using some form of git locally (either command 
line or GUI based)? The web interface has major problems, such as not being 
able to run tests locally, in addition to being unwieldy with a project on 
the scale of Sage. Honestly, people 

Re: [sage-devel] Re: docstring of _element_constructor_

['Travis Scrimshaw' via sage-devel]

I try to make sure the ways (I first typed methods, but then realized this 
was confusing) to construct the elements is available either in the parent 
and/or element level documentation by way of examples (maybe saying, "We 
can construct a foo by giving it a list::").

Best,
Travis

On Saturday, September 10, 2022 at 1:07:27 AM UTC+9 dim...@gmail.com wrote:

> On Fri, Sep 9, 2022 at 4:43 PM davida...@gmail.com
>  wrote:
> >
> > I believe that the functionalities given by the method 
> _element_constructor_ should be at least mentioned in the main docstring of 
> the Parent.
> >
> > For example, when typing:
> >
> > sage: QQ?
> >
> > Then, the ouput explains to the user how to construct a rational number. 
> This is how I always used Sage. The documentation of _element_constructor_ 
> would be there for the developers that need to understand and modify it.
>
> Well, _things are internal, and not required to be documented.
>
> >
> > Le vendredi 9 septembre 2022 à 05:16:27 UTC-4, axio...@yahoo.de a écrit 
> :
> >>
> >> Dear all,
> >>
> >> as a user, how am I supposed to access the docstring of an 
> _element_constructor_?
> >>
> >> For example,
> >>
> >> sage: P. = QQ[]
> >> sage: P?
> >>
> >> does not give me any hint about the various ways to construct a 
> polynomial.
> >>
> >> If this is not possible other than "R._element_constructor_?", then, as 
> developers, how should we make this documentation accessible?
> >>
> >> Martin
> >
> > --
> > 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/ecf3daf3-0050-4255-84cc-472881a37e0en%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/16f92c24-d12d-475e-a4a5-ed291c357ae9n%40googlegroups.com.

[sage-devel] Re: BROADCAST MESSAGE

['Travis Scrimshaw' via sage-devel]

Thank you to everyone who has worked on getting this fixed and working 
again. A big special thanks to Frédéric for taking point (or at least 
willing to do the public relations).

Best,
Travis

On Monday, September 5, 2022 at 3:30:55 AM UTC+9 Eric Gourgoulhon wrote:

> Thank you so much Frédéric at al. for all the work in setting up the new 
> Trac!
>
> Eric.
>
>
> Le dimanche 4 septembre 2022 à 09:32:42 UTC+2, Frédéric Chapoton a écrit :
>
>> Trac 1.2 comes with various changes, including display of full names and 
>> internationalisation. You may want to look in your user preferences to 
>> customize some of these if you prefer.
>>
>> Le dimanche 4 septembre 2022 à 01:32:35 UTC+2, Kwankyu Lee a écrit :
>>
>>> Trac is now in version 1.2. 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/0898a968-1440-415e-a155-a47d4b40b7efn%40googlegroups.com.

[sage-devel] Re: tensor products of symmetric functions and PartitionTuples

['Travis Scrimshaw' via sage-devel]

Short version: no but with implementation caveats.

Longer version: It gores through generic tensor product code:

sage: s = SymmetricFunctions(QQ).s()
sage: s2 = tensor([s, s])
sage: s2.__class__


In order to have it return partition tuples (which didn't exist at the time 
this was written either), there would need to be at least a little work 
done. Nobody has had an interest in doing it as nobody has seen a benefit 
for it. However, I am +1 for the change provided it doesn't slow things 
down significantly (note that hashing, construction of the elements, and 
comparisons are done a lot in manipulating the elements in the tensor 
algebra).

Best,
Travis


On Saturday, August 27, 2022 at 4:24:18 AM UTC+9 axio...@yahoo.de wrote:

>
> Is there any good reason that the basis keys in tensor products of 
> symmetric functions are tuples of partitions and not `PartitionTuples`?
>
> Martin
>
> sage: h = SymmetricFunctions(QQ).h()
> sage: t = tensor([3*h[3], 11*h[1,1]+2*h[2]])
> sage: t
> 33*h[3] # h[1, 1] + 6*h[3] # h[2]
> sage: [(mu, c) for mu, c in t]
> [(([3], [1, 1]), 33), (([3], [2]), 6)]
> sage: type(_[0][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/467b33de-1359-4b91-aea7-a3258a8f0a34n%40googlegroups.com.

[sage-devel] Re: AlphabeticStrings()

['Travis Scrimshaw' via sage-devel]

Hi Doris,
   What would their images be in this monoid? Their capital letter versions 
are not generators of the monoid. If you would like to work in a different 
(free) monoid, then you would need to implement it (not necessarily within 
Sage). If you just want to extend the encoding, say have ß -> SS and ü -> 
U, then you are probably best writing your own encoding function to handle 
these additional cases.

Best,
Travis


On Thursday, August 25, 2022 at 3:28:52 PM UTC+9 dantetante wrote:

> Hi list,
>
> this
>
> A=AlphabeticStrings()
> s='hellowörld'
> A.encoding(s)
>
> is throwing an error. Is there any possibility of enlarging the alphabet 
> set by some chosen characters like german ü, ä, ö, ß?
> I understand that it makes no sense to enlarge to the whole ASCII 
> character set in *this* case, but I really would appreciate to have german 
> umlauts.
>
>
> Thanks in advance ...
>
> Doris
>
>
>

-- 
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/536f7a35-0cb7-4e3c-8452-2edb4c874e08n%40googlegroups.com.

[sage-devel] Re: If I run make twice in a row, shouldn't the second run be instant?

['Travis Scrimshaw' via sage-devel]

However, I don't think it should take 30 minutes, that seems far too long 
to me to check everything, even on a slow system. The longest part to me 
always seems to be checking the documentation part.

Samuel, how long does "make build" take for you?

Best,
Travis


On Thursday, August 25, 2022 at 4:45:13 AM UTC+9 Matthias Koeppe wrote:

> Our build system does not know the precise dependence of sagelib on its 
> source files and other components. 
> To know if it needs to be rebuilt, we just invoke sagelib's build system. 
> This is akin to https://trac.sagemath.org/ticket/29711
>
> Likewise for the docbuild: It kind of depends on source files and on the 
> built Sage library, but our build system does not know how it depends.
> So we just invoke the docbuild's build system and rely on its incremental 
> work to be as fast as it can be.
>
>
> On Wednesday, August 24, 2022 at 12:19:59 PM UTC-7 Samuel Lelievre wrote:
>
>> Dear sage-devel,
>>
>> Having built Sage successfully from source with the command
>> `make configure && make`, if I then immediately run `make`
>> a second time in the same shell session, shouldn't that second
>> run have nothing to build, and thus terminate almost instantly?
>>
>> Here is an example of building Sage successfully:
>>
>> ```
>> $ source .homebrew-build-env # recommended on macOS
>> $ make -s V=0 configure
>> $ make -s V=0
>>
>> ...
>>
>> [sage_conf-9.7.beta8] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sage_conf-9.7.beta8.log
>> [sage_conf-9.7.beta8] successfully installed.
>> [sagelib-9.7.beta8] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sagelib-9.7.beta8.log
>> [sagelib-9.7.beta8] successfully installed.
>> [sagemath_doc_html-none] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sagemath_doc_html-none.log
>> [sagemath_doc_html-none] successfully installed.
>>
>> real 31m44.059s
>> user 23m35.949s
>> sys 4m3.652s
>> Sage build/upgrade complete!
>> ```
>>
>> Immediately after that, in the same session,
>> without having modified any file:
>>
>> ```
>> $ make -s V=0
>>
>> ...
>>
>> [sagelib-9.7.beta8] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sagelib-9.7.beta8.log
>> [sagelib-9.7.beta8] successfully installed.
>> [sagemath_doc_html-none] installing. Log file:
>> /opt/s/sage-9-7b8-fresh-clone/logs/pkgs/sagemath_doc_html-none.log
>> [sagemath_doc_html-none] successfully installed.
>>
>> real 31m28.059s
>> user 22m3.713s
>> sys 4m12.429s
>> Sage build/upgrade complete!
>> ```
>>
>> I would have hoped for this to complete in a few seconds
>> and I find it surprising that it takes half an hour.
>>
>> Has that been reported and discussed already, either on
>> Sage Trac or on mailing lists?
>>
>> Doesn't that create problems for our Docker images?
>>
>> Apologies if I have already asked and forgotten, in which case
>> please refresh my memory. --Samuel
>>
>

-- 
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/aeef69c4-a362-4053-9226-4f6f048a8e32n%40googlegroups.com.

[sage-devel] Re: Useful methods for graphics objects

['Travis Scrimshaw' via sage-devel]

Yes we do, otherwise it doesn't make sense mathematically. There are lots 
of different metrics I can use on 2D vectors that make sense. Otherwise any 
(physical paper) maps would be very impractical. I think it is generally 
bad practice to assign mathematical significant things to classes that are 
not used for mathematical purposes.

I have no idea what your argument is for the second part. Separations of 
concerns means object A (in this case, an object for drawing something in 
3D) only does things that are meant for object A (drawing stuff) and not do 
things that are meant for object B (a vector or line segment in Euclidean 
space). It has nothing to do with what you use to actually do the 
implementation. If you are worried about linking together stuff that 
shouldn't be needed, that to me is a code smell.

Best,
Travis

On Wednesday, August 24, 2022 at 10:14:22 AM UTC+9 Kwankyu Lee wrote:

> On Wednesday, August 24, 2022 at 9:18:06 AM UTC+9 Travis Scrimshaw wrote:
>
>> Éric, what do you think about adding such things to SageManifolds? Could 
>> this be feasible?
>>
>
> It is embarrassing that  an idea of attaching ".length()" method to a line 
> segment graphics object leads to SageManifolds. We don't need vectors and 
> inner products to compute the length of a line segment.
>
> If we ever implement the idea, then it should be done with basic python 
> only for "separations-of-concerns" and for modularization of sage.
>
>  
>

-- 
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/f7e92932-0704-47dd-b6d9-0504bb612fe3n%40googlegroups.com.

[sage-devel] Re: Trac only displaying some comments

['Travis Scrimshaw' via sage-devel]

Ah, I see. That fixed it. Thanks. I never knew about that as I never paid 
any attention to that box. it is annoying that changed on a Firefox 
update...Oh well.

Best,
Travis


On Wednesday, August 24, 2022 at 10:06:05 AM UTC+9 Matthias Koeppe wrote:

> Try the checkbox "Show property changes" on the ticket?
>
> On Tuesday, August 23, 2022 at 6:02:53 PM UTC-7 Travis Scrimshaw wrote:
>
>> I think this is something that has to do with more recent versions of 
>> Firefox, as I can see everything in Chrome, but I only see the changes to 
>> the ticket that have comments. So if someone, say, changes only the branch 
>> field or the milestone, I do not see these. Is there something that can be 
>> done to trac to fix this? This has been annoying me for a while now, but I 
>> am now tired to the wasted time working around it.
>>
>> Best,
>> Travis
>>
>>

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

[sage-devel] Trac only displaying some comments

['Travis Scrimshaw' via sage-devel]

I think this is something that has to do with more recent versions of 
Firefox, as I can see everything in Chrome, but I only see the changes to 
the ticket that have comments. So if someone, say, changes only the branch 
field or the milestone, I do not see these. Is there something that can be 
done to trac to fix this? This has been annoying me for a while now, but I 
am now tired to the wasted time working around it.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cacfec4d-87b8-4012-a724-d39e8bd99c5en%40googlegroups.com.

[sage-devel] Re: Trac #34152 needs you (to vote)!

['Travis Scrimshaw' via sage-devel]

hybrid > sage psuedo > copy files package

I think we should be mindful that there can be people who build from source 
who are not developers. So not having a dependency on git is a small bonus, 
but I think almost everyone who has a non-Windows machine has git installed 
on their computer by default. I also fully agree with Dima that gnulib has 
no business being in Sage's git tree, and if I understand the hybrid 
approach, it remains separate as a separate (cloned) git repo.

Best,
Travis


On Wednesday, August 24, 2022 at 9:04:58 AM UTC+9 Matthias Koeppe wrote:

> Thanks for sending out the poll, Francois.
>
> I endorse the "hybrid" variant.
>
> On Tuesday, August 23, 2022 at 4:38:40 PM UTC-7 François Bissey wrote:
>
>> Hi all,
>>
>> https://trac.sagemath.org/ticket/34152 needs help to decide what 
>> solution we implement going forward.
>>
>> The ticket is concerned with updating the bootstrap process by removing 
>> the current need for gettext and replacing it with gnulib (
>> https://www.gnu.org/software/gnulib). gnulib is not a regular software 
>> library but a collection of bits and pieces to help portability across 
>> platforms.
>>
>> The issue at hand is how do we include and use gnulib in sagemath.
>> Matthias Koeppe and Dima Pasechnik have been arguing for several weeks 
>> and across most of the ~250 comments of the ticket about the way to 
>> proceed. At some point it became clear that they would not agree and would 
>> need arbitration. This is what this post is about, I am inviting the 
>> sagemath community to weigh in and decide the issue.
>>
>> The ticket summary has been updated with summaries of the problem and of 
>> both options along with links to branches implementing them. I would not 
>> recommend diving in the comment section.
>>
>> There are 3 (three) options to choose from, one from Matthias, one from 
>> Dima and a hybrid approach they tried to create.
>>
>> -- copy files --
>>
>>- Follows approach 3 of the Gnulib manual section 'Integration with 
>>Version Control Systems' 
>>
>>.
>>- 5 files, in config/ and m4/, total 112 KB, have been imported by 
>>using `gnulib-tool import iconv` 
>>
>>  
>> and 
>>committed to the branch.
>>- Matches our practice with imported files `m4/ax_*.m4` 
>> from 
>>autoconf-archive 
>>. 
>>Different from our practice with SPKGs because the files are needed to 
>>generate the configure script.
>>- Introduces no new dependency.
>>- Burden on a developer who authors an update ticket for these files: 
>>Obtain gnulib by cloning the repo, then re-run gnulib-tool import, 
>>remove unneeded files (that's where #29549 
>> went wrong), commit the 
>>changes. (Updates are expected to be necessary only very rarely.)
>>- Burden on users and other developers: None.
>>- dimpase's criticism of this approach: "gnulib's code is not Sage's 
>>code, it has no place in Sage git tree; this way, updating the imported 
>>gnulib files is tricky and error-prone by design".
>>
>> -- sage pseudo package --
>>
>>- Follows approach 2(C) of the Gnulib manual section 'Integration 
>>with Version Control Systems' 
>>, 
>>but instead of using Gnulib's Programs for developing in Git checkouts 
>>
>> , 
>>implements its own script (making checkout much faster, as full gnulib 
>> checkout 
>>is 250 MB).
>>- Introduces a new (although one can't really do Sage development 
>>without git installed) dependency on git and on availability of 
>>internet connection at the first run of ./bootstrap in a tree, to 
>>pull 83 MB (fair to say that internet is needed for Sage development a 
>> lot, 
>>anyway).
>>- Burden on a developer who authors an update ticket for these files: 
>>Edit the bootstrap file to change the commit hash, verify that the 
>>list of files removed by make bootstrap-clean is still correct, 
>>commit this change
>>- Burden on other users: a pseudo-package needs to be installed once 
>>(and updated, automatically)
>>- mkoeppe's criticism of this approach: "Having bootstrap operate a 
>>multi-megabyte git clone (on the 1st install and when there's a change of 
>>the gnulib commit hash) in the upstream/ directory increases 
>>complexity for no benefit."
>>
>> -- hybrid --
>>
>>- Resolves the criticism on the "copy files" approach: "updating the 
>>imported gnulib files" is now assisted by the spkg-src script 
>>(adapted from dimpase's 

[sage-devel] Re: source and build artifacts mixed ?

['Travis Scrimshaw' via sage-devel]

Could it be easily possible to get something inbetween? I like having the 
.c files there next to the file (although I have to retrain myself a bit 
with typing) rather than having to hunt for them in some obscure 
not-well-documented directory. However, I would like that when I make 
changes to py files, I do not reload my Sage with these (potentially 
broken) changes and want the current behavior. I have had to do a lot of 
stashing when writing tests to make sure behavior doesn't change.

Best,
Travis


On Wednesday, August 24, 2022 at 2:59:19 AM UTC+9 Nils Bruin wrote:

> That's probably due to
>
> https://trac.sagemath.org/ticket/32406 'Make "./configure 
> --enable-editable" the default'
>
> among other things, sys.path now has '$SAGE_ROOT/src' in it. That explains 
> why the "so" files are there, and the .c files are probably a consequence 
> of how cython compiles under those conditions.
>
> On Tuesday, 23 August 2022 at 10:43:53 UTC-7 Thierry 
> (sage-googlesucks@xxx) wrote:
>
>> Hi,
>>
>> i recently found that the src/sage directory was cluttered with some .c
>> and some .so files, and that the build artifacts were back in the src/
>> directory. What is the rationale behind this move ?
>>
>> Ciao,
>> Thierry
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d97b71e9-9b5a-4601-a646-d7f53266032an%40googlegroups.com.

[sage-devel] Re: Useful methods for graphics objects

['Travis Scrimshaw' via sage-devel]

In general, I think we are best leaving the drawing classes to just drawing 
as a separations-of-concerns. It sounds like we need better integration 
between our algebraic objects/implementations and the drawing/plotting 
tools. This might include more plot_* functions or specialized 
mixin-/sub-classes for small dimensional (sub)spaces. Likewise we might 
want to add some general tools for inner product spaces, such as 
"ind_closest_point() or shortest_distance(), with an assumption of course 
that we can do calculus on the vector space.

As an alternative, if we want to think of objects specifically living in 
Euclidean space, we have the EuclideanSpace(n) for this with specialized 
subclasses for 2d and 3d. Perhaps we should implement some of the features 
you want using objects there, such as line (segment) as a subclass of the 
curve? For piecewise differentiable curves, this might require some more 
programming.

Éric, what do you think about adding such things to SageManifolds? Could 
this be feasible?

Best,
Travis

On Tuesday, August 23, 2022 at 4:26:11 PM UTC+9 Kwankyu Lee wrote:

> On Monday, August 22, 2022 at 12:04:57 PM UTC+9 Travis Scrimshaw wrote:
>
>> I am not sure how much I support that because there is no metric. 
>>
>
> It is of course euclidean, as you say
>  
>
>> you can do
>>
>> sage: l = line3d([(1,2,3), (4,5,6)])
>> sage: V = RR^3
>> sage: (V(l.points[1]) - V(l.points[0])).norm()
>> 5.19615242270663
>>
>
> My point is to attach methods to graphics objects for handy computation. I 
> am not sure if this is technically doable. 
>  
>
>> There could also be other natural interpretations of length here, such as 
>> the number of (non-colinear) segments.
>>
>
> (1) .length() could be an alias of .line3d_euclidean_length() as this is 
> most useful. 
>
> (2) .line3d_combinatorial_length(): I doubt if this is useful for drawing.
>
> Is this more pedagogical or are you using 3d line segments in some 
>> meaningful way?
>>
>
> Pedagogical and meaningful :) I thought of this idea while drawing 
> graphics to prepare lecture notes for a class next semester. 
> If graphics objects get more powered, then drawing (2d or 3d) mathematical 
> pictures, which is always difficult, would get less difficult. 
>
> For another example,  we may implement a method to compute the 
> intersection point given two line segments (as tikz can do in latex)
>

-- 
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/13870a33-c3d8-45cc-865d-48a918002e03n%40googlegroups.com.

[sage-devel] Re: sage.combinat.integer_vector_weighted.iterator_fast arguments

['Travis Scrimshaw' via sage-devel]

I thought it produced wrong results when it was for some composition? 
Perhaps I am mistaken or that was some older version of the code. If the 
logic is valid for any composition, then we can change the doc.

Best,
Travis


On Monday, August 22, 2022 at 7:59:22 PM UTC+9 axio...@yahoo.de wrote:

> The docstring of iterator_fast says that the weights should be weakly 
> decreasing.
>
> It seems to me that the code actually works for any composition, or am I 
> missing something?
>
> Martin
>
> def iterator_fast(n, l):
> """
> Iterate over all ``l`` weighted integer vectors with total weight 
> ``n``.
>
> INPUT:
>
> - ``n`` -- an integer
> - ``l`` -- the weights in weakly decreasing order

-- 
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/6d53a93a-fa65-43f2-b2a8-f4d55e7a500cn%40googlegroups.com.

Re: [sage-devel] Graph([(0,'a')]).vertices() raises exception

['Travis Scrimshaw' via sage-devel]

I think it is a very bad idea to have default sorting based upon hashing. 
This could make a lot of output appear seemingly random (despite having a 
natural order), nor there is no way to deal consistently with hash 
collisions. This would cause far more problems than it would solve when 
working with incomparable objects.

Best,
Travis


On Friday, August 19, 2022 at 9:05:23 PM UTC+9 ggun...@gmail.com wrote:

> On Wed, Jul 13, 2022 at 5:46 PM John H Palmieri  
> wrote:
> >
> > "Fix your old code" could just mean using `vertices(sort=False)`. See 
> also https://trac.sagemath.org/ticket/22349.
> >
>
> fixing the sort() appears easy:
>
> >>> li=['a',0]
> >>> li.sort(key=hash);li
> [0, 'a']
>

-- 
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/7891a0c7-8a26-47e5-be9d-0dbb8775b060n%40googlegroups.com.

[sage-devel] Re: Useful methods for graphics objects

['Travis Scrimshaw' via sage-devel]

I am not sure how much I support that because there is no metric. If you 
are working with the Euclidean metric (the usual one you are used to), then 
you can do

sage: l = line3d([(1,2,3), (4,5,6)])
sage: V = RR^3
sage: (V(l.points[1]) - V(l.points[0])).norm()
5.19615242270663

There could also be other natural interpretations of length here, such as 
the number of (non-colinear) segments.

Is this more pedagogical or are you using 3d line segments in some 
meaningful way?

Best,
Travis

On Friday, August 19, 2022 at 6:26:31 PM UTC+9 Kwankyu Lee wrote:

> Hi,
>
> I wish  that this would work:
>
> sage: l = line3d([(1,2,3),(2,2,3)])
> sage: l.length()
> 1
>
> Is there already a handy way to get the same result in Sage?
>
> You can image other useful methods attached to a graphics object.
>
>
>
>

-- 
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/7ba749b5-e6d2-4024-973f-ff9832b36e12n%40googlegroups.com.

Re: [sage-devel] Re: LazyPowerSeriesRing Replacement

['Travis Scrimshaw' via sage-devel]

I will let Martin discuss the naming as I think the is attached to the name 
LazyTaylorSeries(Ring). A quick counterpoint to Kwankyu's claim, the power 
series "is" a function (well, formally), we just usually think of it as 
being equal to an "easier" function.

However, it is meant to be a complete replacement with removing the old 
LazyPowerSeriesRing code. This new version should be faster, more robust, 
and have more functionality.

Best,
Travis


On Monday, August 15, 2022 at 5:06:29 PM UTC+9 vdelecroix wrote:

> On Mon, 15 Aug 2022 at 09:50, John Cremona  wrote:
> >
> > On Mon, 15 Aug 2022 at 08:21, Kwankyu Lee  wrote:
> > >
> > > If LazyTaylorSeriesRing could be a complete replacement of 
> LazyPowerSeriesRing, then I think we should remove the old 
> LazyPowerSeriesRing
> > > and rename LazyTaylorSeriesRing to LazyPowerSeriesRing. Do you mean 
> this?
> > >
> > > Mathematically, Taylor series means power series derived from a 
> function. So aTaylor series is always attached to a function. The name 
> LazyTaylorSeriesRing seems a misnomer.
> >
> > I agree with all these points!
>
> Me too.
>

-- 
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/5e4f1036-1898-41ba-80b4-6fbba24bca37n%40googlegroups.com.

[sage-devel] LazyPowerSeriesRing Replacement

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   Now that https://trac.sagemath.org/ticket/32324 is positively reviewed, 
I was wondering if there would be any opposition to replacing the current 
LazyPowerSeriesRing with the next LazyTaylorSeriesRing. This is already 
happening as the backend for species in 
https://trac.sagemath.org/ticket/32367. Are there any features missing that 
people want from LazyPowerSeries?

I should also point out that the framework on 
https://trac.sagemath.org/ticket/32324 also easily allows us to work with 
formal infinite series over any graded algebra (at least where each graded 
piece is a finite sum of elements). I plan on doing the slight refactoring 
and adding a noncommutative Cauchy product stream to the code to support 
this somewhat soon for some computations I need.

Best,
Travis

PS - Side question: Do we have q-commuting polynomials as a graded algebra 
in Sage? I don't think so, but perhaps there is an easy way to construct 
it. I know in 2 variables, I can build it as a SkewPolynomialRing in y over 
R['x'], but this it doesn't have the right grading.

-- 
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/ae105d3b-cab5-4cb7-85df-fec395e485ben%40googlegroups.com.

[sage-devel] Re: MSC-2020 -- Class 52: Convex and Discrete Geometry -- CAS Citations from 2000 to 2021

['Travis Scrimshaw' via sage-devel]

Indeed, it is not only great to see that Sage is increasing in the number 
of citations* but also the total number of papers citing mathematics 
software.

Best,
Travis

* In algebraic combinatorics, I sometimes notice that people give an 
acknowledgement that they have used Sage to help with their paper without 
actually citing Sage. This makes it harder for simple data mining tools to 
pick up I think. I also know of some papers that have used Sage to 
construct examples without even an acknowledgement... So there work to do 
on making sure the broader math community does properly cite (or at least 
acknowledge) the use of a CAS. (As I say this, I think I forgot to cite 
Mathematica in one of my papers that one of my coauthors used somewhat 
extensively...)


On Friday, August 12, 2022 at 2:44:10 PM UTC+9 kcrisman wrote:

> I take this opportunity to thank the Sage community and the developers of 
>> related softwares integrated for this Huge effort and to let you know of 
>> the positive comments that I receive form the research community in MSC-52. 
>> THANK YOU SO MUCH!
>>
>> If you are interested in a deeper analysis, I produced detailed graphics 
>> and provide the raw data in a Jupyter notebook on my webpage:
>>
>> https://jplab.github.io/sage_cite.html
>
>
> Great post! 
>

-- 
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/dc80e2fa-a1d8-4fc4-832f-82746b8193d8n%40googlegroups.com.

[sage-devel] Re: Proposal: downgrade some packages to experimental

['Travis Scrimshaw' via sage-devel]

I would like to see the p_group_cohomology fixed. Progress got stalled on 
that, but I am happy to work on that (while I have time for August).

Best,
Travis


On Sunday, August 7, 2022 at 5:23:46 AM UTC+9 Matthias Koeppe wrote:

> The sage_numerical_backends_* packages are on their way out anyway.
> Coin support will switch to go through CVXPy in 
> https://trac.sagemath.org/ticket/34251, and Gurobi/CPLEX likewise in a 
> follow up ticket
>
> On Saturday, August 6, 2022 at 1:09:37 PM UTC-7 John H Palmieri wrote:
>
>> Thank you for the link. With this ticket, the gurobi and cplex backends 
>> still fail because I don't have gurobi and cplex installed. It would be 
>> nice if that was detected earlier in the process and the build failed right 
>> away. Actually, it is detected early in the process:
>>
>>   /bin/sh: gurobi.sh: No such file or directory
>>   GUROBI_HOME is not set, or it does not point to a directory with a 
>> Gurobi installation.  Trying to link against -lgurobi
>>
>> but the installation proceeds anyway. But this is a separate issue.
>>
>> On Saturday, August 6, 2022 at 12:39:00 PM UTC-7 Matthias Koeppe wrote:
>>
>>> This one is https://trac.sagemath.org/ticket/34221
>>>
>>> On Saturday, August 6, 2022 at 11:55:36 AM UTC-7 John H Palmieri wrote:
>>>
 Also, the various sage_numerical_backend_* packages fail to build, with 
 errors like


   Error compiling Cython file:
   
   ...
   from sage.numerical.backends.generic_backend cimport GenericBackend
   ^
   

   check_add_col_untyped_args.pyx:1:0: 
 'sage/numerical/backends/generic_backend.pxd' not found


 Also downgrade? Is there a ticket for this?

 On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:

> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>
>> The following packages do not build for me on OS X 12.5 (Monterrey), 
>> Intel chip:
>>
>>- polylib (#33758)
>>- symengine_py (#34141)
>>- p_group_cohomology (#30787)
>>- r_jupyter
>>- rubiks
>>
>> I propose that these be downgraded from optional to experimental 
>> until the issues are fixed. What do people think?
>>
>>
> Also on various Linux platforms (
> https://github.com/sagemath/sage/actions/runs/204587) I see 
> failures for
> symengine_py, 
> p_group_cohomology, 
> r_jupyter
>
> So these 3 definitely need to be changed to "experimental".
>
>
>  
>


-- 
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/975cb633-de43-4cba-8c67-286c413c4ceen%40googlegroups.com.

[sage-devel] Re: Group algebra bug

['Travis Scrimshaw' via sage-devel]

I posted on the ticket a long debug of the issue, which comes down to a 
subtlety with making copies of PermutationGroup_generic and its __dict__.

Best,
Travis


On Sunday, August 7, 2022 at 3:57:59 AM UTC+9 Trevor Karn wrote:

> Sorry of course the parent of kH(a) and kH.one() are the same. We do see 
> that the parents of the indexing elements are different despite being 
> mathematically the same:
>
> sage: a.parent()
> sage: list(kH.one().monomial_coefficients())[0].parent()
>
> Permutation Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]
> Permutation Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]
> sage: list(kH.one().monomial_coefficients())[0].parent() is a.parent()
> False
>
> On Saturday, August 6, 2022 at 11:53:03 AM UTC-7 Trevor Karn wrote:
>
>> The following bug was reported on sage-support, which I was able to 
>> reproduce on 9.7.beta7.
>>
>> sage: H = PermutationGroup([[(1,2), (3,4)], [(5,6,7),(12,14,18)]])
>> sage: kH = H.algebra(GF(2))
>> sage: H.gens()
>> ((5,6,7)(12,14,18), (1,2)(3,4))
>> sage: a, b = H.gens()
>> sage: x = kH(a) + kH(b) + kH.one(); x
>> (5,6,7)(12,14,18) + (1,2)(3,4) + ()
>> sage: x*x
>> Traceback (most recent call last):
>> ...
>> RuntimeError: There is a bug in the coercion code in Sage.
>> Both x (=()) and y (=(5,6,7)(12,14,18)) are supposed to have identical 
>> parents but they don't.
>> In fact, x has parent 'Permutation Group with generators 
>> [(5,6,7)(12,14,18), (1,2)(3,4)]'
>> whereas y has parent 'Permutation Group with generators 
>> [(5,6,7)(12,14,18), (1,2)(3,4)]'
>> Original elements () (parent Permutation Group with generators 
>> [(5,6,7)(12,14,18), (1,2)(3,4)]) and (5,6,7)(12,14,18) (parent Permutation 
>> Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]) and maps
>>  None
>>  (map 
>> internal to coercion system -- copy before use)
>> Coercion map:
>>   From: Permutation Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]
>>   To:   Permutation Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]
>>
>> I'm confused about why this is happening because
>>
>> sage: kH(a).parent()
>> Algebra of Permutation Group with generators [(5,6,7)(12,14,18), 
>> (1,2)(3,4)] over Finite Field of size 2
>> sage: kH.one().parent()
>> Algebra of Permutation Group with generators [(5,6,7)(12,14,18), 
>> (1,2)(3,4)] over Finite Field of size 2
>> sage: kH(a).parent() is kH.one().parent()
>> True
>>
>> which I would think should mean that the condition on line 1323 of 
>> sage/src/sage/structure/coerce.pyx that the parents are the same should be 
>> tripped, but for some reason, it is not. I printed the hash of the parents 
>> right before the bug (added it in between lines 1322 and 1323)  and they 
>> have the same hash (547464660303730434), so I am surprised that they are 
>> not considered the same. They are however recognized to be equal, and so 
>> the elif statment checking if they are equal (on line 1327) is triggered, 
>> but then the coercion of y_elt to parent(x_elt) on line 1329 seems to fail, 
>> so that the parent comparison on 1330 still fails, kicking it out to the 
>> coercion error.
>>
>> I'm unsure how to fix this but am willing to do the legwork to fix it if 
>> anyone can explain the problem. 
>>
>> Opening https://trac.sagemath.org/ticket/34292.
>>
>>
>> Full traceback:
>>
>> sage: H = PermutationGroup([[(*1*,*2*), (*3*,*4*)], [(*5*,*6*,*7*),(*12*,
>> *14*,*18*)]])
>>
>> sage: kH = H.algebra(GF(*2*))
>>
>> sage: H.gens()
>>
>> ((5,6,7)(12,14,18), (1,2)(3,4))
>>
>> sage: a, b = H.gens()
>>
>> sage: x = kH(a) + kH(b) + kH.one(); x
>>
>> (5,6,7)(12,14,18) + (1,2)(3,4) + ()
>>
>> sage: x*x
>>
>>
>> ---
>>
>> RuntimeError  Traceback (most recent call 
>> last)
>>
>> Input In [7], in ()
>>
>> > 1 x*x
>>
>>
>> File ~/Applications/sage/src/sage/structure/element.pyx:1514, in 
>> sage.structure.element.Element.__mul__()
>>
>> *   1512* cdef int cl = classify_elements(left, right)
>>
>> *   1513* if HAVE_SAME_PARENT(cl):
>>
>> -> 1514 return (left)._mul_(right)
>>
>> *   1515* if BOTH_ARE_ELEMENT(cl):
>>
>> *   1516* return coercion_model.bin_op(left, right, mul)
>>
>>
>> File ~/Applications/sage/src/sage/structure/element.pyx:1560, in 
>> sage.structure.element.Element._mul_()
>>
>> *   1558* raise bin_op_exception('*', self, other)
>>
>> *   1559* else:
>>
>> -> 1560 return python_op(other)
>>
>> *   1561* 
>>
>> *   1562* cdef _mul_long(self, long n):
>>
>>
>> File ~/Applications/sage/src/sage/categories/coercion_methods.pyx:53, in 
>> sage.categories.coercion_methods._mul_parent()
>>
>> * 51* True
>>
>> * 52* """
>>
>> ---> 53 return (self)._parent.product(self, other)
>>
>>
>> File ~/Applications/sage/src/sage/categories/magmatic_algebras.py:215, in 
>> MagmaticAlgebras.WithBasis.ParentMethods._product_from_product_on_basis_multiply(self,
>>  
>> left, right)
>>
>> *201* *def* 

[sage-devel] Re: Polling for sphinx background style

['Travis Scrimshaw' via sage-devel]

I slightly protest that one day of voting at the end of the week is not a 
lot of time for such a consequential vote.

That being said, I support grayish (but I also noticed there is so little 
difference on dark mode).

Best,
Travis


On Saturday, August 6, 2022 at 6:14:54 PM UTC+9 Kwankyu Lee wrote:

> Up to now, the voting counts
>
> (1) grayish: 5
> (2) detoned: 1
> (3) no opinion: 1
>
> So I conclude that grayish is the winner. 
>
> Let me close the voting. Once again, I thank you who participated. 
>
> The new doc will be prepared according to the result.
>

-- 
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/e1dfc105-b480-4cf4-ab76-4d5ca80718d0n%40googlegroups.com.

[sage-devel] Re: Docstring Formatting Question: Bullet Points

['Travis Scrimshaw' via sage-devel]

I don't think we should mandate things so much, but it would be good to 
have a general policy about this. For example, we have a policy about error 
messages, but this is not absolute. In particular, this is about breaking 
ties when an author is doing something that a reviewer dislikes. I don't 
think effectively telling the community they can do whatever they like is 
so useful. (I suspect Frédéric could say a few words about this will all of 
the changes he has been doing to standardizing much of the code and 
documentation.) We should also be cognizant of the what is in the 
developer's manual can easily be interpreted as our convention 
choices/general policies (and has sometimes been referenced by reviewers in 
this manner).

Best,
Travis

On Wednesday, July 13, 2022 at 12:39:42 PM UTC+9 Kwankyu Lee wrote:

> On Wednesday, July 13, 2022 at 12:13:28 PM UTC+9 John H Palmieri wrote:
>
>> I am "no" to having a Sage policy dictating blank lines, and I am also 
>> "no" to having a policy dictating no blank lines. 
>>
>
> We do have conventions in the developer manual by which sage developers 
> are "dictated". Specifically the blank line convention is suggested by 
> Examples in the developer manual: 
>
>
> https://doc.sagemath.org/html/en/developer/coding_basics.html#headings-of-sage-library-code-files
>
> So perhaps Travis wants to revise the Examples if we reach to a consensus.
>  
>
>

-- 
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/ddd430bf-ebdd-45a7-98c6-c2611405cf70n%40googlegroups.com.

[sage-devel] Docstring Formatting Question: Bullet Points

['Travis Scrimshaw' via sage-devel]

Right now there are two conventions throughout Sage for bullet points (and 
similar things). Someone has been systematically trying to change 
everything to one convention (which I am opposed to). However, we as a 
community have not had a discussion about this as far as I am aware (I 
believe also changing the example doc page at some point). I figured we 
should have this conversion now.

The question is this: Should there be blanklines between bullet points:

Pros (these are the ones I can see, but I am biased):

- It makes it more clear what bullet point is which.

- It could be easier to read as it looks less like a big paragraph of text.

Cons:

- IMO it looks really bad when there are few bullet points and they are 
really short.
- I find it *harder* to separate bullet points from non-bullet points, 
especially when
  separated by single lines

  * This includes sublists, which must have a blank line before/after them 
(just like normal lists).

- It makes it more clear that these bullet points should be thought of as a 
single
  collection.
- Because blanklines separates a list from the body of text, it makes it 
seem like
  the bullet points are each their own list of single items.

Note that this does not change the compiled doc, but I typically am not 
looking at that.

What is your opinions? I think it is clear that I am for no blanklines 
between bullet points.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5039446f-3d96-4065-a9eb-7be070ebb1e6n%40googlegroups.com.

[sage-devel] Re: Implementing Parent with Facade that is not an Element

['Travis Scrimshaw' via sage-devel]

Hi Trevor,
   Right...I remember coming across this problem before. Since I know this 
class is for internal use (simply to index a basis), we can override 
__call__() instead of _element_constructor_() as we do not need to invoke 
the coercion framework (and we want this to be fast). This is what the 
subsets code does too.

Best,
Travis


On Tuesday, June 21, 2022 at 1:20:07 AM UTC+9 Trevor Karn wrote:

> Hi all,
>
> I am trying to implement a Parent in the category of 
> FiniteEnumeratedSets().Facade(). My hope was to have the finite enumerated 
> sets be represented by `Bitset 
> `s.
>  
> Upon testing, I get the error: TypeError: Cannot convert 
> sage.data_structures.bitset.Bitset to sage.structure.element.Element. I 
> also get the same error when I set facade=True in the Parent.__init__ call. 
> I think this behavior makes sense because (as I understand it) the facade 
> elements should be elements of *some* parent, just not the parent `self`. 
> On the other hand, Bitsets are not an element of any parent.
>
> Does anyone have advice on how to proceed? I can think of a few options:
>
> - Make Bitsets an Element. This doesn't seem desirable because Bitsets is 
> Cythonized, and as I understand it, Cython doesn't play nice with the 
> Parent/Element framework (please correct me if I misunderstand).
>
> - Make an Element class for my Parent which inherits from both element and 
> Bitset. This doesn't seem desirable because I want my parent to be in 
> FiniteEnumeratedSets().Facade().
>
> I don't like either of those options, does anyone have suggestions on what 
> else I could do?
>
> Thanks so much!
>
> -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/5646a2cb-22d5-43bb-bcbd-b92b0119fb00n%40googlegroups.com.

[sage-devel] Re: Finite dimensional algebra generated by matrices

['Travis Scrimshaw' via sage-devel]

Yes, you have. To better integrate it into Sage, I would expand the 
existing functionality of FiniteDimensionalAlgebra (and ideally it would do 
the basis and multiplication table lazily) . This class would likely need 
some additional work to get it to do what you eventually want, but it would 
make for a good project. Note that FiniteDimensionalAlgebra already has a 
class for ideals.

Sage, in principle, should also be able to construct any subalgebra of a 
finite-dimensional algebra given by generators using some of its generic 
code (i.e., not just from a subalgebra of all matrices) through a simple 
modification of your code. (In practice, I think the matrices are 
essentially compatible up to dealing with issues of mutability. I don't 
know how much this has been tested though...)

Some general coding advice: Python is an object-oriented programming 
language. This means you can organize your code into logical groupings 
called "classes" that give additional information about what the data 
represents. So rather than having a bunch of unrelated functions, they can 
become more tied together (of course, when this appropriate). It is wise to 
take advantage of this.

Best,
Travis

On Sunday, June 12, 2022 at 12:30:27 PM UTC+9 Yingdong Li wrote:

> Dear Travis,
>
> I think my code already has the function you mentioned(the function named 
> "basis_of_algebra" is used to build a basis, and we can plug it in the 
> "ideal" function to get the ideal we want, see line 53-139). I'm not sure 
> whether I misunderstood your advice. Anyway, thanks for your advice and 
> welcome to point out more  problem about my code(we can still discuss it 
> here)!
>
> Best wishes,
> Li Yingdong
>
> 在2022年6月10日星期五 UTC+8 08:38:41 写道：
>
>> One thing you could consider doing is adding an option for the input of 
>> the finite dimensional algebra code to take the generators as input and 
>> then use that to generate a basis and feed that back into the finite 
>> dimensional algebra. I am sure I have written code to compute a basis from 
>> a generating set in at least one form somewhere in Sage. It seems like this 
>> code needs to be factored out to be used for purposes like this.
>>
>> Best,
>> Travis
>>
>>
>> On Thursday, May 26, 2022 at 4:12:41 PM UTC+9 Yingdong Li wrote:
>>
>>> Dear all,
>>>
>>> I have put my code in GitHub(with some explanation of it) so that you 
>>> can clearly see it. 
>>>
>>> Here's a link of my code in GitHub(see the code called "Finite generated 
>>> algebra as a ring")
>>> Dongulas/Dongulas: Config files for my GitHub profile. 
>>> 
>>>
>>> Best wishes,
>>> Li Yingdong
>>>
>>> 在2022年5月17日星期二 UTC+8 21:37:06 写道：
>>>
 Dear Travis,

 Thanks for your advice! The finite dimensional algebra code in Sage 
 need a multiplication table, so the second part of our code is used to 
 find 
 the multiplication table with the basis of the algebra. And the first part 
 of our code is used to find the basis with the generators of the 
 algebra(along with a ideal of the polynomial ring). Our aim is to find the 
 ring structure of the algebra generated by a list of commuting matrices.

 Best wishes,
 Li Yingdong

 在2022年5月15日星期日 UTC+8 11:16:24 写道：

> I would advise against having it as an external package if you plan to 
> integrate it into Sage. It further fragments the code and makes it more 
> likely to bitrot from what I have seen. I would instead create a ticket 
> and 
> upload the code to that.
>
> Is this a finite dimensional commutative algebra? We already have 
> finite dimensional algebras (with no assumptions, e.g., associativity) in 
> Sage. How does your code compare with this code? Could they be combined?
>
> Best,
> Travis
>
>
> On Thursday, May 12, 2022 at 9:55:55 PM UTC+9 davida...@gmail.com 
> wrote:
>
>> Hello,
>>
>> Most of the SageMath developpment is explained in this guide:
>>
>>   https://doc.sagemath.org/html/en/developer/index.html
>>
>> Also, I don't know exactly what is the scale of your code, but I 
>> would advise you to first upload your code to Github (if it isn't 
>> already 
>> done) as an external package. Github is very convenient for sharing 
>> code, 
>> so it would be easier to share it with the community. Next, I think to 
>> contribute to SageMath it is better to start with small contribution. 
>> For 
>> example, review some tickets or fix some bugs. Then, it becomes easier 
>> to 
>> contribute to bigger projects. 
>>
>> Anyway, welcome to the community and good job on your research 
>> project!
>>
>> David Ayotte
>>
>> Le jeudi 12 mai 2022 à 05:45:53 UTC-4, Yingdong Li a écrit :
>>
>>> Dear all,
>>>
>>> I have written some codes in Sage to compute the finite-dimensional 
>>> 

[sage-devel] Re: Finite dimensional algebra generated by matrices

['Travis Scrimshaw' via sage-devel]

One thing you could consider doing is adding an option for the input of the 
finite dimensional algebra code to take the generators as input and then 
use that to generate a basis and feed that back into the finite dimensional 
algebra. I am sure I have written code to compute a basis from a generating 
set in at least one form somewhere in Sage. It seems like this code needs 
to be factored out to be used for purposes like this.

Best,
Travis


On Thursday, May 26, 2022 at 4:12:41 PM UTC+9 Yingdong Li wrote:

> Dear all,
>
> I have put my code in GitHub(with some explanation of it) so that you can 
> clearly see it. 
>
> Here's a link of my code in GitHub(see the code called "Finite generated 
> algebra as a ring")
> Dongulas/Dongulas: Config files for my GitHub profile. 
> 
>
> Best wishes,
> Li Yingdong
>
> 在2022年5月17日星期二 UTC+8 21:37:06 写道：
>
>> Dear Travis,
>>
>> Thanks for your advice! The finite dimensional algebra code in Sage need 
>> a multiplication table, so the second part of our code is used to find the 
>> multiplication table with the basis of the algebra. And the first part of 
>> our code is used to find the basis with the generators of the algebra(along 
>> with a ideal of the polynomial ring). Our aim is to find the ring structure 
>> of the algebra generated by a list of commuting matrices.
>>
>> Best wishes,
>> Li Yingdong
>>
>> 在2022年5月15日星期日 UTC+8 11:16:24 写道：
>>
>>> I would advise against having it as an external package if you plan to 
>>> integrate it into Sage. It further fragments the code and makes it more 
>>> likely to bitrot from what I have seen. I would instead create a ticket and 
>>> upload the code to that.
>>>
>>> Is this a finite dimensional commutative algebra? We already have finite 
>>> dimensional algebras (with no assumptions, e.g., associativity) in Sage. 
>>> How does your code compare with this code? Could they be combined?
>>>
>>> Best,
>>> Travis
>>>
>>>
>>> On Thursday, May 12, 2022 at 9:55:55 PM UTC+9 davida...@gmail.com wrote:
>>>
 Hello,

 Most of the SageMath developpment is explained in this guide:

   https://doc.sagemath.org/html/en/developer/index.html

 Also, I don't know exactly what is the scale of your code, but I would 
 advise you to first upload your code to Github (if it isn't already done) 
 as an external package. Github is very convenient for sharing code, so it 
 would be easier to share it with the community. Next, I think to 
 contribute 
 to SageMath it is better to start with small contribution. For example, 
 review some tickets or fix some bugs. Then, it becomes easier to 
 contribute 
 to bigger projects. 

 Anyway, welcome to the community and good job on your research project!

 David Ayotte

 Le jeudi 12 mai 2022 à 05:45:53 UTC-4, Yingdong Li a écrit :

> Dear all,
>
> I have written some codes in Sage to compute the finite-dimensional 
> algebra by a list of commuting matrices and I want to contribute it to 
> Sage. Here is the idea of my codes.
>
> 1. We can construct the algebra as a quotient of a polynomial ring(by 
> using the homomorphism which sends each x_i to t_i, where t_1,...,t_n is 
> the n matrices generate the algebra), we can also get the basis by doing 
> this.
>
> 2. With the basis of the algebra, we can also compute the 
> multiplication table then use the finite-dimensional algebra command in 
> Sage to get a description to this algebra.
>
> Once we have done with these things above, we can get the ring 
> structure of the algebra. This is very useful in dealing with some 
> problems 
> about modular forms since we can further study the prime ideals or 
> maximal 
> ideals of Hecke algebra by using its ring structure.
>
> I'm an undergraduate student and this is part of my research project. 
> I was wondering how I can contribute the codes to Sage. Could anyone give 
> me some help me with this(since I'm not so familiar about the Sage trac 
> and 
> I'm not sure where I can share my codes)? Thanks in advance!
>
> Moreover, if you have some questions or comments on this, we can 
> discuss about it here.
>
> Best wishes,
> Li Yingdong
>
>
>
>
>

-- 
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/d16609cd-facb-4cf6-b2fb-fdaafda313cbn%40googlegroups.com.

Re: [sage-devel] Question about factories, representations and multiple classes

['Travis Scrimshaw' via sage-devel]

> > The __classcall_private__() mechanism works well for this kind of 
> dispatching 
> > with lots of examples within Sage for this. 
>
> Agreed, and this is fairly standard. However, I am still skeptical about 
> the 
> fact this mechanism prevents deep copies... This limits the user's 
> abilities. 
>
> I have no idea what you mean by that. I feel like you are confusing that 
with UniqueRepresentation, which is a completely different concept 
(although they are typically paired together since we want to normalize the 
input). You can have a __classcall_*_() without being a 
UniqueRepresentation. You might also want to think about why you need to 
make (deep) copies.

Best,
Travis

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/423429c0-7ca6-4e08-b3a2-b68414722f67n%40googlegroups.com.

Re: [sage-devel] Question about factories, representations and multiple classes

['Travis Scrimshaw' via sage-devel]

>
> I'm also relatively new to Sage development, but one thing I can think of 
> is that you could create a constructor module for your implementation of 
> Drinfeld module. In short, the way I see it is that you would have a new 
> module named "constructor" with a class "constructor.FiniteDrinfeldModule" 
> which would be available to the end user. This "constructor class" would 
> take care of formatting the user input and would return a 
> "FiniteDrinfeldModule_rank_two" or a "FiniteDrinfeldModule_generic" 
> depending of the input. This would also give you the opportunity of giving 
> some liberty to the user when creating a Drinfeld module (via a list, an 
> additive polynomial, etc...)
>

I am generally -1 on this. There can be specific reasons for doing this, 
most of those involve fairly complicated object creation at the cost of 
disassociating the construction from the actual object returned. The 
__classcall_private__() mechanism works well for this kind of dispatching 
with lots of examples within Sage for this.

A quick general comment: The module should be a parent and vectors should 
be elements. Maps between them are elements of the Homset, which would be a 
parent.

Best,
Travis
 

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

Re: [sage-devel] (cy)PARI in Parallel, Heisenbugs, and Merging Policy

['Travis Scrimshaw' via sage-devel]

That sure seems like it. So what should we do about the ticket? Would there 
be opposition to merging this piece of code, as there doesn't seem like 
there is a fix coming for the likely underlying cypari bug anytime soon?

Best,
Travis


On Sunday, May 15, 2022 at 4:14:31 PM UTC+9 vdelecroix wrote:

> Probably related to https://github.com/sagemath/cypari2/issues/107 ?
>
> Le 15/05/2022 à 05:06, 'Travis Scrimshaw' via sage-devel a écrit :
> > Hi everyone,
> > On ticket #30423 <https://trac.sagemath.org/ticket/30423>, Dan, Willie,
> > and I have been working on a parallel-computation based implementation 
> for
> > computing F-matrices that are used in math physics. However, we have been
> > seeing some doctest failures sporadically that involve segfaults and
> > linked-list corruption from (cy)PARI. Here are the logs from testing with
> > the first and the last having full tracebacks.
> > 
> > http://sporadic.stanford.edu/badlog-match
> > http://sporadic.stanford.edu/badlog
> > http://sporadic.stanford.edu/badlog1
> > http://sporadic.stanford.edu/badlog2
> > http://sporadic.stanford.edu/badlog3
> > 
> > The first question would be if anyone has an idea about what is causing
> > this. I have this impression that PARI is thread-safe, but I am wondering
> > if cypari is also thread/parallel-safe or if there are any specific 
> things
> > that we should be careful about. (We’ve already had to work around a
> > pickling issue with polynomials IIRC.)
> > 
> > Second question is that because this is a Heisenbug and I suspect it is
> > something upstream (and so far, nobody has been able to reproducing it
> > during an interactive version of Sage), I was wondering what the policy
> > would be for merging the ticket. I recall in the past that we have merged
> > tickets with Heisenbugs with followup tickets noting the behavior, but I 
> am
> > not 100% sure about that (and I wouldn’t necessarily know how to find any
> > explicit examples). I was wondering if we could merge the ticket in an
> > early beta version so that many people/systems can test it to see if it
> > becomes more reproducible; of course this is assuming that the build bots
> > are not consistent in reproducing this. Should we just mark any offending
> > test(s) as “# known bug” and is there some general policy about this?
> > 
> > Thanks,
> > Travis
> > 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/23dca745-b13f-47b6-9662-dc75f6109784n%40googlegroups.com.

Re: [sage-devel] Question about factories, representations and multiple classes

['Travis Scrimshaw' via sage-devel]

For this you want to use __classcall_private__ as otherwise you would 
likely end up in an infinite loop when you try to construct the subclass. 
There are lots of examples of this in the Sage library code.

Best,
Travis


On Sunday, May 15, 2022 at 5:42:49 AM UTC+9 Eric Gourgoulhon wrote:

> Hi, 
>
> Le samedi 14 mai 2022 à 00:07:02 UTC+2, David Roe a écrit :
>
>> I think the following should work:
>>
>> class MyObject:
>> def __classcall__(cls, arg):
>>  if isinstance(arg, special):
>>  return typecall(MyObject_specific_case, arg)
>>  else:
>>  return typecall(MyObject, arg)
>>
>> plus the same __init__ you had before.  I haven't checked it though
>> David
>>   
>>
>
> An alternative is to use __classcall_private__
> For an example, see the class EuclideanSpace in
> src/sage/manifolds/differentiable/examples/euclidean.py 
> 
>
> EuclideanSpace(n) actually returns an instance of the subclass 
> EuclideanPlane if n = 2 or of the subclass Euclidean3dimSpace if n = 3.
>
> Best wishes,
>
> Eric.
>

-- 
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/8280058a-377a-43ca-baab-1b96f5257a05n%40googlegroups.com.

[sage-devel] Re: Adding combinatorial divisorial polytopes to sagemath

['Travis Scrimshaw' via sage-devel]

There are chances, but it depends on many independent factors, such as 
availability and mathematical expertise. However, before that could be 
considered, you will need to provide the code first.

Best,
Travis

On Saturday, May 14, 2022 at 7:07:02 AM UTC+9 ie.bat...@gmail.com wrote:

> Hi,
>
> I created a ticket https://trac.sagemath.org/ticket/33830 for 
> implementing new functionality and going to work on it by myself. Are there 
> any chances that anyone will review my pull request any time soon if I will 
> submit it within the next couple of weeks?

-- 
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/6cd2566b-b121-4346-88f1-d08e25943c23n%40googlegroups.com.

[sage-devel] Re: Finite dimensional algebra generated by matrices

['Travis Scrimshaw' via sage-devel]

I would advise against having it as an external package if you plan to 
integrate it into Sage. It further fragments the code and makes it more 
likely to bitrot from what I have seen. I would instead create a ticket and 
upload the code to that.

Is this a finite dimensional commutative algebra? We already have finite 
dimensional algebras (with no assumptions, e.g., associativity) in Sage. 
How does your code compare with this code? Could they be combined?

Best,
Travis


On Thursday, May 12, 2022 at 9:55:55 PM UTC+9 davida...@gmail.com wrote:

> Hello,
>
> Most of the SageMath developpment is explained in this guide:
>
>   https://doc.sagemath.org/html/en/developer/index.html
>
> Also, I don't know exactly what is the scale of your code, but I would 
> advise you to first upload your code to Github (if it isn't already done) 
> as an external package. Github is very convenient for sharing code, so it 
> would be easier to share it with the community. Next, I think to contribute 
> to SageMath it is better to start with small contribution. For example, 
> review some tickets or fix some bugs. Then, it becomes easier to contribute 
> to bigger projects. 
>
> Anyway, welcome to the community and good job on your research project!
>
> David Ayotte
>
> Le jeudi 12 mai 2022 à 05:45:53 UTC-4, Yingdong Li a écrit :
>
>> Dear all,
>>
>> I have written some codes in Sage to compute the finite-dimensional 
>> algebra by a list of commuting matrices and I want to contribute it to 
>> Sage. Here is the idea of my codes.
>>
>> 1. We can construct the algebra as a quotient of a polynomial ring(by 
>> using the homomorphism which sends each x_i to t_i, where t_1,...,t_n is 
>> the n matrices generate the algebra), we can also get the basis by doing 
>> this.
>>
>> 2. With the basis of the algebra, we can also compute the multiplication 
>> table then use the finite-dimensional algebra command in Sage to get a 
>> description to this algebra.
>>
>> Once we have done with these things above, we can get the ring structure 
>> of the algebra. This is very useful in dealing with some problems about 
>> modular forms since we can further study the prime ideals or maximal ideals 
>> of Hecke algebra by using its ring structure.
>>
>> I'm an undergraduate student and this is part of my research project. I 
>> was wondering how I can contribute the codes to Sage. Could anyone give me 
>> some help me with this(since I'm not so familiar about the Sage trac and 
>> I'm not sure where I can share my codes)? Thanks in advance!
>>
>> Moreover, if you have some questions or comments on this, we can discuss 
>> about it here.
>>
>> Best wishes,
>> Li Yingdong
>>
>>
>>
>>
>>

-- 
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/3db7757d-79e0-42c5-af43-33c85cc13fdan%40googlegroups.com.

Re: [sage-devel] The SageMath developer map needs your (updated) information

['Travis Scrimshaw' via sage-devel]

I think I have used a “malformed” email address in the past (which github 
won’t recognize/accept) with “at” instead of “@“ to try and avoid some 
spambots, so we might need to change the history in order to fix mine…

Best,
Travis


On Tuesday, May 10, 2022 at 2:11:00 AM UTC+9 Matthias Koeppe wrote:

> https://github.com/sagemath/sage/graphs/contributors already has a good 
> visualization of the time axis.
>
> But some data is missing -- fchapoton's contributions appear to stop in 
> 2019, tcscrim is missing completely.
>
> Maybe people could take the time to check which email addresses used on 
> commits have been made known to GitHub?
>
>
> On Monday, May 9, 2022 at 9:54:29 AM UTC-7 vdelecroix wrote:
>
>> It would be cool to have map locators for the quadruple 
>>
>> (person, time, affiliation, trac id) 
>>
>> (no affiliation being an option). That way we could make many 
>> maps out of one. And in particular visualize the evolution of 
>> sage development. 
>>
>> Vincent 
>>
>> Le 09/05/2022 à 09:59, David Roe a écrit : 
>> > For former contributors who are no longer active, do we have a policy 
>> about 
>> > saying their current institution/company versus where they were when 
>> they 
>> > were contributing to Sage? 
>> > David 
>> > 
>> > On Mon, May 9, 2022 at 3:51 AM Dima Pasechnik  
>> wrote: 
>> > 
>> >> On Sun, May 8, 2022 at 9:51 PM Matthias Koeppe  
>> >> wrote: 
>> >>> 
>> >>> https://www.sagemath.org/development-map.html 
>> >>> 
>> >>> To add yourself or to update your information: edit 
>> >> https://github.com/sagemath/website/blob/master/conf/contributors.xml 
>> and 
>> >> send a pull request 
>> >> 
>> >> there are lots of `http:` URLs there which should become `https:` 
>> >> Also, some contributors don't have their trac logins mentioned. 
>> >>> 
>> >>> 
>> >>> 
>> >>> 
>> >>> -- 
>> >>> 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/019ca0a8-5d4c-45d2-8505-1a548bbe98een%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/CAAWYfq1b0j6t-Z0cR8bBzv7CDK8bGwvXooSeqe7SLjTSZdu_NQ%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/304bb24b-8bda-40bd-bba0-7dd1915c464cn%40googlegroups.com.

[sage-devel] (cy)PARI in Parallel, Heisenbugs, and Merging Policy

['Travis Scrimshaw' via sage-devel]

Hi everyone,
   On ticket #30423 , Dan, Willie, 
and I have been working on a parallel-computation based implementation for 
computing F-matrices that are used in math physics. However, we have been 
seeing some doctest failures sporadically that involve segfaults and 
linked-list corruption from (cy)PARI. Here are the logs from testing with 
the first and the last having full tracebacks.

http://sporadic.stanford.edu/badlog-match
http://sporadic.stanford.edu/badlog
http://sporadic.stanford.edu/badlog1
http://sporadic.stanford.edu/badlog2
http://sporadic.stanford.edu/badlog3

The first question would be if anyone has an idea about what is causing 
this. I have this impression that PARI is thread-safe, but I am wondering 
if cypari is also thread/parallel-safe or if there are any specific things 
that we should be careful about. (We’ve already had to work around a 
pickling issue with polynomials IIRC.)

Second question is that because this is a Heisenbug and I suspect it is 
something upstream (and so far, nobody has been able to reproducing it 
during an interactive version of Sage), I was wondering what the policy 
would be for merging the ticket. I recall in the past that we have merged 
tickets with Heisenbugs with followup tickets noting the behavior, but I am 
not 100% sure about that (and I wouldn’t necessarily know how to find any 
explicit examples). I was wondering if we could merge the ticket in an 
early beta version so that many people/systems can test it to see if it 
becomes more reproducible; of course this is assuming that the build bots 
are not consistent in reproducing this. Should we just mark any offending 
test(s) as “# known bug” and is there some general policy about this?

Thanks,
Travis


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ab4daa9c-7353-408a-a5c5-cb14cff1fc03n%40googlegroups.com.

Re: [sage-devel] orbit decompositions

['Travis Scrimshaw' via sage-devel]

>
> Sorry, I don't know an easy way. I've always just defined them by hand 
>> whenever needed. 
>> However, I agree with you that a better way is needed. 
>>
>
> I would love for there to be some standard way to define a group action on 
> a set - preferably maintaining other algebraic properties of the set, such 
> as addition!  But I don't know if there is even close to a standard way to 
> do this either. 
>

- There is a standard way to do this, but not a generic method/class for it 
IIRC. You can do this by implementing an _act_on_() method on a wrapper 
class. Yet, this requires some manual input.
- For cyclic actions, there is the DiscreteDynamicalSystem class introduced 
in https://trac.sagemath.org/ticket/24128.
- There is also the Representation class in 
modules/with_basis/representation.py if you want to want to extend the 
action on the set to the module with a basis given by that set.

Likely we will want to implement a class SetWithAction that automates a 
collects the orbit_decomposition functions and similar together as methods 
as a single global entry point.

Best,
Travis


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/37eff638-b07c-4f07-b525-13a5a0ef7a69n%40googlegroups.com.

[sage-devel] Re: Memory Leak in canonical_label with bliss?

['Travis Scrimshaw' via sage-devel]

Hi Thomas,
   Sorry for taking so long to respond as I was away from my computer last 
week to test.

Yes, I seem to be seeing it as well. However, if it is within bliss, then 
it needs to be solved upstream (and/or with a patch here).

Best,
Travis


On Tuesday, April 26, 2022 at 5:47:07 AM UTC+9 t.will...@gmail.com wrote:

> Hi Travis,
> I do not know whether the leak is caused within bliss or by sage's wrapper 
> unfortunately.
> But can you reproduce the problem?
> Best,
> Thomas
>
>
>
> On Monday, April 25, 2022 at 2:49:07 AM UTC+2 Travis Scrimshaw wrote:
>
>> Hi Thomas,
>>Could the memleak be coming from within bliss?
>>
>> Best,
>> Travis
>>
>>
>> On Sunday, April 24, 2022 at 1:50:26 AM UTC+9 t.will...@gmail.com wrote:
>>
>>> Dear all,
>>>
>>> there seems to be a memory leak in canonical_label(...), using bliss.
>>> Here is a test script to demonstrate the problem:
>>>
>>> -
>>>
>>> import os, psutil
>>>
>>> from sage.all import *
>>>
>>> process = psutil.Process(os.getpid())
>>> oldmem = process.memory_info().rss
>>>
>>> for i in range(100):
>>> G = graphs.RandomGNM(10,20)
>>> canonG = G.canonical_label(algorithm='bliss')
>>> # canonG = G.canonical_label(algorithm='sage')
>>>
>>> if i%1000 == 0:
>>>print(f"graph count {i}, mem usage (Delta) {process.memory_info
>>> ().rss - oldmem}")
>>>oldmem = process.memory_info().rss
>>>
>>> 
>>>
>>> This uses up more and more memory if I use 'bliss' as algorithm:
>>> On my machine around 260KB/1000 calls are lost.
>>> Invoking garbage collection manually does not help.
>>> I believe this might be a bug.
>>>
>>> There is no memory leak using 'sage' as algorithm.
>>>
>>> Info on my system:
>>> MacBook Pro with M1 processor, macOS Monterey,
>>> sage 9.4, bliss 0.73
>>>
>>> Thanks a lot for your help,
>>>
>>> Thomas
>>>
>>> P.S.: The amount of memory lost in the sample script is small on an 
>>> absolute scale, but our  programs run for a week or two and we end up 
>>> losing many GB.
>>> The obvious bugfix is to use algorithm='sage', but this is twice slower 
>>> than bliss.
>>>
>>>
>>>
>>>
>>>

-- 
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/b249581b-e41c-4763-98ff-3e7be47991e9n%40googlegroups.com.