Mailman 3 October 2004 - SciPy-Dev

Accessible SciPy (ASP) project
by Joe Harrington Nov. 3, 2004

Nov. 3, 2004

Accessible SciPy Request for Comments #1 Joseph Harrington Perry Greenfield At SciPy '04 we had an animated Birds-of-a-Feather session about making SciPy more accessible to the general scientific user. The session and the many conversations that followed cleared up a lot of issues and myths about SciPy. Among a core group of about a dozen participants, a consensus began to emerge about what needs to be done. The purpose of this document is to lay out our understanding of that consensus for your comment (whether or not you have been involved up to now), to announce our intention to make this vision a reality, and to solicit everyone's participation and support. Many hands make light work, and many brains, properly channeled, make great work. We thus introduce the Accessible SciPy (ASP) project. Please take a moment to look at the BoF presentation, minutes, and summary at http://www.scipy.org/wikis/scipy04/ConferenceSchedule. With those documents as background, we lay out the problem, our dream, and a path to get there. THE PROBLEM Python is wonderful for doing scientific computation. Those who try it are thrilled by the freedom from arbitrary limitations, legacy syntaxes, and license managers. Some of the applications and demos are stunning. At the same time, the experience of a new user who comes to SciPy "cold" is awful. There is little in the way of instructions for installing it and running it, even to the "Hello, world!" stage, and much of that information is outdated. There is a lengthy description of the build process, which most users could never follow even if they wanted to. It is not even clear what components are in SciPy, what else is needed, and what the add-ons do. It is to the millions of such potential users (which includes every high-school science student in the world) that the current effort is directed. We need to say at this point that we are not picking on Enthought. In fact, what's on their servers works a great deal better than they advertise. One of us was able to do a "yum install SciPy" on a laptop at the conference. But, the word "yum" appears nowhere on the web site, nor does the URL for the repository. We need to take the resources being made available by Enthought and create from them the user experience SciPy needs to thrive. WHAT'S EXPECTED BY NEW USERS New users who are not "bit-heads" expect a first-time experience that goes something like this: 1. They hear about SciPy and are somehow induced to find the site and visit. 2. They see a brief front page that says what SciPy is, lists some features, and points to a page with more info. There is a reasonable number of relevant links, all clearly laid out on a page that is not too busy. Words on the front page invite them to download and try the software. 3. They click "download", and go to a friendly page that offers a binary install package for the current version of the software for their machine (and others, but they don't care about that). It also offers instructions for installing the package on their platform. For platforms like Red Hat and Debian Linux, the instructions say what lines to add to yum.conf or its Debian equivalent, though the option to download the binary package directly also exists. The instructions end with: how to configure (if necessary, hopefully not), how to test the install, where to go for help if the install failed, a pointer to a "Getting Started With SciPy" document. They follow the instructions and it installs fine. 4. They read the "Getting Started" document, which is about 20 pages and contains: a. A brief (1/2 page) description of SciPy's key characteristics from a new user's point of view b. A get-your-feet-wet tutorial, for example: make a sine wave and a parabola, add them, and plot, read some ASCII data and plot it, do a Fourier transform of the data and plot it, read an image and display it, make a second image, add it to the first, and display it, and extract an image section, manipulate it, and display it. c. The basic (non-programming) Python syntax, including array creation, access, and manipulation. d. The key elements of Python's interaction with the operating system (e.g., the most important environment variables, how to tell it where routines are stored, etc.). e. A statement on the current state of the software, that there is flux in graphics and the underlying array package, but that the functionality we teach in the docs will not (likely) go away. f. Sources of further information and support, both in the downloaded package and on the web. 5. Encouraged by the smoothness of the experience so far, the user dives right into some topical docs (for astronomy, biology, etc.), buys a book on Python (or even SciPy), subscribes to scipy-user and a topical list, downloads add-ons, and becomes productive almost immediately. OUR SOLUTION TO THE CONUNDRUM OF OPEN DEVELOPMENT SciPy both suffers and benefits from being Open Source Software. On the one hand, many developers work on it and it is quite powerful. On the other, there is no central organization, so packages can conflict, there is duplicated work, there are holes, etc. ASP proposes to provide the organization that is lacking. Through a community-driven process, we will solicit help in resolving the issues and in implementing the solutions. We will guide new users toward what the community feels are the best packages for each basic task, so that new users experience a unified software package with clear documentation. At the same time, we will continue to provide the broadest array of application software possible, and will index all the available packages and functionality so people can make informed choices if they decide the defaults are not what they need. Mainly, we will guide users through selective documentation. For example, once we select a more capable graphics package that supports all platforms, the general user documentation will teach that package rather than xplt or gplt. The latter would continue to exist, would receive whatever support their developers and fans chose to give them, and would be listed along with all the other graphics options. They would merely not be emphasized in the tutorial documentation. Thus, nobody will lose functionality or choice. It is possible that, in the future, another package may supplant one that the documentation promotes. In that case, after due deliberation, we may decide to rewrite the documents to reflect that change. Of course, such a change would be undertaken only in compelling circumstances. WHAT'S NEEDED TO GET THERE At the BoF, we identified three key areas that needed to be worked on in order to realize the experience above: packaging, the web site, and documentation. We also identified two situations, graphics and the numeric/Numarray split, that will confuse (and therefore discourage) new users until they are resolved. We will address these first, as they frame the packaging issues. SOFTWARE ISSUES On the graphics front, there are two included packages, gplt and xplt. One works best on Unix, the other on Windows. Neither is much to write home about, and all this is acknowledged. Considerable effort has gone into Chaco, but the package has not matured as fast as some had hoped, and it is still not ready (according to most). A new player, matplotlib, is gaining popularity. With the exception of contour plots, which are being actively worked on, it seems to implement the 2D plotting capability of Matlab, with both a similar user interface to Matlab and a more capable Python-like class library. It is interactive (you can click on a screen plot and adjust it in real time). It works on all platforms. The BoF consensus was to base the new documentation on matplotlib and to de-emphasize gplt and xplt by not mentioning them in the docs at all. They would remain in SciPy indefinitely. Supporters of Chaco may advocate for the selection of that package instead. Whether the community goes for this idea will depend in large part on the state of Chaco (including package documentation and maintainability by people other than the original authors) when this decision is made. On the numeric/Numarray front, it is a problem for some that Numarray performance is worse for small arrays than that of the older numeric. Other issues exist as well. Perry Greenfield is working on getting the two packages to co-exist such that which one to use can become a run-time choice of the user, and so that package maintainers can independently choose to use either one. It is hoped that ultimately Numarray will be superior to numeric in all respects, so that numeric can be deprecated and then later removed. Thus, the BoF consensus was to document the use of Numarray for interactive work. For now, Numarray and matplotlib would not be in the SciPy core. Numarray will enter the core when the coexistence issues are resolved and the developers accept it. matplotlib may enter the core when its release schedule slows down, but at this point matplotlib releases much more frequently than SciPy and there are substantial improvements with each release. If matplotlib were in the core, users would be stuck with an incomplete and beta package until the next release of SciPy, which could be many months away. PACKAGING New users generally will not build software from source code anymore. The packaging goal is thus to produce binary packages for Linux under both RPM and the Debian Package Manager, and for Mac, Windows, and Sun using their native package managers. Support for each of these (and for other platforms) depends on interested users participating and contributing good packages on a timely basis. We appreciate any help the software developers can provide in producing the packages, but we expect that most of the packaging work will be done by volunteers who specialize in this task. The BoF consensus was to distribute SciPy, Numarray, and matplotlib as separate binary packages, possibly tied together by a meta-package that contained only dependencies (for YUM and APT users). In addition, the conference was sufficiently impressed with the interactive experience offered by IPython that it would be included until it entered the SciPy core. That move was discussed positively at the conference. Optimized matrix routines may be included, or may be available as an option, depending on our ability both to produce them in a timely fashion and to provide a simple new-user experience. DOCUMENTATION Documentation is undoubtedly the area where the largest number of work hours remain to be done. It needs rewriting, or writing for the first time, at all levels visible to users. Because of this and the beta nature of some of the packages, it makes sense to focus on shorter documents that address specific tasks, rather than something like a paper book (though that might make sense two to three years from now). It is important for docs to be well-written: clear, concise, grammatical, current, complete, correct, and visible. Thus, it makes sense to coordinate this effort closely between the writers, relevant developers, and those planning the overall effort. The approach of writing shorter docs will enable participation by a larger group of writers, thus (we hope) completing the first draft of each document sooner. It will also make updates and rewrites easier. Of course, it will be important to provide good cross-references to other documents and the web site, and to keep these up to date. Needed documentss: What is SciPy? (listing of features and included packages) Installing and Testing SciPy on Red Hat Linux Debian Gnu-Linux MAC Windows Sun Getting Started with SciPy SciPy for IDL Users, with cheat sheet SciPy for Matlab Users, with cheat sheet SciPy User's Guide SciPy Reference Manual SciPy for Astronomy, Biology, Chemistry, etc. It was noted at the BoF that Enthought has substantial documentation in its Windows package in .chm format, and that there is now an X reader for these files. Those documents will be broken out for non-Windows users and may form the bases for one or more of the documents above, assuming cooperation from Enthought on permissions and copyrights. Translations are always a good idea, but can only be obtained in a community project through the work of competent volunteers. The quality of our documentation will be vastly improved by user testing and comment, and by the participation of more than one person in the creation of each document. However, content determines form, so we should not be shy about making first drafts available, provided that we continue to work on them. We will need to agree on a set of standards for writing documents. Certainly all docs should be available in PDF and HTML, and the source should be modifiable by anyone on any platform. The Windows .chm format may also be a viable target if good tools exist to do it under Linux and Mac as well as Windows. The source form must be viable in the long term and must not leave us in a bind if the text-processing software ceases to be supported. Structured Text and LaTeX have been suggested. MSWord and other proprietary forms are out. The major need for formulae in scientific documentation may push us to LaTeX, perhaps with a standardized format, but this is open for discussion. WEB SITE Probably the easiest step is improving the web site. Enthought has provided a Plone-based site, which means that updates by many contributors will be easy and many features are already there. Much of the content needs updating, and many new areas are needed. For example: - The site says that unit tests are the main need from the community. Our needs are broader, as evidenced by the BoF conclusions. - The documentation above needs to be placed on the site as it becomes available. - Pages and mailing lists are needed for topical discussions, each managed by a field representative. - The YUM archive and other download sites need to be linked to the main pages. - The utilitarian, Plone-out-of-the-box appearance should be replaced by one with more legible buttons and some lightweight graphics that make the page attractive. - A page with demos and screen shots should be added. - Pages that present and possibly rate add-on packages are needed. - Pages of user recipes and web links are needed. - A page of demos would be nice. - Throughout, it needs to be clear who is responsible for each page and how to reach that person. - Overall, the site needs to be reorganized to give new users the experience outlined above, without making it much less useful for experienced users to navigate. Essentially, scipy.org needs to become a one-stop-shopping web portal for scientific computing in Python. By providing current, complete, and accessible information in an attractive format, the web site will show potential users that this software is serious business, that it will not be difficult to learn, and that it is actively maintained by a large user community. PRIORITIES The three areas for improvement can proceed in parallel. Since packaging issues affect the documentation, those should be resolved as soon as possible. For packaging, we need to: 1. determine whether the idea of replacing xplt and gplt with matplotlib in the docs is acceptable to the community, 2. determine whether IPython should go into the core, 3. determine whether the "coexistence" approach for resolving the numeric/Numarray split is a good idea. Then, we need to roll and field-test the binary packages. The latter effort will require volunteers, so if you want your package or platform to be supported, please sign up. For documentation, we need to agree on a common source format, an open copyright, and some stylistic guidelines. Documents are needed in roughly the order listed above, though if someone is very inspired to start on a later one, he or she should proceed. Suggestions for additional documents are welcome, as are volunteers to write them. Goals for the web site are less clear than for packaging and documentation. Some mailing list brainstorming on content and format issues would be a good idea, starting with those above. Then, we need to identify page maintainers and get them access. Several individuals stepped forward at the BoF, and a web human interface designer has volunteered to help. Again, more volunteers are needed. TOPICAL SOFTWARE As a parallel effort, there is now critical mass in several disciplines for the creation of topic-specific software. For example, in astronomy, most data come in Flexible Image Transport System (FITS) format, and there is a package written by Paul Barrett that reads and writes FITS files in Python. We wish to encourage these contributions, to provide guidance for a seamless integration with the main packages, and to help new users find these resources. We can start by hosting topical mailing lists at scipy.org and by providing a variety of web resources, including package or topic home pages, lists of packages by topic, and lists of links to packages hosted elsewhere. ADVOCACY Once the basics are in place, we can start advocating SciPy to the broader scientific community. With luck and a little effort, this should expand the group of contributors so that the remaining work can be done more quickly. Suggestions from the BoF included a conference kit so that someone can set up a booth that advocates SciPy simply by printing some posters and handouts and setting up a computer. Others included lunchtime talks in departments, killer demos, comparison web pages, and the best advocacy of all, being a good example to peers. The BoF identified the need for a user survey. Individuals can best judge when and to whom they advocate SciPy. However, it would make sense to coordinate any major presentations with the SciPy community, to ensure good synchronization with new releases, web site work, etc. CONCLUSION SciPy is a community project, and the community should coordinate and review what goes into SciPy. In that vein, this document is a genuine request for your comments, and we will hope to maintain this format in the future so that all voices can be heard. If you are willing to work on any part of this effort, please make your intentions known by adding your name and email (spam-obscured, if you like) to the ASP Wiki at http://www.scipy.org/wikis/accessible_scipy/. Since this is a community project, please be prepared to accept edits, corrections, and updates from the community, and to ask for help or to hand off your work to someone else when you are no longer able or willing to maintain it at the level or rate that is needed. The vision above is a large one. However, none of the steps is particularly large. Many projects can proceed in parallel and we gain from the completion of each task. Discussion will continue, for now, on the scipy-dev(a)scipy.org mailing list, with major announcements copied to scipy-user. If this topic comes to dominate the list, it may be split off into its own list, but for now we want to keep all those working on SciPy apprised of our efforts. We invite you to join us in making SciPy the environment of choice for technical computation, starting with your comments on the plan outlined above. --jh--

