Project

General

Profile

Design #822

Should ElimMat return a ConstMatrix

Added by John Abbott over 8 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
High
Assignee:
Anna Maria Bigatti
Category:
Tidying
Target version:
CoCoALib-0.99550 spring 2017
Start date:
25 Nov 2015
Due date:
% Done:

100%

Estimated time:
5.01 h
Spent time:
5.10 h

Description

In my new implementation the fixed order matrices return ConstMatrix.
At the moment ElimMat returns a matrix; should it return a ConstMatrix instead?

What about ElimMat with a specified grading? And HomogElimMat?

Related issues

Related to CoCoALib - Bug #820: NewMatMinimize, NewMatCompleteOrd - a godforsaken mess!Closed2015-11-25

Related to CoCoALib - Feature #313: Elim(vector<long>) as PPOrderingCtorIn Progress2013-02-15

History

#1 Updated by John Abbott over 8 years ago

I really feel I have opened Pandora's box :-(

I'll keep plodding on... this is all very frustrating :-(

#2 Updated by John Abbott over 8 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10
What should the ElimMat function do in these two limit cases?
  • elim no indets
  • elim all indets

Note that the question is about the fn which creates an order matrix, and not about the fn which produces an elim ideal.

I propose that the behaviour be one of these two actions:
  • give error
  • return MatStdDegRevLex

The point of giving an error is that the user may find it helpful to know that the program wanted to construct an "edge case" order matrix. I presume the elim fn itself will handle "elim all" and "elim none" as special cases, so it should not try to construct the corresponding order matrix.

#3 Updated by John Abbott over 8 years ago

I note that test-RingWeyl1.C tries to create a an elim mat for no indets. Why? Is that really what it should do?

#4 Updated by John Abbott over 8 years ago

Anna suggested change the arg order for ElimMat and HomogElimMat so that the list of indets to elim is the first arg. Sounds sensible to me.

#5 Updated by John Abbott over 8 years ago

I suppose strictly the fns should be called ElimOrdMat and HomogElimOrdMat.
Is that a good idea or a not-so-good idea?

#6 Updated by John Abbott over 8 years ago

  • % Done changed from 10 to 50

The documentation for ElimMat and HomogElimMat is largely missing; and the names given in the doc are different from those in the code. FIX THIS!

#7 Updated by John Abbott over 8 years ago

Checked in the updated code.

Still need: decide fn names, write proper doc!

#8 Updated by Anna Maria Bigatti about 8 years ago

  • Target version changed from CoCoALib-0.99540 Feb 2016 to CoCoALib-0.99550 spring 2017

#9 Updated by Anna Maria Bigatti about 8 years ago

  • Related to Bug #820: NewMatMinimize, NewMatCompleteOrd - a godforsaken mess! added

#10 Updated by Anna Maria Bigatti over 7 years ago

  • Description updated (diff)

#11 Updated by Anna Maria Bigatti over 7 years ago

  • Assignee set to Anna Maria Bigatti

#12 Updated by Anna Maria Bigatti over 7 years ago

just simplified CoCoA-5 porting (no longer passing through CoCoALibSupplement)
I'd like to change HomogElimMat into ElimHomogMat

#13 Updated by Anna Maria Bigatti over 7 years ago

general improvement on coherence and readability of ElimMat and ElimHomogMat (was HomogElimMat)

#14 Updated by John Abbott over 7 years ago

Should ElimMat([1,2,3]) and ElimMat([3,2,1]) give the same result? Why or why not?

In other words, does the order in which the indets to eliminate are listed make a difference?

#15 Updated by Anna Maria Bigatti over 7 years ago

John Abbott wrote:

Should ElimMat([1,2,3], 4) and ElimMat([3,2,1], 4) give the same result? Why or why not?
In other words, does the order in which the indets to eliminate are listed make a difference?

I think that the only guarantee that we give is that it is an elimination ordering for the set.
No other guarantee on how this ordering is defined.
And if a user has the knowledge to expect a particular elimination ordering, than he's got the knowledge to make it himself as he needs (and we don't!)

#16 Updated by John Abbott over 7 years ago

  • Related to Feature #313: Elim(vector<long>) as PPOrderingCtor added

#17 Updated by John Abbott about 7 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 50 to 90

The current code works without any apparent problems, so we can just accept it as it is. It may not be the best design, but there are plenty of other more important matters to deal with (and anyway the current code works).

JAA suggests closing: apart from a name change, there has been no change to the code in over a year.

#18 Updated by Anna Maria Bigatti almost 7 years ago

  • Estimated time set to 5.01 h

#19 Updated by John Abbott almost 7 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100

Also available in: Atom PDF