gap-online-help 4r6p5-3 / usr / share / gap / doc / ref / chap26.txt

This file is indexed.

/usr/share/gap/doc/ref/chap26.txt is in gap-online-help 4r6p5-3.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below. 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
  
  26 Vector and matrix objects
  
  This  chapter  is  work  in  progress.  It  will eventually describe the new
  interface to vector and matrix objects.
  
  Traditionally,  vectors  in GAP have been lists and matrices have been lists
  of  lists  (of  equal  length). Unfortunately, such lists cannot store their
  type  and  so  it  is  impossible to use the full advantages of GAP's method
  selection  on  them.  This  situation is unsustainable in the long run since
  more  special  representations  (compressed, sparse, etc.) have already been
  and  even  more  will be implemented. To eventually solve this problem, this
  chapter describes a new programming interface to vectors and matrices.
  
  
  26.1 Fundamental ideas and rules
  
  The whole idea of this interface is that (row-) vectors and matrices must be
  proper  objects  with  a  stored  type  (i.e.  created by Objectify allowing
  inheritance) to benefit from method selection. We therefore refer to the new
  style   vectors   and   matrices   as  vector  objects  and  matrix  objects
  respectively.
  
  It  should  be possible to write (efficient) code that is independent of the
  actual  representation  (in  the  sense of GAP's representation filters) and
  preserves it.
  
  This latter requirement makes it necessary to distinguish between (at least)
  two classes of matrices:
  
      RowList-Matrices  which  behave  basically  like  lists  of  rows,  in
        particular  are  the  rows  individual  GAP objects that can be shared
        between different matrix objects.
  
      Flat  matrices  which behave basically like one GAP object that cannot
        be  split  up  further. In particular a row is only a part of a matrix
        and no GAP object in itself.
  
  For  various reasons these two classes have to be distinguished already with
  respect to the definition of the operations for them.
  
  In   particular  vectors  and  matrices  know  their  BaseDomain  and  their
  dimensions.  Note  that  the basic condition is that the elements of vectors
  and  matrices  must  either  lie in the BaseDomain or naturally embed in the
  sense  that  +  and * and = automatically work with all elements of the base
  domain (example: integers in polynomials over integers).
  
  Vectors  are  equal with respect to "=" if they have the same length and the
  same  entries.  It  is  not  necessary  that  they have the same BaseDomain.
  Matrices  are equal with respect to "=" if they have the same dimensions and
  the  same  entries. It is possible that not for all pairs of representations
  methods exist.
  
  It is not guaranteed that all rows of a matrix have the same vector type! It
  is  for  example thinkable that a matrix stores some of its rows in a sparse
  representation  and  some in a dense one! However, it is guaranteed that the
  rows of matrices in the same representation are compatible in the sense that
  all  vector  operations defined in this interface can be applied to them and
  that  new  matrices in the same representation as the original matrix can be
  formed out of them.
  
  Note  that  there  is  neither  a  default  mapping  from  the set of matrix
  representations  to the set of vector representations nor one in the reverse
  direction!  There is nothing like an "associated" vector representation to a
  matrix representation or vice versa.
  
  The  way  to write code that preserves the representation basically works by
  using constructing operations that take template objects to decide about the
  actual representation of the new object.
  
  Vectors  do  not  have  to  be  lists  in the sense that they do not have to
  support  all  list operations. The same holds for matrices. However, RowList
  matrices  behave nearly like lists of row vectors that insist on being dense
  and containing only vectors of the same length and with the same BaseDomain.
  
  There  are  some  rules embedded in the comments to the following code. They
  are marked with the word "Rule". FIXME: Collect all rules here.
  
  
  26.2 Categories of vectors and matrices
  
  
  26.3 Constructing vector and matrix objects
  
  
  26.4 Operations for row vector objects
  
  
  26.5 Operations for row list matrix objects
  
  
  26.6 Operations for flat matrix objects

APT Browse - Built by Thomas Orozco.