On Tue, Feb 8, 2011 at 9:02 PM, D. S. McNeil <dsm...@gmail.com> wrote: > Hello! > > First time poster, so brief introduction: planetary astronomer, been > using Sage for years for both science and fun. I'm also one of the > Editors-in-Chief of the OEIS, and have been experimenting with using > Sage for bulk sequence processing and verification. I find writing in > Sage very competitive, but there are a handful of things I'd like to > fix. > > For one behaviour which startled me, I thought I followed the right > procedure: asked why it was done that way on IRC, then filed a bug > report on trac. I found the current behaviour irritating enough to > consider posting to sage-devel to complain, but one page recommended > against shouting here as a way of drawing attention to your pet bug, > so I figured before I suggest work for others it's important to show > I'm willing to do some myself. Accordingly I've spent time answering > questions on ask.sagemath.org and worked my way up to fourth, just > passing was. I don't think I'll be catching those above me (hi @niles, > @kcrisman!), as I keep having to vote them up..
Dang, I need to post to http://ask.sagemath.org more! > > Anyway, now it's time to start burning that karma. :^) > > > The easiest to fix of my pet peeves, each of which I'm willing to > submit patches for if there's someone willing to help navigate. > > (1) gcd is broken. http://trac.sagemath.org/sage_trac/ticket/10459 > > gcd(2/1,4) returns 1 "for simplicity" (!), because 2/1 is a rational. > This is shockingly silly. It's especially so given the existence of > both .content and lcm! I could almost understand raising an > exception, but there's no reason not to use something which reduces to > the integer case. (Using // isn't a good option for me, because that > means surrendering a great sanity check for sequences which should be > made up of integers but aren't.) There's a pending request to > implement a more general gcd, but that's a different problem: I just > want the common case of rationals to do something sensible, and it > could be done in just a few lines given the existing code. I'm personally OK either way with this. > > (2) No kwarg constraints in Partitions/Compositions should be mutually > exclusive. (I think there's a ticket for this but I can't find it > now.) > > Partitions(15,length=5, parts_in=[1,3,4]) doesn't work, so you have to > do an explicit filter. Optimizing it is a separate issue, but when > there's a trivial way to implement the functionality (simply test that > partitions satisfy the specified criteria before yielding them, in > cases where we don't currently embed the constraints in the > construction process itself), then ISTM we should do so now rather > than wait for a more efficient implementation to appear. > Functionality+speed > functionality, but functionality >>> no > functionality. > > Currently, partitions_restricted's docstring says not to use it but to > use RestrictedPartitions instead, which in turn says not to use > RestrictedPartitions but to use Partitions with the "parts_in" > keyword, which in its turn doesn't work. You should probably email the sage-combinat list about this: http://groups.google.com/group/sage-combinat-devel/ > > (3) primes(10, infinity) should work. > > Since we're just calling next_prime, there's no reason to require the > upper limit to be an integer. This bites me more than you'd think, > because lots of (often uninteresting, but very error-prone) OEIS > sequences are of the form "function-of (next prime > x s.t. > something-or-other)" and I like functional programming styles. > Wouldn't mind a proof=False option which calls next_probable_prime > instead, either. +1 to both suggestions. I don't see any reason for somebody not to implement both of these. Great suggestions. > (4) Probably this has already been discussed to death and presumably > vetoed for sound reasons, but I don't see the point of complaining > about whitespace issues at the end of a program after every > non-whitespace character when Python doesn't. I don't remember any discussion about this at all. It sounds like you might have found a bug in the preparser. Could you post an example to nail down exactly what you're talking about? -- William > > > Doug > > -- > Department of Earth Sciences > University of Hong Kong > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
