#5566: [with patch, needs some work] Symmetric Groebner bases and Infinitely
Generated Polynomial Rings
---------------------------------+------------------------------------------
Reporter: SimonKing | Owner: SimonKing
Type: enhancement | Status: new
Priority: major | Milestone: sage-3.4.2
Component: commutative algebra | Keywords: Symmetric Ideal
---------------------------------+------------------------------------------
Comment(by malb):
Replying to [comment:26 SimonKing]:
> Replying to [comment:23 malb]:
> > * please don't use {{{__repr__}}} and friends in doctests but use
examples that are natural Python and mark them {{{#indirect doctest}}}
>
> Could you elaborate? I don't understand what that means.
You have lines like {{{foo.__repr__()}}} in your {{{EXAMPLES}}}. It should
be {{{str(foo)}}} instead, i.e. double underscore functions shouldn't be
called directly (but indirectly by Python).
> > * why do you ask coercion questions in {{{_add_}}} and friends, at
this point coercion should be done. What am I missing?
>
> You mean {{{hasattr(self.parent(),'_P')}}}? This is since I have a dense
and a sparse implementation of infinite polynomial rings, but I only have
a ''single'' class of infinite polynomials, in order to avoid code
duplication. So, I have to check whether the parent of an infinite
polynomial is dense or sparse.
>
> But now, as you mention it: The dense ring class inherits from the
sparse ring class; perhaps there should also be dense and a sparse element
class, with separate {{{_add_}}}?
It probably would be cleaner and faster.
> > * you should add an {{{AUTHORS}}} block and add your name to each
file
>
> So, the copyright information is not enough?
It is "enough" for legal purposes but someone reading the docs won't see
your name which would be a shame.
> Conncerning copyright: Although most of the code is original, I would
like to include mhanson in the copyright, because his code was the
starting point for me, and his 'dense' approach towards infinite
polynomial rings is now the standard implementation (since it is faster).
Is it ok to name him, although he did not explicitly state that he agrees
with being named?
That is probably alright.
> > * at the risk of being obnoxious: the Python convention is to use
{{{add_generator}}} over {{{AddGenerator}}}
>
> Ok, will change it. Note, however, that {{{addGenerator}}} without
underscore is the name of the corresponding method in polybory's
{{{GroebnerStrategy}}}.
Note that they changed that in PolyBoRi 0.6 to be consistent with Python's
convention.
> At this occasion: Would you prefer the method name
'symmetric_cancellation_order' over 'sco'?
If {{{sco}}} is not the word used in papers, I'd prefer
{{{symmetric_cancelation_order}}}. I have no hard feelings either way
though.
> > * Did you generate and check the docs?
>
> I checked the doc tests, but I don't know how to generate the docs.
run {{{sage -docbuild reference html}}} and check for warnings + inspect
the result.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5566#comment:29>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
