Project

General

Profile

Feature #735

Convert a PPMonoidElem to RingElem with coefficient one

Added by Mario Albert almost 9 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Anna Maria Bigatti
Category:
New Function
Target version:
CoCoALib-0.99540 Feb 2016
Start date:
11 Jun 2015
Due date:
% Done:

100%

Estimated time:
2.00 h
Spent time:
1.90 h

Description

Let pp be a PPMonoidElem of the PPMonoid PPM. Let P be a SparsePolyRing with PPM as PPMonoid.
Several times I want to handle pp as a member of P.
At the moment I have to call for this case

  RingElem r = monomial(P, One(CoeffRing(P)), pp); // r = 1*pp

It would be quite nice if there would be a method monomial(SparsePolyRing, PPMonidElem) which can do the same:

  RingElem r = monomial(P, pp); // r = 1*pp

History

#1 Updated by Anna Maria Bigatti almost 9 years ago

  • Category set to New Function
  • Status changed from New to In Progress
  • Target version set to CoCoALib-0.99540 Feb 2016
  • Estimated time set to 2.00 h

That seems very reasonable: I had a look at the code and, indeed, most of the times monomial is called the coefficient is 1. I can see no ambiguity, so we can do it.
Meanwhile you may use the more convenient call monomial(P,1,pp) ;-)

#2 Updated by Anna Maria Bigatti almost 9 years ago

Should we do the same for monomial(P, expv)?
I cannot see any ambiguity.

REPLY (JAA) if we have monomial(P,PP) then we should also have monomial(P,expv)

#3 Updated by John Abbott almost 9 years ago

  • % Done changed from 0 to 10

I am a little uncertain about the proposal. monomial(P,pp) gains little over monomial(P,1,pp).

Is it worth creating a "new" function for relatively little benefit?

Do you think that monomial(P,pp) is usefully clearer to read than monomial(P,1,pp)?
I think it is marginally clearer, but am uncertain whether it really merits a "new" function.

Perhaps the documentation should make it clearer that monomial(P,1,pp) works as expected, and that it is not necessary to write monomial(P,one(CoeffRing(P)),pp).

I do not believe that monomial(P,1,pp) is measurably slower than monomial(P,one(...),pp); and even if it were slower, we could treat the case of coeff=1 specially to make it faster.

I'm not opposing the proposal; I just want to be convinced that it is worthwhile. Perhaps better documentation is the right approach...?

#4 Updated by Mario Albert almost 9 years ago

I didn't know that monomial(P, 1, pp) works as expected.

But I think for the normal user who wants to use a PPMonoidElem as a RingElem it would be more natural if he can use monomial(P, pp) as well.

#5 Updated by John Abbott almost 9 years ago

  • % Done changed from 10 to 20

I do agree that, without familiarity with the function, upon reading monomial(P,1,pp) my first thought would be "What does 1 mean here?" In contrast, monomial(P,pp) does seem clearer.

I note that monomial(P,pp) could also be written RingElem(P,pp), but the former seems to express better what the programmer wants (the latter is perhaps too vague).

Is there any other name we should consider? Probably it should have the same name as the 3 arg version...

#6 Updated by John Abbott almost 9 years ago

I point out that assignment to RingElem can perform some type changes. Should we allow assignment to a RingElem from PPMonoidElem? This would succeed only if the RingElem belongs to a poly ring P and the PPMonoidElem belongs to PPM(P).

I'm less convinced about this idea (implicit conversion) than Mario's original proposal (explicit conversion).

#7 Updated by Anna Maria Bigatti almost 9 years ago

My preference (by far) goes to monomial(P, pp)
I have already implemented and all tests pass.
Should I also do monomial(PP, expv)? I think so.

#8 Updated by John Abbott almost 9 years ago

  • Assignee set to Anna Maria Bigatti

OK, do it! Including monomial(P,expv).
Don't forget documentation, examples and tests!

#9 Updated by Anna Maria Bigatti almost 9 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 20 to 70

done, checked in.
So far I modified only the files in AlgebraicCore

#10 Updated by John Abbott over 8 years ago

Hi Anna. Could you finish this issue, and take it to "feedback"? Thanks, J

#11 Updated by Anna Maria Bigatti about 8 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 70 to 100

updated calls in BuiltinFunctions-CoCoALib and CoCoALibSupplement.
NOTE: this is only done for SparsePolyRing because monomial(R, i) would be ambiguous for DensePolyRing.
Closed.

Also available in: Atom PDF