Project

General

Profile

Design #707

MatrixOrderingMod32749Impl: test and write documentation!

Added by Anna Maria Bigatti about 9 years ago. Updated about 2 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Anna Maria Bigatti
Category:
Safety
Target version:
CoCoALib-0.99880
Start date:
15 May 2015
Due date:
% Done:

50%

Estimated time:
8.00 h
Spent time:
0.90 h

Description

32749 is the biggest prime with some guarantee for <I-cant-remember-what>, so the order matrix is actually over ZZ/(32749) instead of over ZZ. I think this was for fast arithmetic with matrix-defined orderings.

But this a limit on the biggest exponent we can work with, because
this seems to be the choice (instead of MatrixOrderingImpl) in

  OrdvArith::reference NewOrdvArith(const PPOrdering& PPO)

It is worth investigating whether it is worth it, safe, and write proper documentation...

Related issues

Related to CoCoALib - Design #683: Module index component in internal compressed representationClosed2015-04-14

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

Related to CoCoALib - Bug #1199: GCD bug with high degree argClosed2018-06-28

History

#1 Updated by Anna Maria Bigatti about 9 years ago

  • Status changed from New to In Progress

Some notes:

In OrdvArith.H there is this comment:

class MatrixOrderingImpl: public base // !!!BUG!!! only partially implemented

that might be why we use the mod 32749 implementation ;-)

Both MatrixOrderingImpl and MatrixOrderingMod32479Impl have the matrix myOrderMatrix as a vector<vector<int> >.
The first also has myAdjointOrderMatrix and myOrderMatrixDet, the second myInverseOrderMatrix.
All as int.

#2 Updated by Anna Maria Bigatti about 8 years ago

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

#3 Updated by Anna Maria Bigatti about 8 years ago

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

#4 Updated by John Abbott almost 8 years ago

  • Target version changed from CoCoALib-0.99550 spring 2017 to CoCoALib-1.0

#5 Updated by John Abbott almost 6 years ago

  • Target version changed from CoCoALib-1.0 to CoCoALib-0.99600
  • % Done changed from 0 to 10

#6 Updated by John Abbott almost 6 years ago

  • Related to Bug #1199: GCD bug with high degree arg added

#7 Updated by Anna Maria Bigatti almost 6 years ago

As explained in Bug #1199:
I added and exponent overflow check in ApplySPRCodomain (and also in GeneralPPMonoidHomImpl::myApply).

#8 Updated by Anna Maria Bigatti almost 6 years ago

  • Target version changed from CoCoALib-0.99600 to CoCoALib-0.99650 November 2019

#9 Updated by John Abbott over 4 years ago

  • Target version changed from CoCoALib-0.99650 November 2019 to CoCoALib-0.99800

Can we use a bigger modulus now that we are effectively assuming 64-bit platform? (are we?)

#10 Updated by John Abbott over 2 years ago

  • Target version changed from CoCoALib-0.99800 to CoCoALib-0.99850

#11 Updated by Anna Maria Bigatti 4 months ago

  • Target version changed from CoCoALib-0.99850 to CoCoALib-0.99880

#12 Updated by John Abbott about 2 months ago

  • % Done changed from 10 to 50

What is the status of this issue?
Not so long ago I wrote a similar class for 64-bitters where the modulus is about 2^31 -- I wonder what happens if the platform is only 32-bit? See #1661

Also available in: Atom PDF