#9094: is_square and sqrt for polynomials and fraction fields
---------------------------------------------------------------------------------------+
Reporter: robertwb
| Owner: AlexGhitza
Type: enhancement
| Status: needs_work
Priority: major
| Milestone: sage-4.7
Component: algebra
| Keywords:
Author: Robert Bradshaw, Maarten Derickx
| Upstream: N/A
Reviewer: John Cremona, Marco Streng
| Merged:
Work_issues: make general sqrt compatible with lazy reals, or go back to
double code |
---------------------------------------------------------------------------------------+
Comment(by mstreng):
Replying to [comment:27 robertwb]:
> * is_square for fraction field elements now always computes a root,
even if it's not needed. This can be quite expensive.
Indeed, it should use {{{root=root}}} instead of {{{root=True}}}
>
> * Why are you writing boilerplate wrappers for all of LazyNamedUnop?
Just do is_square and sqrt if need be.
Hi Robert,
I can answer this question. This was [http://groups.google.com/group/sage-
devel/browse_thread/thread/441948aa73d1c49f a discussion on sage-devel]. 4
options were discussed for dealing with these unitary operators for lazy
numbers.
A) leaving them as they were
B) hard-coding them (as Maarten just did)
C) "fixing LazyNamedUnop to preserve documentation"
D) "populating these methods at class creation time
(rather than attribute lookup time, perhaps dynamically creating a
docstring for them)"
Option A was discarded: it lacks tab completion, and (as we saw in this
ticket) leads to a big mess and a lot of confusion when a base class such
as RingElement gets a default implementation for one of these unitary
operators.
Options C and D were suggested by you, but you seemed to be the only one
in the discussion who knew how to do them. Maarten said he was interested
in them, and then nothing happened for months.
So I guess that in the end Maarten implemented the only remaining option,
which leads to stable, transparent, understandable code that is
unfortunately a bit long.
I think the extra time that Sage developers will need when extending or
changing Maarten's long list of similar methods is not too bad if you
compare it to the time that Sage developers will need when trying to
understand more complicated code and having to debug it if something
unforeseen happens. But that's just my opinion.
+1 from me for the way Maarten implemented it.
>
> * Using _parent is just fine, especially for subclasses. No need to
incur the extra expense of a method call.
Are there general guidelines for this? I can imagine {{{_parent}}} to be
faster, but {{{parent()}}} to be more stable in case creative
implementations are in base classes.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9094#comment:28>
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 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.