11 43

Testing for powers of two
by Charles Harris Oct. 29, 2004

Oct. 29, 2004

There was a discussion some time ago about testing for powers of two. The other day I saw a nifty version go by on the LKML, courtesy of Linus. Namely: is_power_of_two = x && !(x & (x - 1)) which works for all numbers except possibly the number x8000, which if twos complement will probably give an underflow on subtraction of 1. So for signed numbers: is_power_of_two = x > 0 && !(x & (x - 1)) Chuck

1 0

ASP: comments on the web site
by Joe Harrington Oct. 28, 2004

Oct. 28, 2004

Things have been quiet since we posted the ASP RFC, at least on the concerns it raised. It really is a request for your comments, and not just a private plan of Perry's and mine. Success in this area will require everyone's participation, even if it's just evaluating what others have done or said and expressing your opinions on this list. All we're asking for at this point is for you to read the RFC, make some comments in email, and help populate some wiki pages with links and concerns. If you're willing to do real work later, we're also asking for you to sign up in the area you can work in. So far only one discipline (astronomy) has posted a page of links on the "Topical Software" wiki. Subsequent to posting his page, Russell Owen offered a critique of the web site, which we identified in the ASP RFC as needing a makeover. He's not on this list but hee allowed me to post his comments here. Please chime in and respond with your own ideas of how to make the web site better, both to serve your needs and to serve those of potential new users. Finally, would someone from biology and from graphics please step up to maintain similar pages for those areas? We need someone from *every* field, but I know there's lots of good application software in both those areas. Maintaining a wiki or a regular page takes only a small amount of time, an hour a month or less once the page is up, but it's a crucial step in attracting a broader user base. Thanks! --jh-- ------- Start of forwarded message ------- In-Reply-To: <006301c4bba0$8c284f70$9c01a8c0@SWISHER> Date: Wed, 27 Oct 2004 14:48:16 -0700 To: "Janet Swisher" <swisher(a)enthought.com>, "'Russell E Owen'" <rowen(a)u.washington.edu> From: Russell E Owen <rowen(a)u.washington.edu> Subject: RE: Help with SciPy.org Wikis Cc: <joneric(a)enthought.com>, <jh(a)oobleck.astro.cornell.edu> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on oobleck.astro.cornell.edu X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=3.9 tests=BAYES_00 autolearn=ham version=2.63 At 4:12 PM -0500 2004-10-26, Janet Swisher wrote: >> On the edit tab for a wiki page, a set of options near the bottom >> determines which format the wiki uses to interpret the page. If you >> edit an existing page, notice which format it is in. >> " >> >> So..."notice which format it is in". Sounds good, but HOW? > >What I had in mind is that, when you edit a page, you can note which of the >format radio buttons is selected. I guess I need to make that more explicit. > >> Better yet, how to change it? > >You can change the selected radio button, but that does not change the >contents of the page. If you want to change a page, for example, from ST to >RST, you would have to make the formatting changes manually. >... >When you click the Edit tab, the contents of the page are full of HTML tags, >and the HTML radio button is selected. OK, I tried with Safari as well and I see no radio buttons, so I think they really and truly are missing (or I am being spectacularly blind). I suspect one needs more god-like privileges than I have to see them, perhaps because if a user can see them, a user can toggle them. (If so, not allowing just anybody to change how a page is parsed is certainly reasonable). In any case, this is a problem because every editor should be able to clearly see what format a page is in. >> Request: >> - Permanent links to "Topical Software" and "Help with SciPy.org >> Wikis" would be a big win. Right now they are only visible because >> they are new enough to appear in "recent items". > >"Topical Software" is permanently listed in the navigation tree under >"Wikis". The user does have to know to click "Wikis" to see it. "Help with >SciPy.org Wikis" is now linked from the root page of the Wikis folder and >from the root page of the published wikis (except the one for the SciPy 2004 >Conference, which is now mainly historical). > >Do you have suggestions about where else these items could be linked that >would be more visible? Since you ask, here are my impressions and suggestions. First the impressions: - - From the SciPy home page, there is no clue that this site has any general "science with Python" information. It just seems to be a site about the SciPy software project. - - One has to first go to "Other Wikis" and then look way down through a page that is mostly about SciPy to find "Topical Software". - - "Topical Software" is not evocative. - - Burying it so deeply and not mentioning it on the home page give the impression that it is very much an afterthoght and not integrated into the site. Suggestions: - - Rename "Topcial Software" to something like "Python Tools for Science". - - Explicitly mention "Python Tools for Science" in the text on the home page. Try to briefly explain that it exists and perhaps WHY it exists. Just a sentence or two should do it. *Talking* about it and not just Further cleanups to consider: - - Consolidate some of the items in Navigation. - - Get rid of "Wikis" and those pages to other, more obvious, sub-headings. - - SciPy should be a recognized link on every scipy wiki (to the SciPy home page). The navigation bar might look like this (with changes noted under each topic): Navigation: About SciPy - - no change (except as mentioned for the body text above) Documentation: - - includes "Wikis" links: "Troubleshooting", "SciPy User's Guide Wiki" and "Help with SciPy.org Wikis" this is touchy and may not fully work because I realize you have non-wiki versions of the docs as well, but I have seen success with offering users both versions side-by-side (let them choose if they want docs cluttered up with user comments or not) Development: - - include CVS and get rid of the CVS link (i.e. bury the CVS page one level deeper) Bug Tracker: - - include the standard navigation panel that we are discussing Mailing Lists - - no change Science with Python - - This is the "Topical Software" page, renamed and brought up one level Anyway, there are my 2 bits, such as they are. Best of luck with the site and the project. - -- Russell P.S. Regarding the gaps I was seeing before every link; it turned out that enabling background images displayed the icons. If those really are background images I am truly amazed, but however it's being done seems to work (except for leaving gaps when one doesn't want to see images). ------- End of forwarded message -------

5 4

scipy_test/testing.py: assert_approx_equal -- array version (patch)
by krivilli＠unberwoot.net Oct. 23, 2004

Oct. 23, 2004

HI, -I'm using scipy_test/testing.py as a 1st try to add tests units into my scripts and reuse some of it in scipy.optimize. -When dealing with something like optimize.leastsq, I needed to compare its resulted array (i.e. optimize.leastsq(...)[0]) against its accuracy. I didn't find anything I could use for this matter in 'testing.py'. I was looking for a n-dimensional (n>1) version of assert_approx_equal. So I wrote one (in fact, i just extented 'assert_approx_equal' for n-arrays); I'm not sure if there is similar code lying around somewhere in scipy_test. -Bellow goes the patch against testing.py (cvs): *** testing.py 2004-10-06 20:03:34.000000000 -0300 --- testing.py 2004-10-23 02:06:34.000000000 -0300 *************** *** 10,16 **** # If Numeric and scipy_base are not available, then some of the # functions below will not be available. from Numeric import alltrue,equal,shape,ravel,around,zeros,Float64,asarray,\ ! less_equal,array2string,less import scipy_base.fastumath as math except ImportError: pass --- 10,16 ---- # If Numeric and scipy_base are not available, then some of the # functions below will not be available. from Numeric import alltrue,equal,shape,ravel,around,zeros,Float64,asarray,\ ! less_equal,array2string,less,floor,fabs,log10,Float import scipy_base.fastumath as math except ImportError: pass *************** *** 689,694 **** --- 689,735 ---- print x, y raise ValueError, 'arrays are not almost equal' + __all__.append('assert_array_approx_equal') + def assert_array_approx_equal(x,y,significant=7,err_msg=''): + x, y = asarray((x, y),Float) + msg = '\nItems are not equal to %d significant digits:\n' % significant + msg += err_msg + + try: + cond = alltrue(equal(shape(x),shape(y))) + if not cond: + msg = msg + ' (shapes mismatch):\n\t'\ + 'Shape of array 1: %s\n\tShape of array 2: %s' % (shape(x),shape(y)) + assert cond, msg + '\n\t' + err_msg + + # Normalized the numbers to be in range (-10.0,10.0) + scale = pow(10,floor(log10(0.5*(abs(x)+abs(y))))) + try: + sc_x = x/scale + except ZeroDivisionError: + sc_x = zeros(shape(x)) + try: + sc_y = y/scale + except ZeroDivisionError: + sc_y = zeros(shape(y)) + + reduced = fabs(sc_x - sc_y) <= pow(10.,-1*significant) + cond = alltrue(reduced) + if not cond: + s1 = array2string(x,precision=significant+1) + s2 = array2string(y,precision=significant+1) + if len(s1)>120: s1 = s1[:120] + '...' + if len(s2)>120: s2 = s2[:120] + '...' + match = 100-100.0*reduced.tolist().count(1)/len(reduced) + msg = msg + ' (mismatch %s%%):\n\tArray 1: %s\n\tArray 2: %s' % (match,s1,s2) + assert cond,\ + msg + '\n\t' + err_msg + except ValueError: + print sys.exc_value + print shape(x),shape(y) + print x, y + raise ValueError, 'arrays are not approximately equal' + __all__.append('assert_array_less') def assert_array_less(x,y,err_msg=''): x,y = asarray(x), asarray(y) regards, -- roberto (krivilli)

