Oscar.jl
Oscar.jl copied to clipboard
oscar-system
Saturation with ordering
Adds a monomial ordering as optional parameter to saturation calls. This addresses #1487 , but needs to be generalized in the future when we allow different GB engines for computing saturations.
For modules we have a field default_ordering to handle this issue. If an ordering independent command (which hence should not have an ordering argument) like ideal or module operations is using Groebner bases, this field is used. The user can change the field or it can be populated automatically depending on the properties of the ring over which the object lives (e.g. a tensor product structure or bi-homogeneity leading to the appropriate ordering). For ideals we will have to do something similar.
PS: The field is in the module e.g. SubModuleOfFreeModule, not in ModuleGens.
@jankoboehm Let us take the example of an ideal quotient or saturation, where two ideals are involved. What if these ideals have different default-orderings?
Then it depends on the command which of the two you should take and the command should do that accordingly. But typically that should not happen since the field is set according to properties of the ring and both ideals are in the same ring.
I think it would make sense to keep the discussion at https://github.com/oscar-system/Oscar.jl/issues/1487 and not split it.
In order to make the user interface consistent I have also updated quotient to allow a monomial ordering as an optional parameter.
With this ordering keyword, we are now forcing singular_assure to use the specified ordering.
One question.
Would it ever be advantageous to see if the input ideals already have a singular version stored with identical base rings, and use that ordering instead of forcing it with the ordering keyword? I am thinking of the case when the user doesn't specify an ordering (saturation(I, J)). In this case, if both I and J already have a singular version in an ordering other than default_ordering(base_ring(I)), I am wondering it is silly to recompute things in this default ordering rather than to use the existing versions.
That is what I am trying in https://github.com/oscar-system/Oscar.jl/pull/1500, and it conflicts with what is here.
That would be sensible if all orderings involved are global. In Singular, non-global ordering are used to mimick working over certain localizations of the polynomial ring. The type of localization strongly depending on the ordering, so I would refrain from automatically switching orderings in the non-global case.
On Fri, 5 Aug 2022 at 15:05, dan @.***> wrote:
With this ordering keyword, we are now forcing singular_assure to use the specified ordering. One question. Would it ever be advantageous to see if the input ideals already have a singular version stored with identical base rings, and use that ordering instead forcing it with the ordering keyword? I am thinking of the case when the user doesn't specify an ordering (saturation(I, J)). In this case, if both I and J already have a singular version in an ordering other than default_ordering(base_ring(I)), I am wondering it is silly to recompute things in this default ordering rather than to use the existing versions.
— Reply to this email directly, view it on GitHub https://github.com/oscar-system/Oscar.jl/pull/1489#issuecomment-1206495875, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIGGK3T4FPAGW5RXFBJDSLVXUNSNANCNFSM5474XSMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
@tthsqe12 Well, that's not easy to answer, I think there is no black and white. In some situation it might be a good idea to see what we have already cached, in others it won't. But often we will (also with heuristics) not know what is the best. If a user asks a question which we can answer using a GB w.r.t. any monomial ordering and if we have two GBs (w.r.t. two different monomial orderings, both not the default ordering) already attached to an ideal should we use one of these? Which one of these? Or is it faster to compute a GB w.r.t. the default ordering and then answer the question the user asked for with this basis? I think we need to build a system where we try our best to give the user the choice to specify a monomial ordering, but also the option to not care about such things at all. Then the system needs to make a decision depending on meta information about the computation, system, etc. and also the cached information we already have. This system has to evolve and to iterate. What we have at the moment, for me, is only a very first step to have functionality running such that people use Oscar. From their feedback and problems we will learn and improve.
There is even a problem or open question from the other side: If a user specifies a monomial ordering, sometimes we know that an indirect method is faster to reach the goal. E.g. a user wants to compute a GB w.r.t. LEX and we know from the ideal's meta data that its dimension is zero. Then we would like to apply FGLM, compute first a GB w.r.t. DRL and then convert this to a GB w.r.t. LEX. Should the user still have the option to really ask the system to compute directly a GB w.r.t. LEX? Maybe the user knows better than the system does.
But I think this is a more general discussion, out of scope of this PR, but related to #1487.
So, what is the status of this PR? Obviously it has a conflict now (which I am sure could be resolved).
But does this need further work or discussion? Then it'd be great to state this as a summary, and mark the PR as "draft" so I don't end up looking at it again.
Or else, if it is in principle ready, then perhaps @ederc can rebase it and one of the other stakeholders (who? @wdecker ? @afkafkafk13 ? @jankoboehm ?) could review/approve?
uses the wrong usage of singular_assure (the illegal 2 argument version) Needs to be sorted after "silent changing" #2109 has been merged
