>
> >> 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.
As with William, I agree that this is a good idea. We can have aliases
sqrt_exact and sqrt_approx when they make sense (for example, rationals
would have both, reals would have both, where sqrt_exact throws an error
given a negative real while sqrt_approx returns a complex, Z/NZ would only
have sqrt_exact and normal sqrt).
Another issue with square roots for general rings is the following:
what do we do when there is no commonly accepted choice of square root?
Worse, what do we do when there are more than two choices (sqrt(mod(17, 32))
could return 7, 9, 23 or 25)? Pari's solution is to raise an error, GAP's
solution is to return a list of all of them, and I bet there's some system
out there that picks one.
> 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.
This would be pretty easy to implement with a system like I described.
David
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