1 0

Re: [Fwd: Scipy topical software wiki]
by Paul Barrett Oct. 22, 2004

Oct. 22, 2004

Russell and I could use some help with the following problems and I thought that these issues my be useful to a wider audience. -- Paul This page: http://www.scipy.org/wikis/topical_software/DirectoryOfSciPyTopicalPages does not exist but a search turned up the AstroPy page. I have corrected the mailing list info and made a few minor edits, but there are several I'd like to see resolved before making this the official AstroPy page: * Cosmetic glitches: - Many words have question marks after them. Based on my limited wiki experience and some testing, it seems that the wiki *THINKS* these words *SHOULD* be links to other pages, and is "helpfully" generating "you could add a page here" links. How do I stop this? (Sigh. I thought only Microsoft went in for this level of fake pseudo-helpful intelligence.) - All my html links have too much space before them. How can I fix this? * Documentation (which would probably allow me to fix the first two): The SciPy wiki site seems to be missing documentation on the format used for SciPy wiki pages. Thus not only am I flying blind, but anyone else who edits this page will also be doing so. That gives me the heebie-jeebies.

2 1

Problems building SciPy with Visual Studio 7.0 (.NET)
by Travis Oliphant Oct. 22, 2004

Oct. 22, 2004

I have colleagues who are struggling to build scipy using the Visual Studio 7.0 (.NET) compiler Does anybody know if there are problems building scipy with this compiler? Thanks, -Travis

