Project

General

Profile

Bug #631

Ambiguous: rank for matrix (in ex-matrix1.C)

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

Status:
Closed
Priority:
Normal
Assignee:
Category:
Portability
Start date:
26 Sep 2014
Due date:
% Done:

100%

Estimated time:
3.40 h
Spent time:

Description

Apple LLVM version 6.0 (Laura's new computer) reports that rank is ambiguous in ex-matrix1.C


Related issues

Related to CoCoALib - Design #619: Modulus (for CRTMill) ambiguousClosed2014-09-09

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

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

I think the problem arises because rank(M) entails a user type conversion from matrix to ConstMatrixView.

std::rank is apparently new in C++11.

I see two ways around this: change name of the rank function (e.g. simply rk), or change defn of rank so that if called with a matrix it does not need the user type conversion (e.g. add overload rank(const matrix& M))

#2 Updated by Anna Maria Bigatti over 9 years ago

John Abbott wrote:

I think the problem arises because rank(M) entails a user type conversion from matrix to ConstMatrixView.

std::rank is apparently new in C++11.

I see two ways around this: change name of the rank function (e.g. simply rk), or change defn of rank so that if called with a matrix it does not need the user type conversion (e.g. add overload rank(const matrix& M))

rk is actually a pretty standard notation, like deg or det.
I guess we used the full word rank because it's short enough ;-)

(On the other hand, maybe the overloading is safer?)

#3 Updated by John Abbott over 9 years ago

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

After speaking to Anna by phone, I have changed the name of rank into rk.

I'm ready to do CVS check in, but first I want to know what Anna thinks about the names myRank and RankByGauss. I have not shortened them because I think the full version is more comprehensible; but if we keep the longer names then we are not consistent in our use of the abbreviated form rk.

What do you think about myRk and RkByGauss?

#4 Updated by John Abbott over 9 years ago

Strictly speaking the proper solution to the problem is to put a using CoCoA::rank; inside the function which will call rank. As far as I can tell this is a "future-proof" solution in that it should work correctly regardless of changes that may be made to namespace std in the future.

I tried simply doing using namespace CoCoA; instead of using CoCoA::rank; but that did not remove the ambiguity (according to my compiler).

I have definite doubts about how sane/maintainable/comprehensible it would be to put using commands for all CoCoALib fns which appear in a function.

#5 Updated by John Abbott over 9 years ago

I now believe the ambiguity would disappear if the entire function were placed inside namespace CoCoA. We could modify all examples so that they are inside namespace CoCoA...

#6 Updated by Anna Maria Bigatti over 9 years ago

John Abbott wrote:

I now believe the ambiguity would disappear if the entire function were placed inside namespace CoCoA. We could modify all examples so that they are inside namespace CoCoA...

Interesting to know, I'll make my own tests also on Linux and MinGW.
For this particular case I think the best solution would be renaming it as rk.

#7 Updated by Anna Maria Bigatti over 9 years ago

John Abbott wrote:

After speaking to Anna by phone, I have changed the name of rank into rk.

I'm ready to do CVS check in, but first I want to know what Anna thinks about the names myRank and RankByGauss. I have not shortened them because I think the full version is more comprehensible; but if we keep the longer names then we are not consistent in our use of the abbreviated form rk.

What do you think about myRk and RkByGauss?

hmmm.... undecided.....
yes, I would go for myRk and RkByGauss.

#8 Updated by John Abbott over 9 years ago

In comment 5 I suggesting putting all code in namespace CoCoA; perhaps we should try doing this for some CoCoALib tests first (so we can see if it works as expected, and how it looks). Assuming the trial goes well, I think it would probably be a good idea to do it for all tests. Afterwards we can decide whether it is a good idea also for the examples.

UPDATE this suggestion has become issue #642

#9 Updated by John Abbott over 9 years ago

  • Subject changed from Ambiguous: rank for matrix (in ex-matrix1.C to Ambiguous: rank for matrix (in ex-matrix1.C)

#10 Updated by Anna Maria Bigatti almost 9 years ago

Renaming is done now. Isn't it?

#11 Updated by John Abbott almost 9 years ago

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

I think everything has now been done.

#12 Updated by John Abbott almost 9 years ago

I noticed that some of Christof's code uses rank; I have written to him asking whether it would be resaonable to change his fn rank into rk. The C5 interface also uses a RECORD with a field called Rank. Waiting for a reply from Christof.

#13 Updated by John Abbott almost 9 years ago

JAA notes that now we're planning to move all test/example code into namespace CoCoA the problem of ambiguity (in names such as rank) goes away -- the positioning inside the namespace resolves the issue.

Anna replies that it is not so convenient for a user to have to place their code inside the CoCoA namespace - indeed this could be a problem with code which uses several libraries.

Anna also suggest offering both rk and rank. JAA is uncertain about "having two names for the same function".

Comments? Opinions? Suggestions?

#14 Updated by John Abbott over 8 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 90 to 100
  • Estimated time set to 3.40 h

We use the name rk for the main function, but allow Rank as a component of a compound name (to increase readability).

Also available in: Atom PDF