Slug #1047
NewPolyRing with user defined ordering is slower than CoCoALib
Related issues
History
#1
Updated by Anna Maria Bigatti about 7 years ago
Updated by - Category set to enhancing/improving
- Status changed from New to Feedback
- Assignee set to Anna Maria Bigatti
- Priority changed from Normal to High
- Target version set to CoCoA-5.2.0 spring 2017
- % Done changed from 0 to 90
- Estimated time set to 4.01 h
Of course I wrote this issue after solving it ;-)
While comparing two functions using GBases with an elimination ordering we (Robbiano and myself) realized that the CoCoA-5 function was curiously a lot slower than the similar CoCoALib one.
After a long investigation (and resurrecting the old code for GRStats) I understood that the problem had to be in the underlying polynomial arithmetic.
Indeed NewPolyRing in BuiltinFunctions-CoCoALib.C was calling NewPolyRing(R->theRing, NewPPMonoid(syms, PPO)), which forces a PPMonoid, then preventing the use of $DMPII$ (I think this was implemented before we wrote the new function below).
The correct call is NewPolyRing(R->theRing, syms, PPO).
#2
Updated by Anna Maria Bigatti about 7 years ago
- Related to Slug #1049: GroebnerFan: slow examples added
#3
Updated by Anna Maria Bigatti almost 7 years ago
- Estimated time changed from 4.01 h to 5.01 h
Still missing: make speed tests with GroebnerFan (I had some strange results)
#4
Updated by Anna Maria Bigatti almost 7 years ago
- Status changed from Feedback to Closed
- % Done changed from 90 to 100
- Estimated time changed from 5.01 h to 5.31 h
Anna Maria Bigatti wrote:
Still missing: make speed tests with GroebnerFan (I had some strange results)
The timing for GroebnerFan is identical because GBasis make its own ring (DMPI/DMPII) for the computation.
Our experiments, instead, had some computations in the cocoa5 ring (implemented as DMP).
#5
Updated by Anna Maria Bigatti almost 7 years ago
- Related to Slug #1057: Slug: Polynomial ring contructor slow with (big) matrix ordering added