
#include <degree.H>
Collaboration diagram for CoCoA::degree:
Public Member Functions  
degree (std::size_t dim)  
const ZZ &  operator[] (std::size_t index) const 
deg[index] (READ ONLY)  
std::size_t  myGradingDim () const 
void  mySetComponent (std::size_t index, const ZZ &VALUE) 
deg[index] = VALUE  
void  mySetComponent (std::size_t index, long value) 
deg[index] = value  
degree &  operator+= (const degree &d) 
Computes deg1+=deg2.  
degree &  operator= (const degree &d) 
Computes deg1=deg2.  
Static Public Member Functions  
static void  CheckCompatible (const degree &d1, const degree &d2, const char *fn) 
checks dims are equal, throws if not.  
Private Attributes  
std::vector< ZZ >  myCoords 
Friends  
int  FastCmp (const degree &d1, const degree &d2) 
like cmp but inline and no checks  
bool  IsZero (const degree &d) 
Copyright (c) 2005 John Abbott Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2; with no Invariant Sections, no FrontCover Texts, and no BackCover Texts. A copy of the licence is included in the file COPYING in this directory. User documentation for the class degree ======================================= The class degree is used to represent the values returned by the "deg" function applied to power products and (multivariate) polynomials. Recall that in general a degree is a value in Z^k; the value of k and the way the degree is computed (equiv. weight matrix) are specified when creating the PPOrdering object used for making the PPMonoid of the polynomial ring  see the function NewPolyRing. If t1 and t2 are two power products then the degree of their product is just the sum of their individual degrees; and naturally, if t1 divides t2 then the degree of the quotient is the difference of their degrees. The degree values are totally ordered using a lexicographic ordering. Note that a degree may have negative components. The following functions are available for objects of type degree: degree d1(k); create a new degree object with value (0,0,...,0) [k zeroes] d1 = d2 assignment, d1 must be nonconst d1 + d2 sum d1  d2 difference (there might be no PP with such a degree) d1 += d2 equivalent to d1 = d1 + d2 d1 = d2 equivalent to d1 = d1  d2 cmp(d1, d2) (int) result is <0, =0, >0 according as d1 <,=,> d2 top(d1, d2) coordinatebycoordinate maximum (a sort of "lcm") cout << d1 print out the degree GradingDim(d) get the number of the components d1[s] get the sth component of the degree (as a ZZ) (for 0 <= s < k) IsZero(d1) true iff d1 is the zero degree d1.mySetComponent(k, n) sets the kth component of d1 to n [you probably shouldn't be using this function] The six comparison operators may be used for comparing degrees (using the lexicographic ordering). A [degree] object may be created by using one of the following functions: wdeg(f) where f is a RingElem belonging to a PolyRing (see PolyRing.txt) wdeg(t) where t is a PPMonoidElem (see PPMonoid.txt) Maintainer documentation for the class degree ============================================= So far the implementation is very simple. The primary design choice was to use C++ std::vector<>s for holding the values  indeed a [degree] object is just a "wrapped up" vector of values of type [degree::ElementType]. For a first implementation this conveniently hides issues of memory management etc. Since I do not expect huge numbers of [degree] objects to created and destroyed, there seems little benefit in trying to use [MemPool]s (except it might be simpler to detect memory leaks...) I have preferred to make most functions friends rather than members, mostly because I prefer the syntax of normal function calls. The [CheckCompatible] function is simple so I made it inline. Note the type of the third argument: it is deliberately not (a reference to) a [std::string] because I wanted to avoid calling a ctor for a [std::string] unless an error is definitely to be signalled. I made it a private static member function so that within it there is free access to [myCoords], the data member of a [degree] object; also the call ]degree::CheckCompatible] makes it clear that it is special to degrees. In implementations of functions on degrees I have preferred to place the lengths of the degree vectors in a const local variable: it seems cleaner than calling repeatedly [myCoords.size()], and might even be fractionally faster. [operator<<] handles the case of onedimensional degrees specially so that the value is not printed inside parentheses. Bugs, Shortcomings and other ideas ================================== How best to handle large and small degrees? Always using ZZs would avoid problems associated with limits BUT may lead to unacceptable runtime performance degradation. There is public writeaccess to the components of a degree object. Is this a bug? No special handling for the case of a grading over Z (i.e. k=1) other than for printing. Is this really a shortcoming? Printing via [operator<<] is perhaps rather crude? Is the special printing for k=1 really such a clever idea? GradingDim(const degree&) seems a bit redundant, but it is clearer than "dim" or "size" Why does mySetComponent only use CoCoA_ASSERT for the index range check? Make operator[] return a proxy?
Definition at line 45 of file degree.H.



deg[index] (READ ONLY)


Definition at line 81 of file degree.H. References myCoords. Referenced by CoCoA::FastCmp(), and CoCoA::GradingDim(). 

deg[index] = VALUE


deg[index] = value


Computes deg1+=deg2.


Computes deg1=deg2.


checks dims are equal, throws if not.


like cmp but inline and no checks




Definition at line 60 of file degree.H. Referenced by CoCoA::FastCmp(), and myGradingDim(). 