CoCoA » CoCoALib

My current feeling is that I should simply change the error mesg, and leave the rest as is: namely, multiplicities must be (strictly) positive.

This would be quick and easy to achieve. But first I would like to hear if there any contrasting opinions.

The current interface for FactorMultiplicity does not use a factorization.
Even if an alternative interface (like that to DivideOutMaxPower) is desired, using a factorization object is not especially helpful. And if we really want to use a factorization object, we can just skip factors with multiplicity zero.

In other words, I see no justification in allowing 0 as an exponent in the representation.

What might be reasonable is to allow factorization::myAppend to be called with 0 multiplicity (in which case it simply ignores the factor). What do you think?

If we allow 0 as a multiplicity when calling myAppend then it should also be allowed in the ctor call which accepts two vectors (factors & mults).
This means that the ctor must be slightly rewritten... not really a problem, just a little tedious.

NOTE is seems that the main change would be havng to move the code from ourConsistencyCheck into the ctor itself; it seems that ourConsistencyCheck is not called from elsewhere.

I now prefer not to allow 0 as a multiplicity because it could be confusing: e.g. someone might call myAppend(fac,0) and then be surprised that nothing was appended to the list of factors.

Also it was not wholly clear to me what myAppend(1,0) should do: the point is that the multiplicity is 0, so the call should be "ignored", but in this instance the factor is a forbidden one (factors may not be invertible or zero-divisors), so perhaps an error should be signalled???

In other words, I agree with comment 2.

I have implemented as decided (i.e. mults must be positive)... effectively we are rejecting the original proposal.

Should factorization throw an exception if the ringelems are in a field?
It is possible to create a factorization object over a field, but there can be only a RemainingFactor (since all values are zero-divs or invertible).

NOTE factorization does not allow automatic ring conversion -- I think it is probably better this way (when would one want to make a factorization with factors in different rings??)

• do not allow 0 multiplicity (will throw an exception)
• do not allow factorization objects over a field (will throw an exception)
• do not allow automatic ring conversion (with throw MixedRings)

Will test the new code shortly... 8-|