Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return eigenvectors as members of a "normal" space instead of as members of an eigenspace #4834

Open
jasongrout opened this issue Dec 19, 2008 · 5 comments

Comments

@jasongrout
Copy link
Member

From sage-support:


> It looks like eigenvectors are returned as the basis vectors of the
> > eigenspace.  Should they be returned as just plain old vectors instead?

Yes, definitely.  Then we don't have create a whole bunch of different
vector spaces for no reason too.

 -- William

CC: @robertwb

Component: linear algebra

Issue created by migration from https://trac.sagemath.org/ticket/4834

@rbeezer
Copy link
Mannequin

rbeezer mannequin commented Dec 10, 2010

comment:2

Attachment: trac_4834_bug_demo.sws.gz

Attached worksheet does a better job of illustrating the problem. I plan to attack this at Bug Days if it is still open.

Can we naturally coerce vectors from lower-dimensional subspaces into the obvious ambient vector space (the one with same degree, same ring or a common super-ring)? That might be one other solution.

@rbeezer rbeezer mannequin added the s: needs info label Dec 10, 2010
@jasongrout
Copy link
Member Author

comment:3

I fiddled with this a bit, and thought I posted a patch. I can help at the Bug Days with this, if it's still open.

@rbeezer
Copy link
Mannequin

rbeezer mannequin commented Jan 11, 2011

comment:4

Following looks to me like the essence of the complaint. Eigenvectors are assigned to their eigenspaces, which I think is useful and informative, and not worth throwing away. Simple operations seem to work properly, in that computations proceed and parents are assigned accordingly.

However, when a symbolic element is introduced, then addition fails with incompatible parents. It would seem that the vector over the rationals could get promoted to be over the symbolic ring? Similar behavior occurs for an element of a number field.

sage: B=matrix([[1,2],[2,1]])
sage: spec=B.eigenvectors_right()
sage: v=spec[0][1][0]
sage: z=spec[1][1][0]
sage: v,z
((1, 1), (1, -1))
sage: v.parent()
Vector space of degree 2 and dimension 1 over Rational Field
User basis matrix:
[1 1]
sage: z.parent()
Vector space of degree 2 and dimension 1 over Rational Field
User basis matrix:
[ 1 -1]
sage: u=3*v
sage: u.parent()
Vector space of degree 2 and dimension 1 over Rational Field
User basis matrix:
[1 1]
sage: w = v + z
sage: w.parent()
Vector space of degree 2 and dimension 2 over Rational Field
User basis matrix:
[ 1 -1]
[ 1  1]

sage: var('t')
t
sage: v + t*z
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/sage/sage-4.6.1.rc1/devel/sage-main/<ipython console> in <module>()

/sage/sage-4.6.1.rc1/local/lib/python2.6/site-packages/sage/structure/element.so in sage.structure.element.ModuleElement.__add__ (sage/structure/element.c:7627)()

/sage/sage-4.6.1.rc1/local/lib/python2.6/site-packages/sage/structure/coerce.so in sage.structure.coerce.CoercionModel_cache_maps.bin_op (sage/structure/coerce.c:6995)()

TypeError: unsupported operand parent(s) for '+': 'Vector space of degree 2 and dimension 1 over Rational Field
User basis matrix:
[1 1]' and 'Vector space of degree 2 and dimension 1 over Symbolic Ring
User basis matrix:
[ 1 -1]'

sage: R.<a>=QuadraticField(-5)
sage: v + a*z
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)

/home/sage/sage-4.6.1.rc1/devel/sage-main/<ipython console> in <module>()

/sage/sage-4.6.1.rc1/local/lib/python2.6/site-packages/sage/structure/element.so in sage.structure.element.ModuleElement.__add__ (sage/structure/element.c:7627)()

/sage/sage-4.6.1.rc1/local/lib/python2.6/site-packages/sage/structure/coerce.so in sage.structure.coerce.CoercionModel_cache_maps.bin_op (sage/structure/coerce.c:6995)()

TypeError: unsupported operand parent(s) for '+': 'Vector space of degree 2 and dimension 1 over Rational Field
User basis matrix:
[1 1]' and 'Vector space of degree 2 and dimension 1 over Number Field in a with defining polynomial x^2 + 5
User basis matrix:
[ 1 -1]'

@rbeezer
Copy link
Mannequin

rbeezer mannequin commented Jan 12, 2011

comment:5

I spent some time trying to see where to add this to the coercion system, but it was beyond me. I could probably review a fix.

@rbeezer
Copy link
Mannequin

rbeezer mannequin commented Jan 22, 2011

comment:6

A workaround is to begin with symbolic matrices, which are now amenable to eigenvector computations (albeit slowly). See #6934, #10346 (coming soon to an official release). Then results (eigenvectors) are symbolic for starters, so they play nicely with a symbolic expression like the variable t.

sage: B=matrix(SR, [[1,2],[2,1]])
sage: spec=B.eigenvectors_left()
sage: spec
[(3, [(1, 1)], 1), (-1, [(1, -1)], 1)]
sage: v = spec[0][1][0]
sage: z = spec[1][1][0]
sage: z.parent()
Vector space of dimension 2 over Symbolic Ring
sage: var('t')
t
sage: v + t*z
(t + 1, -t + 1)

But I think an addition to the coercion system is still the best long-term solution, since these symbolic eigenvalue computations are not real robust.

@jdemeyer jdemeyer modified the milestones: sage-5.11, sage-5.12 Aug 13, 2013
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.1, sage-6.2 Jan 30, 2014
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.2, sage-6.3 May 6, 2014
@sagetrac-vbraun-spam sagetrac-vbraun-spam mannequin modified the milestones: sage-6.3, sage-6.4 Aug 10, 2014
@mkoeppe mkoeppe removed this from the sage-6.4 milestone Dec 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants