Module index component in internal compressed representation
The internal representation of module in GBasis computations is through an embedding into a polynomial ring.
i is encoded as exponent "10000 - i" (I'm skipping all the details).
This causes problms when using CoCoALib with 8-bit exponents (
(Found by John Abbott while tackling a huge computation with small exponents)
#1 Updated by Anna Maria Bigatti almost 3 years ago
I think 10000 can be replaced by
max_exp (how is it called in cocoalib?)
I don't think it is ever used in operations with other exponents, but in that case using
max_exp instead of 10000 should break immediately ;-) Could you test it with all debugging on?
It is still ugly to use a hard-coded constant, but indeed
max_exp would cover all cases which can be represented in that way.
#3 Updated by John Abbott almost 3 years ago
- Status changed from New to In Progress
- Target version set to CoCoALib-0.99999
- % Done changed from 0 to 10
Is there a
MaxExp function? At least one
PPMonoid has no upper limit on exponents; what value should be used in that case? Perhaps 0? If so, the max number of components could then be arbitrarily set to 2^32-1 (or even just 1000000); it's hard to imagine how
anyone could compute with a larger module.
#4 Updated by Anna Maria Bigatti almost 3 years ago
- Assignee set to Anna Maria Bigatti
- % Done changed from 10 to 30
- Estimated time set to 10.00 h
Bug probably found.... my fault
John has implemented in GBEnv.C
/*static*/ const long GRingInfo::myMaxComponentIndex = numeric_limits<SmallExponent_t>::max()/2; // max num of compts -- depends on type SmallExponent_t
and this failed, showing that my guess for
But this allowed making many tests very quickly (just compiling 1 .C file), so I found that the strange limit was 32748 instead (??!?!?). After one day of tests, and noticing how coherently it was going even when failing I decided to grep for 327... and I found
OrdvArith::MatrixOrderingMod32749Impl::MatrixOrderingMod32749Impl(long NumIndets, long GradingDim, const matrix& OrderMatrix):
where 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.
This seems to be the choice (instead of
OrdvArith::reference NewOrdvArith(const PPOrdering& PPO)
It is worth investigating whether it is worth it, safe, and write proper documentation... I'll do it (opening a new redmine issue)
#7 Updated by John Abbott over 2 years ago
I shall check in shortly; anyway here is the modified line:
/*static*/ const long GRingInfo::myMaxComponentIndex = min(32748ul, min(static_cast<unsigned long>(numeric_limits<long>::max()-1), static_cast<unsigned long>(numeric_limits<SmallExponent_t>::max()-1))); // max num of compts -- depends on type SmallExponent_t
NOTE checked in now :-)
#11 Updated by John Abbott 2 months ago
- Status changed from Resolved to Closed
- % Done changed from 80 to 100
The code has been unchanged for over a year, and no problems have yet arisen (because no one has tried computing with a module having more than 32000 components?).
Someone ought to check whether there are safeguards against creating modules with too many components... sigh.
Next time, maybe?
I'm fed up with this issue. Closing.