Yeah, I also found some morphisms in the polynomial ring code, but like the
QQ - ZZ code, it seemed dated (and hence might not follow recommended
practices).
As for sage.algebras.*, I didn't really see anything other than Boolean
return values.
On Fri, Jun 6, 2014 at 9:21 AM, Vincent Delecroix
I don't think there's much documentation beyond what's in
_coerce_map_from_() in Parent.
If it returns re, then it uses _element_constructor_ to construct the
morphism. Otherwise you return a morphism. I think there's some examples in
src/algebras which returns morphisms (I'm pretty sure I've
2014-06-06 17:12 UTC+02:00, Travis Scrimshaw tsc...@ucdavis.edu:
I don't think there's much documentation beyond what's in
_coerce_map_from_() in Parent.
If it returns re, then it uses _element_constructor_ to construct the
morphism. Otherwise you return a morphism. I think there's some
Ok, follow up question. Is there much documentation on morphisms, or am I
just blind and missing it?
At least as far as I can tell, the documentation on the coercion seems to
recommend implementing morphisms for _coerce_map_from_, but in the toy
examples, only boolean return values are used
On Thu, May 29, 2014 at 11:30:36PM +0200, Nicolas M. Thiery wrote:
Funny, I had exactly the same discussion yesterday. I am apparently
not lazy enough, and getting bitten by it: I should have written
something about this in the documentation a long time ago. I started
doing this today, and
Thanks for these clear explanations.
The case of IPython tab mechanism for getting documentation is very
convincing!
Coming from the C++ world, I was used to have the attributes private, but
was not sure about the Python way of dealing with this (having read
different opinions about it). I did
Hi William,
On 2014-05-28, William Stein wst...@gmail.com wrote:
With properties, guess what happens? Suppose f.something is a
property that's an immutable number, e.g., the determinant of a
matrix.
sage: a = matrix(...)
sage: a.det?
docstring about integer!
That's not true, if det
On Thursday, May 29, 2014 12:03:54 AM UTC+1, William wrote:
Another issue is that frequently in math we have algorithms/options to
functions, e.g.,
sage: a.det(algorithm=padic)
And even if there is no argument I would prefer a.det() over a.det to make
it clear that this is invoking a
On Thu, May 29, 2014 at 1:58 AM, Eric Gourgoulhon
egourgoul...@gmail.com wrote:
Thanks for these clear explanations.
The case of IPython tab mechanism for getting documentation is very
convincing!
Coming from the C++ world, I was used to have the attributes private, but
was not sure about
On Thu, May 29, 2014 at 2:41 AM, Simon King simon.k...@uni-jena.de wrote:
Hi William,
On 2014-05-28, William Stein wst...@gmail.com wrote:
With properties, guess what happens? Suppose f.something is a
property that's an immutable number, e.g., the determinant of a
matrix.
sage: a =
Thanks for the advice.
I've just finished the changes, setting all attribute names to single
underscore (2280 substitutions, thank you sed !).
Best wishes,
Eric.
Le jeudi 29 mai 2014 19:07:04 UTC+2, William a écrit :
Please try to use a single underscore, e.g., self._tensor, instead of
On Wed, May 28, 2014 at 04:03:11PM -0700, William Stein wrote:
When properties were added to Python, and Sage got them, I was not
convinced and didn't want to switch all the code to them. Why?
...
Thanks William for this synthetic answer on that matter. We should
definitely add this to the
On Wed, May 28, 2014 at 09:57:43AM +, Simon King wrote:
Personally, I would not hesitate to use these existing base classes
(sage.rings.ring.Ring for example) for things that are guaranteed to be
rings. Of course, if the actual algebraic structure depends on
parameters, then one must use a
Hi Andrew,
On 2014-05-28, R. Andrew Ohana andrew.oh...@gmail.com wrote:
For instance, what is the recommended class I should inherit from for my
parent class? I see at the top of sage.rings.rings, that it is not
recommended that I inherit from the Ring class anymore (maybe?),
REALLY? Why is
Some comments:
Non-underscore attributes implement a mutable interface. You are inviting
your users to modify field.tensor_type = (1,2), which will almost certanly
lead to inconsistent objects. In Sage, the convention is generally to use
underscore attributes and ensure immutability through
Thank you for these comments. I'll modify the code accordingly!
Eric.
Le mercredi 28 mai 2014 16:23:20 UTC+2, Volker Braun a écrit :
Some comments:
Non-underscore attributes implement a mutable interface. You are inviting
your users to modify field.tensor_type = (1,2), which will almost
At some point, someone(s) should sit down and make all of the old parents
into the new Parent class. This might have to be done all at once (at least
the one time I tried to change homset IIRC) and will likely take a full day
plus.
Best,
Travis
--
You received this message because you are
On Wednesday, May 28, 2014 7:23:20 AM UTC-7, Volker Braun wrote:
Non-underscore attributes implement a mutable interface.
I wasn't aware of that convention. Is it documented somewhere, with
rationale?
I've indeed seen constant instance attributes accessed via accessors and
was aware of the
Some comments:
By not hiding attributes (not using underscores like self._manifold) you
implement a mutable interface, essentially inviting users to change them.
This of course will generally not work (e.g. reach into ZeroScalarField and
making it non-zero). It also prevents you from ever
On Wednesday, May 28, 2014 5:35:18 PM UTC+1, Nils Bruin wrote:
Non-underscore attributes implement a mutable interface.
I wasn't aware of that convention. Is it documented somewhere, with
rationale?
Python provides @property and @foo.setter to make this convention work
safely, so clearly
On Wed, May 28, 2014 at 12:59 PM, Volker Braun vbraun.n...@gmail.com wrote:
On Wednesday, May 28, 2014 5:35:18 PM UTC+1, Nils Bruin wrote:
Non-underscore attributes implement a mutable interface.
I wasn't aware of that convention. Is it documented somewhere, with
rationale?
Python
21 matches
Mail list logo
