Ralf Hemmecke wrote:
>
> Ooops. I forgot to send the link again.
>
> https://github.com/hemmecke/fricas/commits/poly
>
> There are commits listed from 18-Dec-2015 concerning generalization of
> Groebner(Internal)Package.
>
> That is in connection with making totalDegree an optional export and the
> problems with that.
>
> See
> https://www.mail-archive.com/[email protected]/msg08830.html
> as the related thread.
>
> Of course, I would prepare properly formatted patches if you think that
> it is worth to be included into FriCAS.
>
> In short (if I remember correctly) there are a couple of things
>
> 1)
> make totalDegree optional in FreeModuleCategory and remove
> the definition from GeneralDistributedMultivariatePolynomial.
> The "rewrite totalDegree" commit was necessary because I had
> problems with the compilation of the
>
> "max"/[reduce("+", s::V, 0) for s in support p]
>
> line.
IIUC you want to add 'totalDegree' as a conditional export
from FreeModuleCategory and remove GeneralDistributedMultivariatePolynomial
This looks hacky to me: I do not see good mathematical sense
of this for FreeModuleCategory.
Concerning problems with compilation: I would like to look
more carefully at what happens, but unfortunately, I had
(and still have) a lot of distractions so did not have
time to do this.
BTW: It makes sense to reorganize IndexedDirectProductCategory,
FreeModuleCategory, AbelianMonoidRing, FiniteAbelianMonoidRing.
One possiblity is to inherit FiniteAbelianMonoidRing also
from FreeModuleCategory (I am not sure if this is good idea,
but at least I do not see immediate obstacles). Next quick
observatiuons:
- 'monom' in FreeModuleCategory seem to be 'monomial' with
arguments reverses, so redundant
- 'leadingCoefficient' and 'leadingSupport' seem to duplicate
definitions in IndexedDirectProductCategory (possibly someone
wanted a new documentation string...).
- 'leadingMonomial' makes sense for IndexedDirectProductCategory
but is absent here
- it makes sense to have category of modules which represent
infinite sums but has most operations from free module
We could also add FiniteSupport attribute to
IndexedDirectProductCategory and try to unify some categries
by making some properties conditional on FiniteSupport.
BTW2: Fernando Mora at last ISSAC had a talk about generalizing
Groebner bases. IIUC non-computable parts can be generalized
to arbitrary rings. More intrestingly, he observed that
under some conditions "Groebner properties" can be passed to
a quotient. In particular any finitely generated commutative
ring can be treated as such a quotient and equippend with
computable theory of Groebner bases. It would be nice to
implement something like this in FriCAS. For this we
probably would need category of filtered rings and modules.
> 2)
> Remove VarSet from Groebner(Internal)Package and the commit
> "Groebner(Internal)Package without VarSet" modifies the other respective
> algebra files that depend on the Groebner package.
That looks OK.
> 3)
> gbasisExtend is not really necessary, but I had locally a problem where
> I knew that my input polynomials were already a Groebner basis wrt the
> given order and I wanted to extend this GB by more polynomials. It
> would, of course, be unnecessary to recomputed the initial list of
> S-polynomials of the known GB-polynomials, because it's just a waste of
> time to let them again reduce to zero. The change was simple enough and
> I did not (yet) make it publicly visible in GroebnerPackage, but only in
> GroebnerInternalPackage.
Looks OK.
>
> 4)
> Remov SetCategory from POLYLIFT.
As I wrote OK.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
