Project

General

Profile

Design #619

Modulus (for CRTMill) ambiguous

Added by John Abbott over 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
John Abbott
Category:
Renaming
Target version:
CoCoALib-0.99536 June 2015
Start date:
09 Sep 2014
Due date:
% Done:

100%

Estimated time:
Spent time:
2.70 h

Description

The type CRTMill has an associated function modulus(const CRTMill&); however calling the function the obvious way (e.g. modulus(crt)) creates an ambiguity according to the compiler.

This is very irritating. It can be avoided by calling explicitly CoCoA::modulus(crt), but this is not very readable.

Find a better solution.

Related issues

Related to CoCoALib - Design #620: Redesign CRTMillIn Progress2014-09-11

Related to CoCoALib - Bug #631: Ambiguous: rank for matrix (in ex-matrix1.C)Closed2014-09-26

Related to CoCoALib - Feature #639: Shadow CoCoA namespace to help guarantee portability (without ambiguity)New2014-10-28

Related to CoCoALib - Design #642: Move code in test file into namespace CoCoAClosed2014-10-29

History

#1 Updated by John Abbott over 9 years ago

I do not understand why the compiler thinks that modulus(crt) is ambiguous.

There is an STL template fn modulus, but I thought template fns were "lower priority" than "exact match" calls. Perhaps its a problem with my old compiler?

I suppose we'll be forced to rename modulus. Any suggestions for a new name?

20141014 correction: in the STL there is a templated class called modulus, so modulus(blah) could also be a ctor call.

#2 Updated by John Abbott over 9 years ago

An obvious "solution" is to put using CoCoA::modulus somewhere inside the function which calls it. Just about acceptable, but still a nuisance.

#3 Updated by John Abbott over 9 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

I think the C++ rules will compel us to change name -- asking the user to write CoCoA::modulus every time is not acceptable. I could not find any useful hints on the internet.

What new name could we use? CombinedModulus (rather long), CurrModulus or CurrentModulus (or CurrMod?)

I prefer not to use a member fn as this is "incompatible" with our philosophy of using them only for modifying operations.

#4 Updated by Anna Maria Bigatti over 9 years ago

John Abbott wrote:

I think the C++ rules will compel us to change name -- asking the user to write CoCoA::modulus every time is not acceptable. I could not find any useful hints on the internet.

What new name could we use? CombinedModulus (rather long), CurrModulus or CurrentModulus (or CurrMod?)

CombinedModulus is long but very clear (better than modulus).
CRTModulus?

#5 Updated by John Abbott over 9 years ago

Assuming my explanation in the correction in comment 1 is correct, then the STL people could break our code at any time by introducing a new template class whose name coincides with the name of any function we have defined :-(

#6 Updated by John Abbott over 9 years ago

(see #631 comment 5) I think the problem goes away if the code is put inside namespace CoCoA.

#7 Updated by John Abbott over 9 years ago

  • Assignee set to John Abbott
  • % Done changed from 10 to 20

As Anna pointed out the names CombinedModulus and CombinedResidue are very clear (though long). Since it seems unlikely that these functions will be used in complicated formulas/expressions, their length is probably not a hindrance.

I'll implement the changes.

#8 Updated by John Abbott over 9 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 20 to 90

Implemented; all tests pass. Updated doc.

Oddly, no tests called these fns; nor any examples -- rectify?

Checked in.

#9 Updated by John Abbott almost 9 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100

Added example and test (actually they are the same).
Checked in. Closing!

Also available in: Atom PDF