#13215: Skew polynomials
-------------------------------------+-------------------------------------
Reporter: caruso | Owner: tbd
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-7.3
Component: algebra | Resolution:
Keywords: skew polynomials | Merged in:
Authors: Xavier Caruso, | Reviewers: Burcin Erocal, David
Arpit Merchant, Johan Rosenkilde | Lucas, Travis Scrimshaw
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/arpitdm/skew_polynomials | 6fb186ab4b9eedb41596053854996263e85c5fe7
Dependencies: #13214, #13303, | Stopgaps:
#13640, #13641, #13642 |
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:96 arpitdm]:
> Replying to [comment:92 tscrim]:
> > - I would move most-to-all of the module-level doc to the user entry
point and then have a `.. SEEALSO:: block referencing said doc`, so it is
visible from the `?` on the command line. This also applies to the parent
class(es?) (i.e. module-level to class-level).
> Could you please explain with an example maybe, what this means? Or
maybe refer me to some method in some file from where I can read and
understand.
I would make a change like this:
{{{#!diff
"""
Top/Module-level
-Description
"""
class Foo:
"""
Class-level.
+
+ Description
"""
}}}
That way when you do `Foo?`, you get `Description`. You also want some
cross-linking so that someone using the online doc has links to follow to
get to `Description`.
> > - You should make `list` into a `cpdef` with an output type of `list`
and remove `_list_c`.
> class `SkewPolynomial_general` inherits from class `SkewPolynomial`. The
`_list_c` method is implemented in the former while in the latter it is
not. Are you suggesting that I remove _list_c from both classes and only
have a `cpdef list list(self)` in the latter class?
> > - For `__iter__`, just iterate over `self.__coeffs`. Actually, a
similar statement applies to many other places you call `_list_c` where
you don't expose it to the user or modify the list (e.g., `__getitem__`
and `_richcmp_`. The multivariate and sparse versions should be overriding
these methods anyways.
> There is no `__coeffs` attribute in class `SkewPolynomial` and it is
actually defined in class `SkewPolynomial_general`. Is it Python
convention to access from one class, an attribute with double leading
underscores of another class? If so, what is the correct way of doing
that?
Don't make it double underscore (you can also do the explicit name-
mangling). In general, I avoid double underscores so you can use the
hidden attributes in subclasses (unless you really wanted it to be
completely hidden from all subclasses, which is very rare).
> > - Actually, a number of functions that use `_list_c` should be moved
to the concrete class (and maybe an `@abstract_method` placeholder done in
the ABC.
> Could you please elaborate a little what you mean by this? I'm not sure
I follow.
ABC = Abstract Base Class, so the methods you have that just raise a
`NotImplementedError` (e.g., `_inplace_add`), you should have them be
blank (modulo a docstring and a doctest of a concrete implementation) with
a `@abstract_method`. These then get picked up by a failure of the
`TestSuite`.
--
Ticket URL: <https://trac.sagemath.org/ticket/13215#comment:98>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
