Opened 11 years ago
Closed 3 years ago
#10941 closed defect (invalid)
ModularSymbols(4727).cuspidal_submodule().decomposition() fails
Reported by: | nbruin | Owned by: | craigcitro |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | modular forms | Keywords: | |
Cc: | AlexGhitza, kedlaya | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
sage: M = ModularSymbols(Integer(4727)) sage: C=M.cuspidal_submodule() sage: dec=C.decomposition() TypeError: element (= [0, 0, ..., 1, 0, 0, 0, 3]) is not in free module
(but getting to this point takes about 75 minutes on sage.math)
Change History (12)
comment:1 Changed 11 years ago by
- Cc AlexGhitza added
comment:2 Changed 10 years ago by
- Status changed from new to needs_info
comment:3 Changed 10 years ago by
- Status changed from needs_info to needs_review
In fact just after I wrote that there was no sign of it terminating, it did:
---------------------------------------------------------------------- | Sage Version 4.7.2.alpha3, Release Date: 2011-09-28 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- ********************************************************************** * * * Warning: this is a prerelease version, and it may be unstable. * * * ********************************************************************** sage: M = ModularSymbols(Integer(4727)) sage: C=M.cuspidal_submodule() sage: dec=C.decomposition() sage: len(dec) 8
comment:4 Changed 10 years ago by
- Status changed from needs_review to needs_work
This is a nasty one: the failure seems to be non-deterministic! I ran ModularSymbols(N).cuspidal_submodule().decomposition()
in a loop from N=1 onwards, and it failed at N = 195
. I tried N = 195
again and it worked. I've had other phantom crashes for other values of N.
So this is a genuine bug, and I was too hasty in nominating it to be closed. Sadly I can't set this back to "new", although that would be the correct status for it.
comment:5 Changed 8 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:6 Changed 8 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:7 Changed 8 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:8 Changed 7 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:9 Changed 5 years ago by
- Cc kedlaya added
comment:10 Changed 4 years ago by
- Milestone changed from sage-6.4 to sage-duplicate/invalid/wontfix
- Status changed from needs_work to needs_review
I'm pretty sure this issue is now fixed; at least, I've tried running ModularSymbols(N).cuspidal_submodule().decomposition()
for the first 2000 values of N (and a selection of larger ones), taking several weeks of CPU time, and it's worked fine. The Hecke module decomposition code hasn't changed in any substantial way since the issue was reported, so my guess is that there was a bug in one of the underlying linear-algebra libraries that has now been fixed.
In an ideal world, we'd have a library of working builds of old Sage versions somewhere and we could try to pinpoint what changed to fix the bug; but since the bug was only ever occurring sporadically, that would be very laborious to do.
I nominate this ticket to be closed.
comment:11 Changed 4 years ago by
- Status changed from needs_review to positive_review
ok, let us close
comment:12 Changed 3 years ago by
- Resolution set to invalid
- Status changed from positive_review to closed
Presuming these are all correctly reviewed as either duplicate, invalid, or wontfix.
This ticket puzzles me. On my research group's Sage box (not as powerful as sage.math but less heavily loaded, thus faster in practice),
ModularSymbols(N).cuspidal_subspace().decomposition()
takes so long even forN = 500
or so that it's somehow not even conceivable that it could finish in any reasonable time forN = 4727
. I tried, and it's been running for 16 hours, and I haven't managed to reproduce the above error but nor is there any sign of it terminating!I'm tempted to suggest we close this as "worksforme" unless we can reproduce the failure; but I can't help wondering how this was initially spotted -- has there been some massive speed regression, so the computation was feasible in Sage as of 7 months back?