3 2

SciPy Topical Pages wiki
by Joe Harrington Oct. 21, 2004

Oct. 21, 2004

Topical or domain-specific pages were a need identified at the SciPy '04 conference. Several of these exist, some with their own mailing lists. I have just created a wiki page to index such pages, so that scipy.org can become a portal where users can go to locate any software that runs under or with SciPy. The URL is: http://www.scipy.org/wikis/topical_software/DirectoryOfSciPyTopicalPages (next time I ask for a wiki, I'll suggest a shorter name...) What's needed now is for people who maintain such pages to link to them from the wiki, with just a few words to help users find their way. Please list them alphabetically by the most obvious topic name. Initially, I'm sure there will be some reshuffling. Maybe the 3D page I proposed will become a graphics page, for example. Likely some areas have two competing pages at the moment. The few pages that exist already are not currently hosted on scipy.org. We'll work through all that. For now, please link any topical pages from the wiki. If you have items to list on a topical page, hold out for a few days and see if an appropriate page shows up. If not, either volunteer to manage it or ask here on scipy-dev for someone else to host it. Please do not list pages for individual packages on the Topical wiki. Ideally, the topical pages will eventually be hosted on SciPy.org. That way, if someone loses interest or moves institutions, the page is still there for everyone and a new maintainer can be found. It also includes the content of those pages in the scipy.org search engine. So, I encourage page maintainers to follow the instructions on the wiki and move their pages to scipy.org. If you prefer to have a different format for your page, such as a plain web page in the scipy.org site or a wiki, please bring that up here or ask the scipy.org web team. At some point we'll have guidelines for what format is best. Experience will tell. Ok, have at it! --jh--

