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:
<type 'exceptions.RuntimeError'>: 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/
-~----------~----~----~----~------~----~------~--~---
