[sage-devel] Re: Multiple return values
On Jan 17, 8:28 pm, Nick Alexander <[EMAIL PROTECTED]> wrote:
> On 17-Jan-08, at 10:19 AM, Soroosh Yazdani wrote:
>
> > The advantage of creating X is that it can cache the above data
> > for efficiency.
> > +1
>
> +1 -- this kind of structure is what makes Sage more powerful than GP/
> PARI and often Magma.
...+1 = 4
To say something positive about Magma's design: Apparently Magma
*does* the thing with creating X, at least in some context.
Example:
> K:=RationalField();
> G:=TransitiveGroup(7,1);
> X:=InvariantRing(G,K); // does nothing!
> time G1:=FundamentalInvariants(X);
Time: 25.520 // ... or 0.19 in Singular! (little advertisement...)
> time G2:=FundamentalInvariants(X);
Time: 0.000 // ... so they do caching!
>From a mathematical point of view, it is the most natural thing that X
= Iso(E1,E2) is an object.
So, the X-thing is intuitive, IMO good design, it is pythonesque
("everything is an object") and (via caching) powerful.
Yours
Simon
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
> I will try to take all the above on board as I am implementing it, and > look forward to having you people make constructive criticisms > But David K's suggestion about the set of all iso/automorphisms might > wait until the next round. I (or someone else) can implement the structures of Iso's at a later date and any existing, relevant member functions moved or copied to these structures later. > I hope that people other than elliptic curve afficionados have been > following this thread, since the whole discussion is relevant in many > other contexts and (as has been said) we definitely want a consistent > interface. +1 -- the subject (multiple return values) was intentionally broad to address the wider audience. Cheers, 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
I will try to take all the above on board as I am implementing it, and look forward to having you people make constructive criticisms But David K's suggestion about the set of all iso/automorphisms might wait until the next round. I hope that people other than elliptic curve afficionados have been following this thread, since the whole discussion is relevant in many other contexts and (as has been said) we definitely want a consistent interface. John On 17/01/2008, Nick Alexander <[EMAIL PROTECTED]> wrote: > > > On 17-Jan-08, at 10:19 AM, Soroosh Yazdani wrote: > > > On Jan 17, 2008 9:33 AM, David Kohel <[EMAIL PROTECTED]> wrote: > > X = Iso(E1,E2) # does nothing > > X.cardinality() # tests is_isomorphic and j-invariant = 0 or 12^3 > > X.representative() # computes an isomorphism > > X.list() # computes all isomorphisms > > > > The advantage of creating X is that it can cache the above data > > for efficiency. > > +1 > > +1 -- this kind of structure is what makes Sage more powerful than GP/ > PARI and often Magma. > > What's old is new again: Smalltalkers say 'everything is an object' > and Sage should too. > > Nick > > > > -- John Cremona --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
On 17-Jan-08, at 10:19 AM, Soroosh Yazdani wrote: > On Jan 17, 2008 9:33 AM, David Kohel <[EMAIL PROTECTED]> wrote: > X = Iso(E1,E2) # does nothing > X.cardinality() # tests is_isomorphic and j-invariant = 0 or 12^3 > X.representative() # computes an isomorphism > X.list() # computes all isomorphisms > > The advantage of creating X is that it can cache the above data > for efficiency. > +1 +1 -- this kind of structure is what makes Sage more powerful than GP/ PARI and often Magma. What's old is new again: Smalltalkers say 'everything is an object' and Sage should too. Nick --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
On Jan 17, 6:33 am, David Kohel <[EMAIL PROTECTED]> wrote: > This is my question: do we have functions which can return > different types depending on the arguments passed in? > Whatever its design flaws, it has been the philosophy that > this should not be the case in Magma. The alternative is > to have a different function: > > E1.is_isomorphic_with_isomorphism(E2) # or is_isomorphic_with_map > > I would like to hear from someone on the "correct" Python style. > Note that this syntax should be followed throughout the SAGE > language, in groups, rings, etc., so we should have a convention. We do currently have several functions where the shape of the return value depends on the arguments. For example: sage: (4.0).sqrt() 2.00 sage: (4.0).sqrt(all=True) [2.00, -2.00] sage: x = polygen(ZZ) sage: (x^2-1).roots() [(1, 1), (-1, 1)] sage: (x^2-1).roots(multiplicities=False) [1, -1] Carl --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
On Jan 17, 2008 9:33 AM, David Kohel <[EMAIL PROTECTED]> wrote: > X = Iso(E1,E2) # does nothing > X.cardinality() # tests is_isomorphic and j-invariant = 0 or 12^3 > X.representative() # computes an isomorphism > X.list() # computes all isomorphisms > > The advantage of creating X is that it can cache the above data > for efficiency. > +1 This seems like a very nice interface to the problem from my perspective, and it can be applied to other classes as well. Soroosh --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
On Jan 17, 2008, at 6:33 AM, David Kohel wrote: >> E1.is_isomorphic(E2) >> >> always returns one boolean. > > +1 I agree too. > >> If you want the map too, you have write >> something explicit, e.g., >> >>t, phi = E1.is_isomorphic(E2, with_map=True) >> >> where phi will be None they aren't isomorphic. > > This is my question: do we have functions which can return > different types depending on the arguments passed in? I think this is best avoided. > Whatever its design flaws, it has been the philosophy that > this should not be the case in Magma. The alternative is > to have a different function: > > E1.is_isomorphic_with_isomorphism(E2) # or is_isomorphic_with_map > > I would like to hear from someone on the "correct" Python style. > Note that this syntax should be followed throughout the SAGE > language, in groups, rings, etc., so we should have a convention. > > I would also propose the syntax: > > E1.isomorphism(E2) > > rather than E1.isomorphism_to(E2) as the direction should be clear. > The latter implies E1.isomorphism_from(E2) should also exist, but > I don't see an argument or context in which E1.isomorphism(E2) and > E2.isomorphism(E1) would not suffice. Seems sensible to me. > Thus we could have: > > E1.is_isomorphic(E2) > E1.is_isomorphic_with_isomorphism(E2) # or > E1.is_isomorphic_with_map(E2) > E1.isomorphism(E2) > > The middle one could be replaced with > E1.is_isomorphism(E2,with_isomorphism=True) > (of with_map) if this is judged acceptable SAGE/Python syntax. I > would propose we endeavor to have the same return type (or None) > independent of the arguments given. The middle two seem redundant (with the first and last)--especially if we're going to replicate this over all of Sage (though perhaps it could be done at a very high level, which I would be much more OK with). I would propose that E1.isomorphism(E2) raise an exception if E1 is not isomorphic to E2, but one could pass in a flag to make it return None rather than raise an error (if that suits your efficiency/ programing style better). If there is more than one isomorphism, I don't think all of them should be computed and returned unless they are explicitly asked for. > John mentioned calculation of all isomorphisms. I propose that the > set > of all isomorphisms be a SAGE object. Thus > > X = Iso(E1,E2) # does nothing > X.cardinality() # tests is_isomorphic and j-invariant = 0 or 12^3 > X.representative() # computes an isomorphism > X.list() # computes all isomorphisms > > The advantage of creating X is that it can cache the above data > for efficiency. > > Moreover is E1 = E2, we could do > > G = Aut(E1) # or Iso(E1,E1) > G.group() > G.group_with_isomorphism() > A = AbelianGroup(2) > A.is_isomorphic(G) > A.is_isomorphic_with_isomorphism(G) > A.isomorphism(G) > > Again, this should be a common syntax throughout SAGE. +1 - Robert --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
Hi, Agreed that Magma > I'll just come out and say it -- It's a _terrible_ design in Magma. +1. > Yet another example of the Magma semantics being a pain. > They don't even use a notion of None. Argh. +1 ; Although there is a syntax to denote no argument (return x, _;) The problem is that in Magma x, y := SomeFunction(a,b,c,...) just ignores the existence of y (if _ is the return value) rather than assigning a None (which doesn't exist as a Magma object) to it. > E1.is_isomorphic(E2) > > always returns one boolean. +1 > If you want the map too, you have write > something explicit, e.g., > >t, phi = E1.is_isomorphic(E2, with_map=True) > > where phi will be None they aren't isomorphic. This is my question: do we have functions which can return different types depending on the arguments passed in? Whatever its design flaws, it has been the philosophy that this should not be the case in Magma. The alternative is to have a different function: E1.is_isomorphic_with_isomorphism(E2) # or is_isomorphic_with_map I would like to hear from someone on the "correct" Python style. Note that this syntax should be followed throughout the SAGE language, in groups, rings, etc., so we should have a convention. I would also propose the syntax: E1.isomorphism(E2) rather than E1.isomorphism_to(E2) as the direction should be clear. The latter implies E1.isomorphism_from(E2) should also exist, but I don't see an argument or context in which E1.isomorphism(E2) and E2.isomorphism(E1) would not suffice. Thus we could have: E1.is_isomorphic(E2) E1.is_isomorphic_with_isomorphism(E2) # or E1.is_isomorphic_with_map(E2) E1.isomorphism(E2) The middle one could be replaced with E1.is_isomorphism(E2,with_isomorphism=True) (of with_map) if this is judged acceptable SAGE/Python syntax. I would propose we endeavor to have the same return type (or None) independent of the arguments given. John mentioned calculation of all isomorphisms. I propose that the set of all isomorphisms be a SAGE object. Thus X = Iso(E1,E2) # does nothing X.cardinality() # tests is_isomorphic and j-invariant = 0 or 12^3 X.representative() # computes an isomorphism X.list() # computes all isomorphisms The advantage of creating X is that it can cache the above data for efficiency. Moreover is E1 = E2, we could do G = Aut(E1) # or Iso(E1,E1) G.group() G.group_with_isomorphism() A = AbelianGroup(2) A.is_isomorphic(G) A.is_isomorphic_with_isomorphism(G) A.isomorphism(G) Again, this should be a common syntax throughout SAGE. --David As long as there are examples > and documentation this is easy to use and very easy to read. > > Justin says: > > > Trying to unwind code that relies > > on this will be a headache, and we should be considering > > maintainability as we go. It's always tough to start tackling a > > large code base long after the original developers have moved on, and > > this kind of trickery won't help a bit. > > In any case, we have to make it possible to use things in Magma from > Sage that people want to use. Just not doing so isn't an option. > > > Still on this specific subthread, I think there must be many > > situations where as well as David's comment that computing one iso is > > not much more work than checking if one exists, one can compute *all* > > isos in not much more time than computing one. In that case I would > > want to implement E1.isomorphisms_to(E2) [note the "s"!] which > > returns a possibly empty list of all iso's from E1 to E2. Then > > E1.is_isomorphic_to(E2) can be *literally* synonymous with > > E1.isomorphisms_to(E2) thanks to Pythons convention that a list is > > "true" if and only if not empty (you can see that I have been reading > > up on Python!). And then E1.isomorphism_to(E2) can return > > E1.isomorphisms_to(E2)[0] with suitable error-catching if the list was > > empty. And finally, E1.isomorphisms_to(E1) would return the set of > > automorphisms of E1. > > I don't think I like that. Shouldn't a function named > is_something(...) return True > or False by default? Taking this further, what would you do with > n.is_prime() > for n an integer? Or with something like x.is_zero_divisor()? > > > All the above is certainly good for the case of ellitpic curves which > > have finite automorphsm groups (and almost always of size 2) so the > > above lists are mainly of length 0 or 2. But maybe elsewhere too? > > > John --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
On Jan 16, 2008 12:34 PM, John Cremona <[EMAIL PROTECTED]> wrote: > William is right that with Python there is no need to have variable > numbers of return variables (for Python functions, I don't mean > Magma). In situations like is_isomorphic() we can always return a > tuple of 2 values, either (true, i) with i an isomorphism or (false, > None). So the calling program can unpack the tuple into 2 values and > only look at the second if the first is true. However that breaks > code which looks correct if written simply as > if E2.is_isomorphic(E2): > do something Hmm. I think it should be that E1.is_isomorphic(E2) always returns one boolean. If you want the map too, you have write something explicit, e.g., t, phi = E1.is_isomorphic(E2, with_map=True) where phi will be None they aren't isomorphic. As long as there are examples and documentation this is easy to use and very easy to read. Justin says: > Trying to unwind code that relies > on this will be a headache, and we should be considering > maintainability as we go. It's always tough to start tackling a > large code base long after the original developers have moved on, and > this kind of trickery won't help a bit. In any case, we have to make it possible to use things in Magma from Sage that people want to use. Just not doing so isn't an option. > Still on this specific subthread, I think there must be many > situations where as well as David's comment that computing one iso is > not much more work than checking if one exists, one can compute *all* > isos in not much more time than computing one. In that case I would > want to implement E1.isomorphisms_to(E2) [note the "s"!] which > returns a possibly empty list of all iso's from E1 to E2. Then > E1.is_isomorphic_to(E2) can be *literally* synonymous with > E1.isomorphisms_to(E2) thanks to Pythons convention that a list is > "true" if and only if not empty (you can see that I have been reading > up on Python!). And then E1.isomorphism_to(E2) can return > E1.isomorphisms_to(E2)[0] with suitable error-catching if the list was > empty. And finally, E1.isomorphisms_to(E1) would return the set of > automorphisms of E1. I don't think I like that. Shouldn't a function named is_something(...) return True or False by default? Taking this further, what would you do with n.is_prime() for n an integer? Or with something like x.is_zero_divisor()? > All the above is certainly good for the case of ellitpic curves which > have finite automorphsm groups (and almost always of size 2) so the > above lists are mainly of length 0 or 2. But maybe elsewhere too? > > John > --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
William is right that with Python there is no need to have variable numbers of return variables (for Python functions, I don't mean Magma). In situations like is_isomorphic() we can always return a tuple of 2 values, either (true, i) with i an isomorphism or (false, None). So the calling program can unpack the tuple into 2 values and only look at the second if the first is true. However that breaks code which looks correct if written simply as if E2.is_isomorphic(E2): do something Still on this specific subthread, I think there must be many situations where as well as David's comment that computing one iso is not much more work than checking if one exists, one can compute *all* isos in not much more time than computing one. In that case I would want to implement E1.isomorphisms_to(E2) [note the "s"!] which returns a possibly empty list of all iso's from E1 to E2. Then E1.is_isomorphic_to(E2) can be *literally* synonymous with E1.isomorphisms_to(E2) thanks to Pythons convention that a list is "true" if and only if not empty (you can see that I have been reading up on Python!). And then E1.isomorphism_to(E2) can return E1.isomorphisms_to(E2)[0] with suitable error-catching if the list was empty. And finally, E1.isomorphisms_to(E1) would return the set of automorphisms of E1. All the above is certainly good for the case of ellitpic curves which have finite automorphsm groups (and almost always of size 2) so the above lists are mainly of length 0 or 2. But maybe elsewhere too? John On 16/01/2008, Justin C. Walker <[EMAIL PROTECTED]> wrote: > > > On Jan 16, 2008, at 10:31 AM, William Stein wrote: > > > > > On Jan 16, 2008 9:26 AM, Robert Bradshaw > > <[EMAIL PROTECTED]> wrote: > >> > >> There is no way in python to detect how many arguments a function > >> result will be assigned to, and I'm not a fan of magma's way of doing > >> it. WIth variable length tuples one has to check the length of a > >> tuple before unpacking it. > > > > I'll just come out and say it -- It's a _terrible_ design in Magma. > > +1. > > I think this is really bad design. Trying to unwind code that relies > on this will be a headache, and we should be considering > maintainability as we go. It's always tough to start tackling a > large code base long after the original developers have moved on, and > this kind of trickery won't help a bit. > > Justin > > -- > Justin C. Walker, Curmudgeon-At-Large > Institute for the Absorption of Federal Funds > > Some people have a mental horizon of radius zero, and > call it their point of view. >-- David Hilbert > > > > > > > -- John Cremona --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
On Jan 16, 2008, at 10:31 AM, William Stein wrote: > > On Jan 16, 2008 9:26 AM, Robert Bradshaw > <[EMAIL PROTECTED]> wrote: >> >> There is no way in python to detect how many arguments a function >> result will be assigned to, and I'm not a fan of magma's way of doing >> it. WIth variable length tuples one has to check the length of a >> tuple before unpacking it. > > I'll just come out and say it -- It's a _terrible_ design in Magma. +1. I think this is really bad design. Trying to unwind code that relies on this will be a headache, and we should be considering maintainability as we go. It's always tough to start tackling a large code base long after the original developers have moved on, and this kind of trickery won't help a bit. Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds Some people have a mental horizon of radius zero, and call it their point of view. -- David Hilbert --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
On Jan 16, 2008 11:31 AM, William Stein <[EMAIL PROTECTED]> wrote: > > On Jan 16, 2008 9:26 AM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > > > There is no way in python to detect how many arguments a function > > result will be assigned to, and I'm not a fan of magma's way of doing > > it. WIth variable length tuples one has to check the length of a > > tuple before unpacking it. > > I'll just come out and say it -- It's a _terrible_ design in Magma. I also > found it bad when I used it. I once overheard somebody at IHP in Paris > talking with John Cannon about Magma and learning of variable numbers > of return arguments (as in Magma), and just being incredulous that they > could have actually implemented something like that. And personally > it makes the computer scientist in me cringe. > > Python's solution to the multiple-return-values problem, with > automatic tuple unpacking, is much more elegant. And it's worth noting that for py3k they added the very nice extension: >>> a, *b, c = range(5) >>> a 0 >>> c 4 >>> b [1, 2, 3] Details here: http://www.python.org/dev/peps/pep-3132/ Cheers, f --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
On Jan 16, 2008 10:34 AM, Kiran Kedlaya <[EMAIL PROTECTED]> wrote: > > Before proceeding, let me thank William for answering my original > question. In the case I was interested in, the number of return values > does not vary in any funny way, so I can use nvals to get what I want > back out. > > But in the example of IsIsomorphic, there seems to be a problem. If I > start Magma and type > > > E := EllipticCurve([2,1]); > > F := EllipticCurve([5,1]); > > bool, phi := IsIsomorphic(E,F); > > then the identifier phi remains undefined! And in Sage, if I type > > sage: E = magma.EllipticCurve([2,1]); > sage: F = magma.EllipticCurve([5,1]) > sage: bool, phi = magma.IsIsomorphic(E, F, nvals=2) > > this generates an error: > > : Error evaluation Magma code. > IN:_sage_[9], _sage_[10] := IsIsomorphic(_sage_[4],_sage_[8]); > OUT: > >> _sage_[9], _sage_[10] := IsIsomorphic(_sage_[4],_sage_[8]); > ^ > Runtime error in :=: Illegal undefined assignment for LHS index > assignment > > In a perfect world, the above would run and produce bool == False, phi > == None. Sigh. Yet another example of the Magma semantics being a pain. They don't even use a notion of None. Argh. Anyway, it might be possible to program around the above problem via some complicated Magma trickiery. Definitely report it as a bug to the Sage tracer. 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
Before proceeding, let me thank William for answering my original question. In the case I was interested in, the number of return values does not vary in any funny way, so I can use nvals to get what I want back out. But in the example of IsIsomorphic, there seems to be a problem. If I start Magma and type > E := EllipticCurve([2,1]); > F := EllipticCurve([5,1]); > bool, phi := IsIsomorphic(E,F); then the identifier phi remains undefined! And in Sage, if I type sage: E = magma.EllipticCurve([2,1]); sage: F = magma.EllipticCurve([5,1]) sage: bool, phi = magma.IsIsomorphic(E, F, nvals=2) this generates an error: : Error evaluation Magma code. IN:_sage_[9], _sage_[10] := IsIsomorphic(_sage_[4],_sage_[8]); OUT: >> _sage_[9], _sage_[10] := IsIsomorphic(_sage_[4],_sage_[8]); ^ Runtime error in :=: Illegal undefined assignment for LHS index assignment In a perfect world, the above would run and produce bool == False, phi == None. Sigh. Kiran On Jan 16, 12:26 pm, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > There is no way in python to detect how many arguments a function > result will be assigned to, and I'm not a fan of magma's way of doing > it. WIth variable length tuples one has to check the length of a > tuple before unpacking it. > > There is a function E1.isomorphism_to(E2) that actually computes the > isomorphism. I think is_isomorphism should just return True or False > (is_* has that convention). Then one can do such things as > > if E.is_isomporhic(F): > ... > > Perhaps an optional argument "compute" which computes and then caches > or returns the actual isomorphism. > > - Robert > > On Jan 16, 2008, at 6:03 AM, John Cremona wrote: > > > What a coincidence -- the patch I am working on *will* (have the > > capability to) return both a boolean and an isomorphism for > > is_isomorphic() on elliptic curves. I was wondering how to do that > > and assumed that it would be a tuple. Rather than make the tuple's > > length (1 or 2) depend on the input I would always return a tuple of > > length 2 but the second item would be None iff the first has false. > > Isn't that a reasonable way of doing it? > > > I don't like requiring the trapping of errors, though I realise that > > it is very Pythonesque to do so. But if we allow the input line > > sage: phi = E1.isomorphism(E2) > > > then we *must* raise an error when the things are not isomorphic, > > just as > > sage: QQ(2).nth_root(2) > > raises as ValueError (though sqrt(2) does not as it creates a > > symbolic sqrt(2)). > > > This is going beyond the original thread, I know. > > > On 16/01/2008, David Kohel <[EMAIL PROTECTED]> wrote: > > >> There was a thread on multiple return values coming from Magma, > >> since renamed to "Integer points on conics" > > >> William pointed out that one can access the multiple return values > >> using nvals: > > >> x = magma.XGCD(15, 10) > >> x,y,z = magma.XGCD(15, 10, nvals = 3) > > >> The first returns an integer, while the second returns a tuple. > > >> Q1: Is this an acceptable general construction for Python and/or > >> SAGE, > >> namely to return a different type depending on the values passed into > >> it? Is it acceptable when it is controlled by nvals in exactly this > >> way? > > >> As William pointed out, very different algorithms can be called > >> depending on the > >> number of arguments requested in Magma. The following is an example: > > >> sage: E = magma.EllipticCurve([1,3]) > >> sage: magma.IsIsomorphic(E,E) > >> true > >> sage: bool, phi = magma.IsIsomorphic(E,E,nvals=2) > >> sage: phi > >> Elliptic curve isomorphism from: Elliptic Curve defined by y^2 = > >> x^3 + > >> x + 3 over Rational Field to Elliptic Curve defined by y^2 = x^3 + > >> x + > >> 3 over Rational Field > >> Taking (x : y : 1) to (x : y : 1) > > >> Currently in SAGE we have: > > >> sage: E = EllipticCurve([1,3]) > >> sage: E.is_isomorphic(E) > >> True > > >> Q2: Would the following be acceptable way of implementing equivalent > >> functionality in SAGE?: > > >> sage: bool, phi = E.is_isomorphic(E, nvals=2) > > >> Note that often (in many concexts) it more expensive to return an > >> isomorphism, but only slightly more so compared with recomputing the > >> isomorphism test. If the answer to my question is "no, it not > >> acceptable SAGE/Python syntax", then how should we implement this > >> functionality? One possibility is: > > >> sage: phi = E1.isomorphism(E2) > > >> and to trap an error if is_isomorphic returns false. Is this a > >> better? > > > -- > > John Cremona --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
On Jan 16, 2008 9:26 AM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > > There is no way in python to detect how many arguments a function > result will be assigned to, and I'm not a fan of magma's way of doing > it. WIth variable length tuples one has to check the length of a > tuple before unpacking it. I'll just come out and say it -- It's a _terrible_ design in Magma. I also found it bad when I used it. I once overheard somebody at IHP in Paris talking with John Cannon about Magma and learning of variable numbers of return arguments (as in Magma), and just being incredulous that they could have actually implemented something like that. And personally it makes the computer scientist in me cringe. Python's solution to the multiple-return-values problem, with automatic tuple unpacking, is much more elegant. > There is a function E1.isomorphism_to(E2) that actually computes the > isomorphism. I think is_isomorphism should just return True or False > (is_* has that convention). Then one can do such things as > > if E.is_isomporhic(F): > ... > > Perhaps an optional argument "compute" which computes and then caches > or returns the actual isomorphism. +1 That's explicit and clear. 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
There is no way in python to detect how many arguments a function result will be assigned to, and I'm not a fan of magma's way of doing it. WIth variable length tuples one has to check the length of a tuple before unpacking it. There is a function E1.isomorphism_to(E2) that actually computes the isomorphism. I think is_isomorphism should just return True or False (is_* has that convention). Then one can do such things as if E.is_isomporhic(F): ... Perhaps an optional argument "compute" which computes and then caches or returns the actual isomorphism. - Robert On Jan 16, 2008, at 6:03 AM, John Cremona wrote: > What a coincidence -- the patch I am working on *will* (have the > capability to) return both a boolean and an isomorphism for > is_isomorphic() on elliptic curves. I was wondering how to do that > and assumed that it would be a tuple. Rather than make the tuple's > length (1 or 2) depend on the input I would always return a tuple of > length 2 but the second item would be None iff the first has false. > Isn't that a reasonable way of doing it? > > I don't like requiring the trapping of errors, though I realise that > it is very Pythonesque to do so. But if we allow the input line > sage: phi = E1.isomorphism(E2) > > then we *must* raise an error when the things are not isomorphic, > just as > sage: QQ(2).nth_root(2) > raises as ValueError (though sqrt(2) does not as it creates a > symbolic sqrt(2)). > > This is going beyond the original thread, I know. > > On 16/01/2008, David Kohel <[EMAIL PROTECTED]> wrote: >> >> There was a thread on multiple return values coming from Magma, >> since renamed to "Integer points on conics" >> >> William pointed out that one can access the multiple return values >> using nvals: >> >> x = magma.XGCD(15, 10) >> x,y,z = magma.XGCD(15, 10, nvals = 3) >> >> The first returns an integer, while the second returns a tuple. >> >> Q1: Is this an acceptable general construction for Python and/or >> SAGE, >> namely to return a different type depending on the values passed into >> it? Is it acceptable when it is controlled by nvals in exactly this >> way? >> >> As William pointed out, very different algorithms can be called >> depending on the >> number of arguments requested in Magma. The following is an example: >> >> sage: E = magma.EllipticCurve([1,3]) >> sage: magma.IsIsomorphic(E,E) >> true >> sage: bool, phi = magma.IsIsomorphic(E,E,nvals=2) >> sage: phi >> Elliptic curve isomorphism from: Elliptic Curve defined by y^2 = >> x^3 + >> x + 3 over Rational Field to Elliptic Curve defined by y^2 = x^3 + >> x + >> 3 over Rational Field >> Taking (x : y : 1) to (x : y : 1) >> >> Currently in SAGE we have: >> >> sage: E = EllipticCurve([1,3]) >> sage: E.is_isomorphic(E) >> True >> >> Q2: Would the following be acceptable way of implementing equivalent >> functionality in SAGE?: >> >> sage: bool, phi = E.is_isomorphic(E, nvals=2) >> >> Note that often (in many concexts) it more expensive to return an >> isomorphism, but only slightly more so compared with recomputing the >> isomorphism test. If the answer to my question is "no, it not >> acceptable SAGE/Python syntax", then how should we implement this >> functionality? One possibility is: >> >> sage: phi = E1.isomorphism(E2) >> >> and to trap an error if is_isomorphic returns false. Is this a >> better? >> >>> >> > > > -- > John Cremona > > --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
[sage-devel] Re: Multiple return values
What a coincidence -- the patch I am working on *will* (have the capability to) return both a boolean and an isomorphism for is_isomorphic() on elliptic curves. I was wondering how to do that and assumed that it would be a tuple. Rather than make the tuple's length (1 or 2) depend on the input I would always return a tuple of length 2 but the second item would be None iff the first has false. Isn't that a reasonable way of doing it? I don't like requiring the trapping of errors, though I realise that it is very Pythonesque to do so. But if we allow the input line sage: phi = E1.isomorphism(E2) then we *must* raise an error when the things are not isomorphic, just as sage: QQ(2).nth_root(2) raises as ValueError (though sqrt(2) does not as it creates a symbolic sqrt(2)). This is going beyond the original thread, I know. On 16/01/2008, David Kohel <[EMAIL PROTECTED]> wrote: > > There was a thread on multiple return values coming from Magma, > since renamed to "Integer points on conics" > > William pointed out that one can access the multiple return values > using nvals: > > x = magma.XGCD(15, 10) > x,y,z = magma.XGCD(15, 10, nvals = 3) > > The first returns an integer, while the second returns a tuple. > > Q1: Is this an acceptable general construction for Python and/or SAGE, > namely to return a different type depending on the values passed into > it? Is it acceptable when it is controlled by nvals in exactly this > way? > > As William pointed out, very different algorithms can be called > depending on the > number of arguments requested in Magma. The following is an example: > > sage: E = magma.EllipticCurve([1,3]) > sage: magma.IsIsomorphic(E,E) > true > sage: bool, phi = magma.IsIsomorphic(E,E,nvals=2) > sage: phi > Elliptic curve isomorphism from: Elliptic Curve defined by y^2 = x^3 + > x + 3 over Rational Field to Elliptic Curve defined by y^2 = x^3 + x + > 3 over Rational Field > Taking (x : y : 1) to (x : y : 1) > > Currently in SAGE we have: > > sage: E = EllipticCurve([1,3]) > sage: E.is_isomorphic(E) > True > > Q2: Would the following be acceptable way of implementing equivalent > functionality in SAGE?: > > sage: bool, phi = E.is_isomorphic(E, nvals=2) > > Note that often (in many concexts) it more expensive to return an > isomorphism, but only slightly more so compared with recomputing the > isomorphism test. If the answer to my question is "no, it not > acceptable SAGE/Python syntax", then how should we implement this > functionality? One possibility is: > > sage: phi = E1.isomorphism(E2) > > and to trap an error if is_isomorphic returns false. Is this a > better? > > > > -- John Cremona --~--~-~--~~~---~--~~ 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/ -~--~~~~--~~--~--~---
