[Numpy-discussion] Benchmarking code
There's a function (_test_unique1d_speed) in numpy/lib/arraysetops.py that looks to me like it should be in a benchmark suite instead of in the library module. Would anyone mind if I moved it to numpy/lib/benchmarks? ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Representation of array subclasses
Hi all, I noticed that subclasses are not represented correctly: In [8]: np.chararray([1, 2, 3]) Out[8]: chararray([[['\x03', '', ''], ['\xc0', '\x03', '']]], dtype='|S1') Notice how the indentation of the second row is completely wrong. I tried to fix this in array_repr_builtin (arrayobject.c:4318), but the fix had no impact. `array_repr_builtin` is not called unless preceded by np.set_string_function(None, repr=1) Does anybody know where the right place is to fix the representation? Thanks Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Benchmarking code
2008/7/23 Alan McIntyre [EMAIL PROTECTED]: There's a function (_test_unique1d_speed) in numpy/lib/arraysetops.py that looks to me like it should be in a benchmark suite instead of in the library module. Would anyone mind if I moved it to numpy/lib/benchmarks? No, please go ahead. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Schedule for 1.2.0
I think we should stick to what has been agreed and announced months ago. It's called honouring our commitments and the project's image depends on it. If the inconvenience of these API changes is worth the trouble, a 1.1.2 release could be considered. My two cents. David 2008/7/22 Joe Harrington [EMAIL PROTECTED]: Hi Jarrod, I'm just catching up on my numpy lists and I caught this; sorry for the late reply! Another issue that we should address is whether it is OK to postpone the planned API changes to histogram and median. A couple of people have mentioned to me that they would like to delay the API changes to 1.3, which seems reasonable to me. If anyone would prefer that we make the planned API changes for histogram and median in 1.2, please speak now. I *strongly* want both these changes for 1.2, as I am sure do the many people teaching courses using numpy for the fall. It is hard to get students to understand why there are inconsistencies and irrationalities in software, and it's even worse when it's open-source, since somehow it's the lecturer's fault that he picked a package that isn't right in some major way. Worse, we're changing these behaviors like 6 months from now, so students will have to learn it wrong and code it wrong, and then their code may break on top of it. On behalf of this year's new students and their instructors, I ask you to keep these changes in the release as planned. Thanks, --jh-- Prof. Joseph Harrington Department of Physics MAP 414 4000 Central Florida Blvd. University of Central Florida Orlando, FL 32816-2385 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Benchmarking code
On Wed, Jul 23, 2008 at 9:40 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: 2008/7/23 Alan McIntyre [EMAIL PROTECTED]: There's a function (_test_unique1d_speed) in numpy/lib/arraysetops.py that looks to me like it should be in a benchmark suite instead of in the library module. Would anyone mind if I moved it to numpy/lib/benchmarks? No, please go ahead. Thanks, done. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Documenting chararrays
Hi all, Should we document character arrays? Does anybody still use them? I think their behaviour can largely be duplicated by object arrays. They also seem to be broken: x = np.array(['1', '2', '3', '4']).view(np.chararray) x*3 chararray(['111', '222', '333', '444'], dtype='|S4') All good, but: x = np.array(['12', '34', '56', '78']).view(np.chararray) x * 3 chararray(['1212', '3434', '5656', '7878'], dtype='|S4') Whereas with object arrays: np.array(['12', '34', '56', '78'], dtype=object) * 3 array([121212, 343434, 565656, 787878], dtype=object) Similaryly: x.rjust(3) chararray([' a', ' b', ' c', ' d'], dtype='|S3') x = np.array(['a','b','c','d']).view(np.chararray) x.rjust(3) chararray([' a', ' b', ' c', ' d'], dtype='|S3') But then x = np.array([['ab','cd'], ['ef','gh']]).view(np.chararray) x.rjust(5) # BOOM Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documenting chararrays
On Wed, Jul 23, 2008 at 9:57 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote: Hi all, Should we document character arrays? Does anybody still use them? I think their behaviour can largely be duplicated by object arrays. They also seem to be broken: FWIW, I've got issues and patches for a couple of chararray problems: __mul__ problem: http://scipy.org/scipy/numpy/ticket/855 __mod__ problem: http://scipy.org/scipy/numpy/ticket/856 I was wondering myself when I looked at the class whether anybody was actually using it. ;) If it's to be replaced, we should probably remove it from the compiled extension wishlist on http://projects.scipy.org/scipy/numpy/wiki/ProjectIdeas. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Documenting chararrays
Stéfan van der Walt wrote: Hi all, Should we document character arrays? Does anybody still use them? I think their behaviour can largely be duplicated by object arrays. They also seem to be broken: x = np.array(['1', '2', '3', '4']).view(np.chararray) x*3 chararray(['111', '222', '333', '444'], dtype='|S4') All good, but: x = np.array(['12', '34', '56', '78']).view(np.chararray) x * 3 chararray(['1212', '3434', '5656', '7878'], dtype='|S4') Whereas with object arrays: np.array(['12', '34', '56', '78'], dtype=object) * 3 array([121212, 343434, 565656, 787878], dtype=object) Similaryly: x.rjust(3) chararray([' a', ' b', ' c', ' d'], dtype='|S3') x = np.array(['a','b','c','d']).view(np.chararray) x.rjust(3) chararray([' a', ' b', ' c', ' d'], dtype='|S3') But then x = np.array([['ab','cd'], ['ef','gh']]).view(np.chararray) x.rjust(5) # BOOM Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion I know that chararrays are used by pyfits. Chris -- Christopher Hanley Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] integer array creation oddity
Thanks Everyone.
On Mon, Jul 21, 2008 at 6:25 PM, Charles R Harris [EMAIL PROTECTED]
wrote:
On Mon, Jul 21, 2008 at 3:37 PM, Stéfan van der Walt [EMAIL PROTECTED]
wrote:
2008/7/21 Suchindra Sandhu [EMAIL PROTECTED]:
Is that the recommended way of checking the type of the array? Ususally
for
type checkin, I use the isinstance built-in in python, but I see that
will
not work in this case. I must admit that I am a little confused by this.
Why
is type different from dtype?
Data-types contain additional information needed to lay out numerical
types in memory, such as byte-order and bit-width. Each data-type has
an associated Python type, which tells you the type of scalars in an
array of that dtype. For example, here are two NumPy data-types that
are not equal:
In [6]: d1 = np.dtype(int).newbyteorder('')
In [7]: d2 = np.dtype(int).newbyteorder('')
In [8]: d1.type
Out[8]: type 'numpy.int32'
In [9]: d2.type
Out[9]: type 'numpy.int32'
In [10]: d1 == d2
Out[10]: False
I don't know why there is more than one int32 type (I would guess it
has something to do with the way types are detected upon build; maybe
Robert or Travis could tell you more).
They correspond to two C types of the same size, int and long. On 64 bit
systems you should have two int64 types, long and longlong.
In [1]: dtype('i').name
Out[1]: 'int32'
In [2]: dtype('l').name
Out[2]: 'int32'
Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Schedule for 1.2.0
On Wed, Jul 23, 2008 at 6:46 AM, David Huard [EMAIL PROTECTED] wrote: I think we should stick to what has been agreed and announced months ago. It's called honouring our commitments and the project's image depends on it. If the inconvenience of these API changes is worth the trouble, a 1.1.2 release could be considered. +1 I would also like to stick with the original plans and make the changes in 1.2.0. I also think that given the fact that 1.1.1 will include a large number of bugfixes from the trunk the concerns about making the API change aren't as pronounced. I also agree that if it becomes an issue that releasing 1.1.2 might be a reasonable response. If anyone still thinks that we should wait until 1.3 to make the changes, now is the time to speak up. Otherwise, let's plan to make the changes on the trunk by the end of the week. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py - a recap
Hi all, I'm just reposting here to see if anyone with a stake in f2py has an opinion/advice on the points below. F2py feels very much in autopilot/drifting into the icebergs mode right now. Is that correct assessment? If there's any guidance on where to go, I can at least file tickets on these points, but I don't want to create unnecessary tickets on trac if others feel the current situation is satisfactory and it's just me who is confused. Cheers, f On Fri, Jul 18, 2008 at 9:00 PM, Fernando Perez [EMAIL PROTECTED] wrote: Howdy, today's exercise with f2py left some lessons learned, mostly thanks to Robert's excellent help, for which I'm grateful. I'd like to recap here what we have, mostly to decide what changes (if any) should go into numpy to make the experience less interesting for future users: - Remove the f2py_options flag from numpy.distutils.extension.Extension? If so, do options like '--debug_capi' get correctly passed via setup.cfg? This flag is potentially very confusing, because only *some* f2py options get actually set this way, while others need to be set in calls to config_fc. - How to properly set the compiler options in a setup.py file? Robert suggested the setup.cfg file, but this doesn't get picked up unless config_fc is explicitly called by the user: ./setup.py config_fc etc... This is perhaps a distutils problem, but I don't know if we can solve it more cleanly. It seems to me that it should be possible to provide a setup.py file that can be used simply as ./setup.py install (with the necessary setup.cfg file sitting next to it). I'm thinking here of what we need to do when showing how 'easy' these tools are for scientists migrating from matlab, for example. Obscure, special purpose incantations tend to tarnish our message of ease :) - Should the 'instead' word be removed from the f2py docs regarding the use of .pyf sources? It appears to be a mistake, which threw at least me for a loop for a while. - Why does f2py in the source tree have *both* a doc/ and a docs/ directory? It's really confusing to see this. f2py happens to be a very important tool, not just because scipy couldn't build without it, but also to position python as a credible integration language for scientific work. So I hope we can make using it as easy and robust as is technically feasible. Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Instructions on building from source
Howdy, I was just trying to explain to a new user how to build numpy from source on ubuntu and I realized that there's not much info on this front in the source tree. Scipy has a nice INSTALL.txt that even lists the names of the debian/ubuntu packages needed for the build (which can be a useful guide on other distros). Should we have a stripped-down copy of this doc somewhere in the top-level directory of numpy? It's also disconcerting for a new user that there's no visible documentation directory at the top, perhaps listing the existence of numpy/doc in the readme could help. I know there's plenty of work being done right now on the docs, so perhaps sprucing up the 'out of the tarball' experience for those building from source could be done with a very reasonable amount of effort. Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Instructions on building from source
On Wed, Jul 23, 2008 at 16:56, Fernando Perez [EMAIL PROTECTED] wrote: Howdy, I was just trying to explain to a new user how to build numpy from source on ubuntu and I realized that there's not much info on this front in the source tree. Scipy has a nice INSTALL.txt that even lists the names of the debian/ubuntu packages needed for the build (which can be a useful guide on other distros). Should we have a stripped-down copy of this doc somewhere in the top-level directory of numpy? Yes. It's also disconcerting for a new user that there's no visible documentation directory at the top, perhaps listing the existence of numpy/doc in the readme could help. Yes. I'm not sure why they're in numpy/doc/ to begin with. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Instructions on building from source
Robert Kern wrote: On Wed, Jul 23, 2008 at 16:56, Fernando Perez [EMAIL PROTECTED] wrote: Howdy, I was just trying to explain to a new user how to build numpy from source on ubuntu and I realized that there's not much info on this front in the source tree. Scipy has a nice INSTALL.txt that even lists the names of the debian/ubuntu packages needed for the build (which can be a useful guide on other distros). Should we have a stripped-down copy of this doc somewhere in the top-level directory of numpy? Just for reference, you can find the build dependencies of any Debian source package by looking at its .dsc file. For numpy, that can be found at http://packages.debian.org/sid/python-numpy Currently (version 1.1.0, debian version 1:1.1.0-3), that list is: Build-Depends: cdbs (= 0.4.43), python-all-dev, python-all-dbg, python-central (= 0.6), gfortran (= 4:4.2), libblas-dev [!arm !m68k], liblapack-dev [!arm !m68k], debhelper (= 5.0.38), patchutils, python-docutils, libfftw3-dev Build-Conflicts: atlas3-base-dev, libatlas-3dnow-dev, libatlas-base-dev, libatlas-headers, libatlas-sse-dev, libatlas-sse2-dev Some of that stuff (cdbs, debhelper, patchutils) is specific to the Debian build process and wouldn't be necessary for simply compiling numpy itself. And on a Debian (derivative) system, you can stall those with apt-get build-dep python-numpy. This will only install the build dependencies for the version of python-numpy which is listed in your apt sources.list, but 99% of the time, that should be sufficient. -Andrew ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reference guide updated
Ok, thanks. I meant the amount of vertical space between lines of text - for example, the gaps between parameter values and their description, or the large spacing between both lines of text and and the text boxes in the examples section. If other people agree it's a problem, I thought the spacing could be tweaked. It's not a problem that there's more than one function per page. I have been helping out with the docs (where I feel I'm qualified enough - I'm no numpy expert!). I think it will make numpy much easier to learn to have easily-accessible, comprehensive docstrings, and the documentation editor makes it very easy to contribute. I'm also learning a lot reading other people's docstrings :) It there a reason why there's so much vertical space between all of the text sections? I find the docstrings much easier to read in the editor: Roughly: * In the editor, you have one function per page, vs several function per page in the reference * in the editor, the blocks 'Parameters', 'Returns'... are considered as sections, while in the reference, they are Field lists (roughly). In the end, it's only a matter of taste, of course. But you raise an interesting point, we should provide some kind of options to choose between behaviors. Please note as well that the reference guide is a work in progress: you're more than welcome to join and work with us. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py - a recap
2008/7/23 Fernando Perez [EMAIL PROTECTED]: I'm just reposting here to see if anyone with a stake in f2py has an opinion/advice on the points below. F2py feels very much in autopilot/drifting into the icebergs mode right now. Is that correct assessment? If there's any guidance on where to go, I can at least file tickets on these points, but I don't want to create unnecessary tickets on trac if others feel the current situation is satisfactory and it's just me who is confused. As far as I understand, Pearu is busy developing g3 of f2py. Does that mean that f2py in NumPy is effectively unmaintained? I hope not. I agree (with your previous e-mail) that it would be good to have some documentation, so if you could give me some pointers on *what* to document (I haven't used f2py much), then I'll try my best to get around to it. Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py - a recap
On Wed, Jul 23, 2008 at 17:18, Stéfan van der Walt [EMAIL PROTECTED] wrote: 2008/7/23 Fernando Perez [EMAIL PROTECTED]: I'm just reposting here to see if anyone with a stake in f2py has an opinion/advice on the points below. F2py feels very much in autopilot/drifting into the icebergs mode right now. Is that correct assessment? If there's any guidance on where to go, I can at least file tickets on these points, but I don't want to create unnecessary tickets on trac if others feel the current situation is satisfactory and it's just me who is confused. As far as I understand, Pearu is busy developing g3 of f2py. I think he's been busy doing other things for the past few months, at least. Does that mean that f2py in NumPy is effectively unmaintained? I hope not. We'll try to fix bugs as they come up, but this is, as always, subject to the vagaries of free time. It is very unlikely to grow new features. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] f2py - a recap
Howdy, On Wed, Jul 23, 2008 at 3:18 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: 2008/7/23 Fernando Perez [EMAIL PROTECTED]: I agree (with your previous e-mail) that it would be good to have some documentation, so if you could give me some pointers on *what* to document (I haven't used f2py much), then I'll try my best to get around to it. Well, I think my 'recap' message earlier in this thread points to a few issues that can probably be addressed quickly (the 'instead' error in the help, the doc/docs dichotomy needs to be cleaned up so a single documentation directory exists, etc). I'm also attaching a set of very old notes I wrote years ago on f2py that you are free to use in any way you see fit. I gave them a 2-minute rst treatment but didn't edit them at all, so they may be somewhat outdated (I originally wrote them in 2002 I think). If Pearu has moved to greener pastures, f2py could certainly use an adoptive parent. It happens to be a really important piece of infrastructure and for the most part it works fairly well. I think a litlte bit of cleanup/doc integration with the rest of numpy is probably all that's needed, so it could be a good project for someone to adopt that would potentially be low-demand yet quite useful. Cheers, f F2PY Author: Fernando Perez [EMAIL PROTECTED]. Please send all comments/corrections to this address. This is a rough set of notes on how to use f2py. It does NOT substitute the official manual, but is rather meant to be used alongside with it. For any non-trivial poject involving f2py, one should also keep at hand Pierre Schnizer's excellent 'A short introduction to F2PY', available from http://fubphpc.tu-graz.ac.at/~pierre/f2py_tutorial.tar.gz Usage for the impatient --- Start by building a scratch signature file automatically from your Fortran sources (in this case all, you can choose only those .f files you need):: f2py -m MODULENAME -h MODULENAME.pyf *.f This writes the file MODULENAME.pyf, making the best guesses it can from the Fortran sources. It builds an interface for the module to be accessed as 'import adap1d' from python. You will then edit the .pyf file to fine-tune the python interface exhibited by the resulting extension. This means for example making unnecessary scratch areas or array dimensions hidden, or making certain parameters be optional and take a default value. Then, write your setup.py file using distutils, and list the .pyf file along with the Fortran sources it is meant to wrap. f2py will build the module for you automatically, respecting all the interface specifications you made in the .pyf file. This approach is ultimately far easier than trying to get all the declarations (especially dependencies) right through Cf2py directives in the Fortran sources. While that may seem appealing at first, experience seems to show that it's ultimately far more time-consuming and prone to subtle errors. Using this approach, the first f2py pass can do the bulk of the interface writing and only fine-tuning needs to be done manually. I would only recommend embedded Cf2py directives for very simple problems (where it works very well). The only drawback of this approach is that the interface and the original Fortran source lie in different files, which need to be kept in sync. This increases a bit the chances of forgetting to update the .pyf file if the Fortran interface changes (adding a parameter, for example). However, the benefit of having explicit, clear control over f2py's behavior far outweighs this concern. Choosing a default compiler --- Set the FC_VENDOR environment variable. This will then prevent f2py from testing all the compilers it knows about. Using Cf2py directives -- For simpler cases you may choose to go the route of Cf2py directives. Below are some tips and examples for this approach. Here's the signature of a simple Fortran routine:: subroutine phipol(j,mm,nodes,wei,nn,x,phi,wrk) implicit real *8 (a-h, o-z) real *8 nodes(*),wei(*),x(*),wrk(*),phi(*) real *8 sum, one, two, half The above is correctly handled by f2py, but it can't know what is meant to be input/output and what the relations between the various variables are (such as integers which are array dimensions). If we add the following f2py directives, the generated python interface is a lot nicer:: c subroutine phipol(j,mm,nodes,wei,nn,x,phi,wrk) c c Lines with Cf2py in them are directives for f2py to generate a better c python interface. These must come _before_ the Fortran variable c declarations so we can control the dimension of the arrays in Python. c c Inputs: Cf2py integer check(0=j jmm),depend(mm) :: j Cf2py real *8 dimension(mm),intent(in) :: nodes Cf2py real *8 dimension(mm),intent(in) :: wei Cf2py real *8 dimension(nn),intent(in)
Re: [Numpy-discussion] Instructions on building from source
On Wed, Jul 23, 2008 at 3:02 PM, Robert Kern [EMAIL PROTECTED] wrote: On Wed, Jul 23, 2008 at 16:56, Fernando Perez [EMAIL PROTECTED] wrote: (which can be a useful guide on other distros). Should we have a stripped-down copy of this doc somewhere in the top-level directory of numpy? Yes. It's also disconcerting for a new user that there's no visible documentation directory at the top, perhaps listing the existence of numpy/doc in the readme could help. Yes. I'm not sure why they're in numpy/doc/ to begin with. OK, thanks for the feedback. I'm not about to touch doc stuff when the core team is deep in the middle of the doc marathon, but this may provide them useful guidance to clean things up a bit. cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Instructions on building from source
On Wed, Jul 23, 2008 at 3:13 PM, Andrew Straw [EMAIL PROTECTED] wrote: And on a Debian (derivative) system, you can stall those with apt-get build-dep python-numpy. This will only install the build dependencies for the version of python-numpy which is listed in your apt sources.list, but 99% of the time, that should be sufficient. Very, very useful. Many thanks for this tip, Andrew! Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reference guide updated
2008/7/24 Neil Crighton [EMAIL PROTECTED]: Ok, thanks. I meant the amount of vertical space between lines of text - for example, the gaps between parameter values and their description, or the large spacing between both lines of text and and the text boxes in the examples section. If other people agree it's a problem, I thought the spacing could be tweaked. It's not a problem that there's more than one function per page. Feel free to play around with the stylesheet. Download the tarball of the docs here: http://mentat.za.net/numpy/refguide.tar.gz And edit default.css until it looks good. When done, please send me the changes! Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Instructions on building from source
Fernando Perez wrote: Very, very useful. Many thanks for this tip, Andrew! Hi Fernando, I am still catching up things (have been on holidays for 2 weeks), but have you started the INSTALL.txt document ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Instructions on building from source
On Wed, Jul 23, 2008 at 8:59 PM, David Cournapeau [EMAIL PROTECTED] wrote: Fernando Perez wrote: Very, very useful. Many thanks for this tip, Andrew! Hi Fernando, I am still catching up things (have been on holidays for 2 weeks), but have you started the INSTALL.txt document ? No, and because I'm triple-swamped pushing an ipython release (while at a full-time workshop), I likely won't. I've been trying to report things I see as I go on numpy/scipy, but realistically my available time needs to go into ipython. So knock yourself out on that one, it will be much appreciated by myself and I'm sure others. Regards, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
