Project

General

Profile

Design #827

NewPositiveMat also for matrices over QQ? Also NewIntegerOrdMat. (now called MakeTermOrd)

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

Status:
Closed
Priority:
Immediate
Assignee:
-
Category:
Tidying
Start date:
26 Nov 2015
Due date:
% Done:

100%

Estimated time:
0.99 h
Spent time:

Description

In test-MatrixForOrdering1.C the function NewPositiveMat is called with a matrix containing rational (non-integer) entries.

NewIntegerOrdMat is not documented. Do we really need/want it?

2016-03 Calling now the new function MakeTermOrd.
The function NewIntegerOrdMat has been removed.


Related issues

Related to CoCoALib - Bug #834: Fix test failures (after revising MatrixForOrdering)Closed2015-12-09

Related to CoCoALib - Bug #814: PPOrdering: matrix ordering, what rings are allowed.Closed2015-11-23

Related to CoCoALib - Design #854: Function MakeTermOrd should be renamed MakeTermOrdMat?Closed2016-03-24

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

History

#1 Updated by John Abbott over 8 years ago

Perhaps the first question should be: do people who build order matrices really start from matrices with rational (non-integer) entries?

Certainly NewPositiveMat can be defined for matrices of rationals; the current impl adds integer multiples of earlier rows to later ones to obtain a non-negative matrix, but we could even use rational multiples. Perhaps the fn name should be NewPositiveOrdMat or NewNonNegOrdMat?

The documentation is vague, about exactly how the non-neg matrix is obtained, and this might actually be good for us: we could change the strategy in future without having to change the documentation. :-)

#2 Updated by John Abbott over 8 years ago

Also converting a (non-neg?) matrix of rationals into a matrix of integers defining an equivalent ordering allows for some inventiveness. Consider this example:

M := mat(QQ, [[1/3,2/3],[4/5,3/5]]);

We could naively multiply the rows by 3 and 5 respectively to get simply [[1,2],[4,3]]; or we could reduce this result to [[1,2],[1,0]].

Do we want to give ourselves the freedom to apply some form of "non-negative integer" row reduction to the result? This is really a question of semantics: we don't have to implement the reduction, but leave ourselves the opportunity to do so in the future.

Devising an algorithm to do this appeals to me, but I'm not sure whether it would ever actually be useful...

#3 Updated by John Abbott over 8 years ago

If there truly is a need to convert a matrix of rationals into a matrix of integers defining the same term ordering, might it not be better to offer a single function which does just that. Internally the fn could make the matrix non-negative, eliminate denoms, and then simplify it.

We could also make the separate steps visible to the public; perhaps some researchers in the area would like to perform the steps separately (maybe so they can offer us better code?)

The KISS philosophy would suggest offering publicly just a single fn to begin with; then later we can make our private fns accessible if there is demand. Remember that once a fn has been made public it is more problematic to change its semantics (or even remove it).

#4 Updated by Anna Maria Bigatti about 8 years ago

  • Related to Bug #814: PPOrdering: matrix ordering, what rings are allowed. added

#5 Updated by Anna Maria Bigatti about 8 years ago

  • Subject changed from NewPositiveMat also for matrices over QQ? Also NewIntegerOrdMat. to NewPositiveMat also for matrices over QQ? Also NewIntegerOrdMat. (now called MakeTermOrd)
  • Description updated (diff)
  • Status changed from New to Feedback
  • % Done changed from 0 to 90

#6 Updated by Anna Maria Bigatti about 8 years ago

  • Related to Design #854: Function MakeTermOrd should be renamed MakeTermOrdMat? added

#7 Updated by Anna Maria Bigatti about 8 years ago

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

#8 Updated by John Abbott almost 8 years ago

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

What is the status of this issue?
I'm hoping it can be closed quickly and easily for the next (imminent) release.

#9 Updated by John Abbott over 7 years ago

  • Priority changed from Normal to Immediate

#10 Updated by John Abbott about 7 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100
  • Estimated time set to 0.99 h

It seems we have taken the approach of making a single function (MakeTermOrd) which is simplest for the user; later oter functions could be made publicly available.

In feedback for 4 months without problems, so closing.

Also available in: Atom PDF