Differences between revisions 5 and 6
Revision 5 as of 2009-01-24 23:08:37
Size: 3236
Editor: TomBoothby
Comment:
Revision 6 as of 2009-01-24 23:08:58
Size: 3797
Editor: TomBoothby
Comment:
Deletions are marked like this. Additions are marked like this.
Line 17: Line 17:

---- /!\ '''Edit conflict - other version:''' ----
Line 18: Line 20:

---- /!\ '''Edit conflict - your version:''' ----
 1. (ish) #5079 Problems in preparsing number literals. While I'm not directly responsible for fixing this, I did a lot of research into it before punting to Robert Bradshaw. So, I was able to help him and guide him around various pitfalls, as well as find subtle bugs & workarounds in his implementation. Also, I suggested pre-emptive compatibility with py3k literals, which Robert liked and implemented.

---- /!\ '''End of edit conflict''' ----

Overall

This has probably been my most productive Sage Days ever. About 80% of my time awake was used reading / writing / reviewing code that ended up being useful. I'd say that about 10% of my time was spent working on code was not useful, and the remaining 10% was spent eating, walking, and insulting Dan Shumow.

Bugs Fixed

  1. #4440 Automatic Indentation: the notebook now handles Python indentation like a "real IDE". For the record, nano, my favorite development environment, can do this too.
  2. #3056 Disabled Karatsuba polynomial multiplication for inexact rings. This changed a few doctests; in all but one case, the results were more accurate or simpler if symbolic. The one remaining case isn't clear-cut.
  3. #3999 Added doctests to MultiplicativeWrapper. Not all of them work, mostly due to bugs and methods which have not been implemented. So, Dan didn't like that and gave it a "needs work". I insulted him for this.

  4. #5061 Steenrod algebras incorrectly reported the additive order for the zero element. I discovered this working on #3999. Forgot to add a doctest for this, so Robert Bradshaw marked it "needs work".
  5. #5064 Steenrod algebras were non-unique. Discovered working on #3999, and fixed this. However, it's not done -- unpickling will result in non-unique algebras.


/!\ Edit conflict - other version:


  • 1.(ish) #5079 Problems in preparsing number literals. While I'm not directly responsible for fixing this, I did a lot of research into it before punting to Robert Bradshaw. So, I was able to help him and guide him around various pitfalls, as well as find subtle bugs & workarounds in his implementation. Also, I suggested pre-emptive compatibility with py3k literals, which Robert liked and implemented.


/!\ Edit conflict - your version:


  1. (ish) #5079 Problems in preparsing number literals. While I'm not directly responsible for fixing this, I did a lot of research into it before punting to Robert Bradshaw. So, I was able to help him and guide him around various pitfalls, as well as find subtle bugs & workarounds in his implementation. Also, I suggested pre-emptive compatibility with py3k literals, which Robert liked and implemented.


/!\ End of edit conflict


Bugs Reviewed

Thanks to the San Diego Airport free wifi, I'm typing this while I wait for my flight.

  1. #5058 fixes a bug in sage -f and sage -f; when the .spkg path has an extra .spkg in it.
  2. #4048 implements minpoly for GF(p)
  3. #2638 fixes recursion limit problems with QQbar.exactify()
  4. #5073 updates iPython to 0.9.1
  5. #4271 indefinite integration for piecewise functions. I expected to learn something about the calculus stuff.... but didn't work up the motivation in the end. I checked doctests, and suggested that somebody more familiar with the code review it as well -- wdj chipped in, and it looks like it still needs some work.
  6. #5052 preparser doesn't respect indentation before "load". This was fixed.
  7. #5025 fixes tinymce issues. This seems to have introduced a serious bug, so I gave it a "needs work". In retrospect, I really wish I'd reviewed this before Jason fell asleep on the chair in the lobby to prepare for his 6:00 AM flight. We could have gotten it resolved, otherwise. It's probably an issue with the patch.
  8. #3658 Pari bug results in unreliable prime_pi. It seems that Pari reports that the number of primes < n is at most the number of primes Pari currently knows about. If Pari pre-computed all primes, that'd probably be a good way of doing things. But they don't for some reason. We should submit a patch to precompute all primes upstream to the Pari group. They'd love us forever.

days12/statusreports/tomboothby (last edited 2009-01-24 23:19:06 by TomBoothby)