[sage-devel] Is this feature: (x+y+3).reduce(Ideal([x*(x-1),y*(y-1)])) == x+y+3
sage: K.=QQ[] sage: I=[x*(x-1),y*(y-1)] sage: a=x+y+3 sage: a.reduce(Ideal(I)) x + y + 3 In addition: sage: Kq=K.quotient(I);Kq(a) xbar + ybar + 3 sage: Ideal([a]+I).groebner_basis() [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/CAGUWgD-OvonwOD9wM_35Sbutn13M%2Bdr4gJd7Gsd%3Dg0qdDLujeA%40mail.gmail.com.
[sage-devel] Re: Modularation doctests
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.
Re: [sage-devel] Modularization project: I. The goals
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-de
Re: [sage-devel] Modularization project: I. The goals
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. 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 have been fixing B and C (in numerous tickets) so that I can make modularized distributions. It didn't come for free; but I have already done most of the necessary work... and clear plans for the other work required. [...]. I am hoping you could answer the following questions in detail with your next post. [...] Thanks a lot for your questions; I'll address them in post II. -- 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/edfe190d-f7af-4563-8c50-d02c780f9547n%40googlegroups.com.
Re: [sage-devel] Modularization project: I. The goals
On Sun, Jun 11, 2023 at 6:53 PM 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? > > I didn't split things up into small pieces only because it is very, very difficult, takes a lot of time, and I just didn't have the resources to do it. Other priorities like increasing doctest coverage were higher. >From a software engineering perspective modularization is very valuable, and if we had more resources we definitely would have divided Sage into more modular blocks long ago. I'm extremely glad that Matthias is working on this difficult problem, and I appreciate that you (Travis) are putting so much effort into clarifying what the heck is going on. Sage is about building the car instead of reinventing the wheel. However, cars are built out of a large number of modular components (e.g., wheels, carburetor, etc.), and it's good engineering to put a lot of effort into properly building those components. I'm absolutely blown away and thrilled Sage is still around after almost 20 years, and that you guys are actually doing that sort of work! -- 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/CACLE5GDK52DwDg13NZo5kFRzRLZE876pEFvb07keJcsteV9i-w%40mail.gmail.com.