4 3

xplt issues
by Arnd Baecker Oct. 21, 2004

Oct. 21, 2004

Hi, As already discussed some time ago on the scipy-user mailing list we have compiled a list of issues/bugs/wishes concerning scipy.xplt. The notes below are written in Restructured text and the html version (+example files) can be found at http://www.physik.tu-dresden.de/~baecker/tmp/xplt/xplt_issues.html Best, Jan Braun and Arnd Baecker ############################ .. -*- mode: rst -*- =========== Xplt issues =========== Remark ahead ============ As already discussed some time ago on this mailing list we have compiled a list of issues/bugs/wishes concerning xplt. This text is written in Restructured text (`ReSt <http://docutils.sourceforge.net/rst.html>`_ and the html version can be found at `xplt_issues.html <http://www.physik.tu-dresden.de/~baecker/tmp/xplt/xplt_issues.html>`_). This text is structured in three parts: 1. Differences between Windows/Linux 2. Platform independent problems 3. A wishlist for improvements of the present behavior .. contents:: PART I, PORTING PROBLEMS ======================== Plotting one point ------------------ Plotting one point using xplt.plg() leads to differing results under Windows/Linux depending on the method used: 1. using plg with 1-element arrays: this works fine under Windows, where xplt/gist plots a single point at the specified position. Under Linux no point is obtained (if one uses standard parameters for plg) and you won't see any graphical output. 2. To get xplt/Linux plotting a single point you need to plot a line from the point to itself. Alternatively, one can disable the plotting of lines and change the marker. Try the example `plot_single_points.py <plot_single_points.py>`_ on Windows and Linux to see this. :: from scipy.xplt import * x=0.5 y=1.0 window() pldefault(marks=0) # plotting a line from/to the same point plg(x*ones(2),y*ones(2),type="dot",marks=0,msize=5) # plotting a single point plg([1],[1],marks=0,type=0,marker=1,msize=5) Pause() and Windows ------------------- The pause() command does not work under Windows. This code :: from scipy.xplt import pause for x in arange(40): print x pause( 100 ) should print the numbers from 0 to 39 but will stop right after printing 0 if started under windows. Example: `pause_windows.py <pause_windows.py>`_. Undefined background colors --------------------------- It seems that the background color of plots depends on the window manager. So some people happily plot white symbols on their grey background, whereas with a different window manager one can end up with white symbols on a white background. It would be a good to force a default background color in the plotting template. PART II, GENERAL PLOTTING ISSUES ================================ Labeling and titles ------------------- Without defined limits() the labels given with x-/ylabel are lost with every scale change. Using limits() preserves the scale and labels. It even brings back labels, that were lost after a rescale. Titles however, are only lost by using fma(). (Applies to titles defined by pl-/title.) :: from scipy.xplt import * window( wait=1 ) xlabel( "xlabel" ) # creates the xlabel x=arange( 100 ) plg( x, x ) # destroys the label limits( 0, 75, 0, 75 ) # label reappears plg( x, x ) # label is preserved by limits fma() plg( x, 0.5*x ) # labels are lost now # although the limits are preserved # a new call to limits() won't bring it back xlabel( "xlabel" ) # recreating label till next fma() plg( x, x ) # labels preserved by old limits It is not possible to get around multiple label/title definitions even using limits(). It would be useful to have these commands installing labels and titles as permanent as the limits used. Example: `labeling.py <labeling.py>`_. Missing axes in empty Windows and corrupted mouse input (animate,fma) --------------------------------------------------------------------- By default xplt knows two coordinate systems for mouse input. By setting limits() or plotting into a window the default coordinate system is specified by the visible part of the axes. In interactive simulations it is often necessary that a user selects coordinates using the mouse. All this works fine most of the time, however, problems occur using the animate() mode or in new windows. Switching buffers with fma() lets xplt loose the frame of reference for mouse input. In fact you will get some coordinates between zero and one. If you don't want to use normalized device coordinates you have to plot after the fma() or use the axes() command. Supplying limits wont help. animate() mode even has another interesting behavior in conjunction with the mouse() command. If you advance a frame, take mouse input and draw _one_ graph, the axes are adjusted to the full length, but only a part of the graph is shown. :: from scipy.xplt import * window( wait=1 ) x=arange( 100 ) animate( 1 ) plg( .5*x,x) fma() m=mouse( -1, 1 ) # mouse input print "used c. system: ", m[8] print " position of mouse: ( ", m[3], ", ", m[4], ")" plg( .5*x,x) fma() # only part of the plot is shown # wont occur if more than one graph is plotted m=mouse(-1,1) print "used c. system: ", m[8] # uses "wrong" coordinate system "0" print " position of mouse: ( ", m[3], ", ", m[4], ")" plg(x,x) # we need to plot something __without__ # advancing a frame (no visible change) m=mouse(-1,1) print "used c. system: ", m[8] # now we get the correct c. system "1" print " position of mouse: ( ", m[3], ", ", m[4], ")" This example is available as `mouse_coords.py <mouse_coords.py>`_. Plot symbols ------------ The symbols are not properly centered to the point they correspond to. This seems to be just a vertical problem. :: x=arange(0.0,1.01,0.5) plg(x*x,x,marker=2,type=0,msize=4,color="red") plg(x*x,x,marker=1,type=0,msize=4) plg(x*x,x,marker=3,type=0,msize=4,color="green") plg(x*x,x,marker=4,type=0,msize=4,) The different colors are just for illustration and the effect is not size-dependent, for an example see `centered_plot_symbols.py <centered_plot_symbols.py>`_. Memory errors with arrays ------------------------- :: x=arange(0.0,1.0,0.1) y=2 plg(y,2) This code results in the misleading message (??) :: MemoryError Especially beginners have difficulties to correct the code. A more helpful error message would be better as it should be easy to check that the arrays are real and of the same length. Even floats (not arrays) should be allowed as input, IM-HO. Fast repeated mouse events -------------------------- Fast clicking on plot windows results in zoom/unzoom events even if mouse input is desired. This may lead to the impossibility to restore the original viewport. While it is possible to disable zoom with zoom_factor( 1 ), it would be helpful to deactivate the movement of the viewport, PART III, Wishlist items ======================== Arbitrary size windows under X ------------------------------- The only possibility to influence the size of windows is the dpi parameter, which lets one choose between 75 and 100 dpi. It would be nice to define different window-sizes for display. Positioning of windows (x-geometry) ----------------------------------- In addition to the preceeding point it would be nice to define a window-position. At the moment you have to rely on the window manager facilities, so you can't assure useful positions of multiple plot windows. Several windows and Mouse-clicks -------------------------------- :: from scipy.xplt import * x=arange( 0.0, 1.0, 0.1 ) window( 0 ) plg( x, x ) window( 1 ) plg( x*x, x ) while 1: m=mouse( 1, 1, "Click with the mouse, finish with right-click" ) if m[9]==3: break Clicking in window 0 one gets the last coordinates clicked in window 1, but no meaningful answer. Would it be possible to - return the correct click-coordinates regardless of the "active" window - add mouse[11] as return parameter which contains the window number in which the user clicked - supply a non-blocking function to report waiting mouse events Minor ----- Under X11: - xlabel too close to the graph - ylabel too close to the left border

1 0

scipy-0.3.2 and gnuplot install
by Brett G. Olivier Oct. 14, 2004

Oct. 14, 2004

Hi I just noticed that neither SciPy_complete-0.3.2.zip nor SciPy_complete-0.3.2.tar.gz contain wgnuplot.exe and gnuplot_helper.exe in /lib/gplt which causes installation under windows to fail. Best regards Brett

1 0

Bug tracker
by Nils Wagner Oct. 14, 2004

Oct. 14, 2004

Hi all, Many of the entries in the bug tracker are outdated. Is it possible to remove obsolete messages ? Where can I place a wishlist for new features (e.g. Rank-revealing QR,...) Any comment ? Nils

2 3