It might be nice to turn the matrix class into a short class hierarchy, something like this:
class MatrixBase class DenseMatrix(MatrixBase) class TriangularMatrix(MatrixBase) # Maybe a few variations of upper/lower triangular and whether the diagonal is stored class SymmetricMatrix(MatrixBase) These other matrix classes could use packed storage, and could call the specific optimized BLAS/LAPACK functions to get higher performance when it is known the matrix is triangular or symmetric. I'm not sure whether this affects the discussion of the matrix * and \ operators, but it's a possibility to consider. -Mark On Mon, Feb 13, 2012 at 4:53 PM, Aaron Meurer <asmeu...@gmail.com> wrote: > I'd like the ability to make "in" (i.e., __contains__) return > something other than a bool. > > Also, the ability to make the x < y < z syntax would be useful. It's > been suggested that the ability to override the boolean operators > (and, or, not) would be the way to do this (pep 335), though I'm not > 100% convinced that's the way to go. > > Aaron Meurer > > On Mon, Feb 13, 2012 at 2:55 PM, Fernando Perez <fperez....@gmail.com> > wrote: > > Hi folks, > > > > [ I'm broadcasting this widely for maximum reach, but I'd appreciate > > it if replies can be kept to the *numpy* list, which is sort of the > > 'base' list for scientific/numerical work. It will make it much > > easier to organize a coherent set of notes later on. Apology if > > you're subscribed to all and get it 10 times. ] > > > > As part of the PyData workshop (http://pydataworkshop.eventbrite.com) > > to be held March 2 and 3 at the Mountain View Google offices, we have > > scheduled a session for an open discussion with Guido van Rossum and > > hopefully as many core python-dev members who can make it. We wanted > > to seize the combined opportunity of the PyData workshop bringing a > > number of 'scipy people' to Google with the timeline for Python 3.3, > > the first release after the Python language moratorium, being within > > sight: http://www.python.org/dev/peps/pep-0398. > > > > While a number of scientific Python packages are already available for > > Python 3 (either in released form or in their master git branches), > > it's fair to say that there hasn't been a major transition of the > > scientific community to Python3. Since there is no more development > > being done on the Python2 series, eventually we will all want to find > > ways to make this transition, and we think that this is an excellent > > time to engage the core python development team and consider ideas > > that would make Python3 generally a more appealing language for > > scientific work. Guido has made it clear that he doesn't speak for > > the day-to-day development of Python anymore, so we all should be > > aware that any ideas that come out of this panel will still need to be > > discussed with python-dev itself via standard mechanisms before > > anything is implemented. Nonetheless, the opportunity for a solid > > face-to-face dialog for brainstorming was too good to pass up. > > > > The purpose of this email is then to solicit, from all of our > > community, ideas for this discussion. In a week or so we'll need to > > summarize the main points brought up here and make a more concrete > > agenda out of it; I will also post a summary of the meeting afterwards > > here. > > > > Anything is a valid topic, some points just to get the conversation > started: > > > > - Extra operators/PEP 225. Here's a summary from the last time we > > went over this, years ago at Scipy 2008: > > > http://mail.scipy.org/pipermail/numpy-discussion/2008-October/038234.html, > > and the current status of the document we wrote about it is here: > > > file:///home/fperez/www/site/_build/html/py4science/numpy-pep225/numpy-pep225.html. > > > > - Improved syntax/support for rationals or decimal literals? While > > Python now has both decimals > > (http://docs.python.org/library/decimal.html) and rationals > > (http://docs.python.org/library/fractions.html), they're quite clunky > > to use because they require full constructor calls. Guido has > > mentioned in previous discussions toying with ideas about support for > > different kinds of numeric literals... > > > > - Using the numpy docstring standard python-wide, and thus having > > python improve the pathetic state of the stdlib's docstrings? This is > > an area where our community is light years ahead of the standard > > library, but we'd all benefit from Python itself improving on this > > front. I'm toying with the idea of giving a lighting talk at PyConn > > about this, comparing the great, robust culture and tools of good > > docstrings across the Scipy ecosystem with the sad, sad state of > > docstrings in the stdlib. It might spur some movement on that front > > from the stdlib authors, esp. if the core python-dev team realizes the > > value and benefit it can bring (at relatively low cost, given how most > > of the information does exist, it's just in the wrong places). But > > more importantly for us, if there was truly a universal standard for > > high-quality docstrings across Python projects, building good > > documentation/help machinery would be a lot easier, as we'd know what > > to expect and search for (such as rendering them nicely in the ipython > > notebook, providing high-quality cross-project help search, etc). > > > > - Literal syntax for arrays? Sage has been floating a discussion > > about a literal matrix syntax > > (https://groups.google.com/forum/#!topic/sage-devel/mzwepqZBHnA). For > > something like this to go into python in any meaningful way there > > would have to be core multidimensional arrays in the language, but > > perhaps it's time to think about a piece of the numpy array itself > > into Python? This is one of the more 'out there' ideas, but after > > all, that's the point of a discussion like this, especially > > considering we'll have both Travis and Guido in one room. > > > > - Other syntactic sugar? Sage has "a..b" <=> range(a, b+1), which I > > actually think is both nice and useful... There's also the question > > of allowing "a:b:c" notation outside of [], which has come up a few > > times in conversation over the last few years. Others? > > > > - The packaging quagmire? This continues to be a problem, though > > python3 does have new improvements to distutils. I'm not really up to > > speed on the situation, to be frank. If we want to bring this up, > > someone will have to provide a solid reference or volunteer to do it > > in person. > > > > - etc... > > > > I'm putting the above just to *start* the discussion, but the real > > point is for the rest of the community to contribute ideas, so don't > > be shy. > > > > Final note: while I am here commiting to organizing and presenting > > this at the discussion with Guido (as well as contacting python-dev), > > I would greatly appreciate help with the task of summarizing this > > prior to the meeting as I'm pretty badly swamped in the run-in to > > pydata/pycon. So if anyone is willing to help draft the summary as > > the date draws closer (we can put it up on a github wiki, gist, > > whatever), I will be very grateful. I'm sure it will be better than > > what I'll otherwise do the last night at 2am :) > > > > Cheers, > > > > f > > > > ps - to the obvious question about webcasting the discussion live for > > remote participation: yes, we looked into it already; no, > > unfortunately it appears it won't be possible. We'll try to at least > > have the audio recorded (and possibly video) for posting later on. > > > > pps- if you are close to Mountain View and are interested in attending > > this panel in person, drop me a line at fernando.pe...@berkeley.edu. > > We have a few spots available *for this discussion only* on top of the > > pydata regular attendance (which is long closed, I'm afraid). But > > we'll need to provide Google with a list of those attendees in > > advance. Please indicate if you are a core python committer in your > > email, as we'll give priority for this overflow pool to core python > > developers (but will otherwise accommodate as many people as Google > > lets us). > > _______________________________________________ > > IPython-dev mailing list > > ipython-...@scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
