Project

General

Profile

Feature #72

Feature #68: cleanup doc for matrix, MatrixViews, *Matrix*,....

MatByRows, MatByCols

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

Status:
Closed
Priority:
Low
Assignee:
John Abbott
Category:
New Function
Target version:
CoCoALib-0.99534 Seoul14
Start date:
21 Dec 2011
Due date:
% Done:

100%

Estimated time:
5.00 h
Spent time:
4.10 h

Description

CoCoA4 has MakeMatByRows and MakeMatByCols.

Should CoCoALib offer MatrixViews which in an analogous way?

If so, what should the pseudo-ctors be called? MatByRows, MatByCols.

Strictly it is redundant having both as transpose(MatByRows(vec)) is MatByCols(vec)

History

#1 Updated by John Abbott over 12 years ago

Even if we decide not to create MatByRows/MatByCols we should mention it in the documentation (e.g. under Shortcomings, etc)

#2 Updated by John Abbott about 11 years ago

  • Category set to New Function
  • Priority changed from Normal to High
  • Target version set to CoCoALib-0.9953

JAA notes that there is a ctor for DenseMat which behaves as MatByRows except that it makes a copy of the entries.

Advantages of MatByRows and MatByCols:
  • does not copy the elements (so should be fast)
  • the impl is easy/fast (in fact I have already done most of it)
Disadvantages:
  • uses a reference internally so there is a risk of a dangling reference with incautious use
  • might be confusing given that there is a NewDenseMat ctor which works similarly to MatByRows (but we could easily eliminate that ctor, replacing a call to it by a call of the form NewDenseMat(MatByRows(...)))

NB I have increased priority in the hope that we can settle this issue shortly.

#3 Updated by John Abbott almost 11 years ago

  • Status changed from New to In Progress
  • Assignee set to John Abbott
  • Priority changed from High to Low
  • Target version changed from CoCoALib-0.9953 to CoCoALib-0.99534 Seoul14
  • % Done changed from 0 to 20

JAA now thinks it is better to offer both MatByRows and MatByCols so that user code is more readable (& expresses more clearly the programmers intent). Of course, internally the implementation of MatByCols could simply be a transpose of a MatByRows...

Since this is not needed for the upcoming CoCoA summer school, I'm delaying "delivery" until 0.9954.

#4 Updated by Anna Maria Bigatti over 10 years ago

  • Target version changed from CoCoALib-0.99534 Seoul14 to CoCoALib-0.99532

#5 Updated by Anna Maria Bigatti about 10 years ago

  • Target version changed from CoCoALib-0.99532 to CoCoALib-0.99533 Easter14

#6 Updated by John Abbott about 10 years ago

  • Target version changed from CoCoALib-0.99533 Easter14 to CoCoALib-0.99534 Seoul14

#7 Updated by John Abbott almost 10 years ago

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

The code is already there (and has been for how long?) Fns are MatByRows and MatByCols.
I added some documentation. I might add an example (if there isn't already one).

Note: there is also a commented out signature with arg vector<vector<RingElem>>.

#8 Updated by Anna Maria Bigatti almost 10 years ago

should we rename the CoCoA-5 functions MakeMatByRows?
(and move the "Make.." into obsolescent?)

#9 Updated by John Abbott almost 10 years ago

Not yet entirely convinced about renaming MakeMatByRows. It is very similar to MatByRows but there is an important difference: the C5 fns do make copies. Perhaps it does not matter that much -- after all the MakeMatByXXX fns are essentially never called in the packages!

Christof is undecided. He wondered whether it'd be better to include the word View in the CoCoALib fns.

#10 Updated by John Abbott almost 10 years ago

The impl for MatByCols was missing; it is there now (quick cut-and-paste job).
Also added an example.

Not closing because of the question in the previous comment about the name (e.g. MatViewByRows as Christof suggested).

#11 Updated by John Abbott over 9 years ago

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

Christof has a valid point about the mnemonic value of including view in the name, but Anna points out that none of the other matrix view pseudo-ctors contains view in the name. Adding View would make all the names longer, an aspect we do not like. So we reject Christof's idea (for the moment); but we will reconsider if problems arise often enough that changing name would be a good idea.

Closing.

Also available in: Atom PDF