On Apr 27, 2007, at 7:32 AM, William Stein wrote:
>> I think the square_root
>> function should take a parameter to distinguish between the three
>> types (with default 2? One can always do sqrt(2.0) or RR(sqrt(2)),
>> etc. and I don't think causal users would be confused by \sqrt{2} as
>> an answer). One could have actual functions for the types too. E.g.
>> sqrt_approx, sqrt_extend, sqrt_exact(?).
>
> Yes. That's almost exactly what I proposed above. I prefer
> different function names, since the return results are so
> different, and since there are three options. If it were just
> one could have
> def sqrt(self, exact=True, extend=True):
> ...
>
> but it gets complicated because if exact=False, you also need
> to be able to pass in an optional precision parameter. I think
> I prefer three separate functions:
> sqrt_approx, sqrt, sqrt_exact.
Having a single function with parameters means one could pass the
parameters on, e.g. in the sqrt function for power series, on needs
to take the square root of the leading coefficient. This would let
one write more generic code. Also, the "global" sqrt could take
parameters too. Perhaps
def sqrt(self, precision=None, extend=True):
....
I think this would be in addition to the named parameters.
> sqrt(2) could be an element of the number field K=Q[x]/(x^2-2)
> *equipped* with an embedding map K --> SR that sends x to
> the symbolic ring element sqrt(2). We could also equip K with maps
> to RR, CC, etc., by choosing a root to some precision (which would
> choose a root to any bigger precision automatically). More generally,
> at creation time one could equip any ParentWithGens object with
> a list of embedding morphisms that should be used by the coercion
> system automatically. This list is would be immutable. So there
> would be a new number field class NumberField_with_embedding(s).
I think this should be an ability of any parent (with gens?), and one
would not necessarily have to create a new class
NumberField_with_embeddings.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
