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.. 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. (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. (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. (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. 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
