Opened 10 years ago

Last modified 10 years ago

#11556 closed enhancement

Linear transformations, built from free module morphisms — at Version 12

Reported by: rbeezer Owned by: jason, was
Priority: major Milestone: sage-4.8
Component: linear algebra Keywords:
Cc: jason Merged in:
Authors: Rob Beezer Reviewers: Martin Raum
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #11552, #11553 Stopgaps:

Status badges

Description (last modified by mraum)

This patch builds vector space morphisms, aka linear transformations, from free module morphisms. This allows for a few specialized methods, such as an easier test for invertibility (check the rank of a matrix representation). But it is mostly about (a) a "linear transformation" constructor for beginners' use, (b) lots of documentation, (c) specialized output routines, so it is clear when a morphism runs between two vecto5r space (not just two free modules).

(c) required lots of doctest changes. When the example was complicated and involved two vector spaces, I usually changed the output to match the new format for the new morphisms. When teh example was simple, I tried to "roll it back" to involve two free modules, to fully exercise that code.

Additionally, there were a lot of doctests with matrices of the wrong size, reversing domain and codomain, that managed to pass due to the bug listed in #10793. Tighter controls here required fixing a lot of these.

Depends:

  1. #11552
  2. #11553

Apply:

  1. trac_11556-linear-transformations-v4.patch
  2. trac_11556-linear-transformations-edits-v3.patch

Change History (19)

Changed 10 years ago by rbeezer

Safe-keeping patch

comment:1 Changed 10 years ago by rbeezer

  • Authors set to Rob Beezer
  • Cc jason added

Patch is mostly up for safe-keeping.

(a) Passes most tests in sage/modules, failures are just output formatting.

(b) Functional, see module-level docs for vector_space_homspace.py.

(c) vector_space_morphisms.py remains to be overhauled - significant module-level documentation, a friendly constructor, and general touch-up.

(d) Need to add two new files to the overall reference documentation.

Changed 10 years ago by rbeezer

Working patch, needs doctests, here for safe-keeping

comment:2 Changed 10 years ago by rbeezer

  • Dependencies set to #11552, #11553
  • Description modified (diff)
  • Status changed from new to needs_review

Changed 10 years ago by rbeezer

comment:3 Changed 10 years ago by rbeezer

Ready for review.

Feeding the patchbot:

Depends #11552, #11553

Apply trac_11556-linear-transformations-v3.patch

Changed 10 years ago by rbeezer

comment:4 Changed 10 years ago by rbeezer

  • Description modified (diff)

v4 patch adds making full-spelling aliases for minpoly and charpoly of free module morphisms, in line with the nomenclature for matrices.

comment:5 follow-up: Changed 10 years ago by mraum

  • Reviewers set to Martin Raum

Hi Robert,

There are very few changes that I propose for this patch. Sorry, for not making them myself, but I somehow happened to lack time again.

  1. Add newline at the end of free_module_morphism.py.
  2. In vector_space_morphism.py l.475f it is not clear what side refers to. Delete the sentence?
  3. l. 639 of the same file contains a typo.
  4. l. 689ff do the imports globally. If for conflicts you cannot move the import statements to the file's head, move at least as many as you can.
  5. l. 756ff is indeed no sufficient to check for linearity. Is there a specific reason why you don't use is_polynomial()? Then check the degree and you are fine.
  6. l. 775 do you want to keep that line or rather merge with l. 732?
  7. l. 856 move this import if possible

With these very minor changes made, this ticket deserves a positive review.

comment:6 in reply to: ↑ 5 Changed 10 years ago by rbeezer

Replying to mraum:

  1. In vector_space_morphism.py l.475f it is not clear what side refers to.

Delete the sentence?

Actual output from _repr_() once made it clearer, but I trimmed the amount of output later. I will expand the sentence.

  1. l. 756ff is indeed no sufficient to check for linearity. Is there a

specific reason why you don't use is_polynomial()? Then check the degree and you are fine.

I did not think I could fully protect against all possible symbolic expressions sneaking through. But I had not thought about is_polynomial() which sounds like a good idea.

  1. l. 775 do you want to keep that line or rather merge with l. 732?

Mistaken leftover from various attempts to get unique parents. ;-)

  1. l. 856 move this import if possible

Generally: I did some reading a few months ago about imports, and got the impression that there was very little cost to placing within a method a statement like

import foo.bar

and then subsequently calling as

answer = foo.bar.stuff()

This is not exactly what is happening at l. 856, but on other tickets, you have suggested moving imports. What is the best strategy? I thought in module headers it would count against startuptime? Guess I'm just confused on what is best.

Thanks for all the help on all these tickets. It is really good to see them all getting wrapped up.

Rob

comment:7 Changed 10 years ago by mraum

Concerning the imports and the performance, the following link might help: http://stackoverflow.com/questions/477096/python-import-coding-style

It exposes my suggestion as premature, and if you like to keep the imports as they are, do so.

comment:8 Changed 10 years ago by rbeezer

Hi Martin,

Caught me just in time on the imports. Thanks for the link, that was helpful and confirmed my understanding from before. I can do a bit of cleanup on the imports, and will move one that is used twice to the top of the file. Otherwise, I will largely leave all those imports in the constructor since I think it makes the rest of the module easier to read with all those segregated.

I'm not sure is_polynomial() is going to work. Consider:

sage: var('x y')
(x, y)
sage: g(x, y) = x*y
sage: g.is_polynomial(x)
True
sage: g.is_polynomial(y)
True
sage: g.degree(x)
1
sage: g.degree(y)
1

I think I can do worse, with negative and/or fractional exponents. I'm open to ideas, but I guess I'm back to feeling there is no good way to confirm an arbitrary (callable) symbolic expression as being multivariate linear (including no constant term). Will post a patch of changes in a few minutes, or later today.

Rob

comment:9 Changed 10 years ago by rbeezer

  • Description modified (diff)

"edits" patch addresses all of the reviewer suggestions, except linearity testing. I'm open to trying new things to improve error-checking for linear function input.

comment:10 follow-up: Changed 10 years ago by mraum

There is one thing left. Sorry, for this, but I probably wasn't very precise. In 2. you added a bit more explanation, but I was referring to the fact that the keyword side only influences matrices. Many lines above there is one example that demonstrates how it works. The sentence that I referred to is placed before a series of examples dealing with lambda expressions and symbolic functions. Do I get this wrong?

Concerning the linear polynomials you are probably right. I thought about something like extracting linear coefficients and then trying to recombine them. But that would have a great impact on performance. Also, lambda expressions cannot be tested for linearity either.

comment:11 in reply to: ↑ 10 Changed 10 years ago by rbeezer

Replying to mraum:

Do I get this wrong?

No, my mistake. Sorry about that. I thought the examples following used the side keyword, but obviously I did not look very carefully.

"edits-v2" patch just deletes the sentence, but has some discussion elsewhere about the side. So I think this is ready for review now.

comment:12 Changed 10 years ago by mraum

  • Description modified (diff)
  • Status changed from needs_review to positive_review

Great! I only changed one type (one -> on), thus the new patch.

Note: See TracTickets for help on using tickets.