On 4/27/07, David Roe <[EMAIL PROTECTED]> wrote: > > 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.
Why don't we have another flag, e.g., def sqrt(self, precision=None, extend=True, all=False): If all == True, return a list of all square roots. Otherwise just return 1, where we choose some documented convention in each case. > > > 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. Excellent. William --~--~---------~--~----~------------~-------~--~----~ 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/ -~----------~----~----~----~------~----~------~--~---
