Re: [Numpy-discussion] proposal: min, max of complex should give warning
I don't work with complex numbers, but just sampling what others do: Python: no ordering, results in TypeError Matlab: sorts by magnitude http://www.mathworks.com/help/matlab/ref/sort.html R: sorts first by real, then by imaginary http://stat.ethz.ch/R-manual/R-patched/library/base/html/sort.html Numpy: sorts first by real, then by imaginary (the documentation link below calls this sort 'lexicographical' which I don't think is correct) http://docs.scipy.org/doc/numpy/reference/generated/numpy.sort.html I would think that the Matlab sort might be more useful, but easy enough by using the absolute value. I think what Numpy does is normal enough to not justify a warning, but leave this to others because as I pointed out in the beginning I don't work with complex numbers. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] PEP8
I made a PR request about supplying a git hooks framework at
https://github.com/numpy/numpy/pull/200. I asked for it to be closed
because I couldn't easily figure our how to handle x-platform issues.
If you have an answer, what I was working on might be a start. But
your script is an example of the x-platform challenges since it will
only run on Windows that has a Linux environment installed (Mingw or
the like).
What I have started to use in my projects is 'tox', 'coverage', and
'flake8'. Really nice stuff. There is an issue though with the
'flake8' report. There are only very localized places in a few files
that I want to ignore some portion or other of PEP8, so I don' t
insist that 'flake8' pass, I just ignore the output where I need to
ignore it. Usually what I want to ignore is the spaces around
brackets and commas in order to line up array values as mentioned in
an earlier post within this thread. Here is an example of my project
setup based in part on 'cookiecutter' -
https://bitbucket.org/timcera/astronomia/src. Yes, I use bitbucket -
so sue me. Magic happens inside the 'tox.ini' file.
I suspect that for numpy, making something like 'flake8' part of the
tests would work better than 'autopep8'. 'autopep8' can be configured
to just report with the --list-fixes option, which would give people a
little more confidence to use it rather that it's primary mission as
an editor. Another plug for 'flake8'; it can be configured on a file
by file basis to ignore particular errors or warnings, and exits with
an error status if the file doesn't pass.
I do think the idea has merit, but this entire process would be a lot
of work and I am not stepping forward to do it. At this point I
simply have to say that I am a 'balcony muppet'. Much thanks to Josef
for the reminder about where I learned my curmudgeony ways. Those
guys made the show!
Kindest regards,
Tim
On Mon, Sep 9, 2013 at 12:08 PM, Blake Griffith
blake.a.griff...@gmail.com wrote:
I think a good solution would to use add a git_hooks directory with a
pre-commit git hook along with an git hook installation script. And a note
should be added to DEV_README.txt suggesting installing the git hooks for
pep8 compatibility. I personally use this as a pre-commit
#!/bin/sh
FILES=$(git diff --cached --name-status | grep -v ^D | awk '$1 $2 { print
$2}' | grep -e .py$)
if [ -n $FILES ]; then
pep8 -r $FILES
fi
which is from here: https://gist.github.com/lentil/810399#comment-303703
On Mon, Sep 9, 2013 at 10:54 AM, Nathaniel Smith n...@pobox.com wrote:
On Mon, Sep 9, 2013 at 3:29 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Mon, Sep 9, 2013 at 8:12 AM, Richard Hattersley
rhatters...@gmail.com
wrote:
Something we have done in matplotlib is that we have made PEP8 a part
of
the tests.
In Iris and Cartopy we've also done this and it works well. While we
transition we have an exclusion list (which is gradually getting
shorter).
We've had mixed experiences with automatic reformatting, so prefer to
keep
the human in the loop.
I agree with keeping a human in the loop, the script would be intended
to
get things into the right neighborhood, the submitter would have to
review
the changes after. If the script isn't too strict there will be than one
way
to do some things and those bits would rely on the good taste of the
coder.
So if I understand right, the goal is to have some script that
developers can run before (or after) submitting a PR, like
tools/autopep8-my-changes numpy/
that will fix up their changes, but leave the rest of numpy alone?
And the proposed mechanism is to come up with a combination of changes
to the numpy source and an autopep8 configuration such that
autopep8 --our-config numpy/
becomes a no-op, and then we can use this as an implementation of
tools/autopep8-my-changes?
If that's right then my feeling is that the goal seems worthwhile but
the approach seems difficult and unlikely to survive for long. As soon
as someone overrides autopep8 once, we either have to disable the rule
for the whole project or keep overriding it manually forever. You're
already suggesting taking out the spaces-around-arithmetic rule, which
strikes me as one of the most useful -- sure, it gets things wrongs
sometimes, but I feel like we're constantly reviewing PRs where
all*the*(arithmetic+is)-written**like*this.
Maybe a better approach would be to spend that time hacking up some
script that uses git and autopep8 together to run autopep8 over all
and only those lines which the current branch has actually touched?
It's pretty easy to parse 'git diff' output to get a list of all line
numbers which have been modified, and then we could run autopep8 over
the modified files and pull out only those changes which touch those
lines.
-n
P.S.: definitely [:, :, 2]
___
NumPy-Discussion mailing list
Re: [Numpy-discussion] (no subject)
I am trying to take the rfft of a numpy array, like this:
my_rfft = numpy.fft.rfft(my_numpy_array)
and replace the amplitudes that can be obtained with:
my_amplitudes = numpy.abs(my_rfft)
with amplitudes from an arbitrary numpy array's rFFT, which is to then be
converted back using numpy.fft.irfft . Alternately, some future plans will
involve having to modify individual array element amplitudes directly based
on other parameters. I would think that modifying and re-synthesizing
signals using FFT is a fairly common use-case, but my attempts at Googling
example code have been fruitless.
I have FFT transform filter in my tidal analysis package. See
http://sourceforge.net/apps/mediawiki/tappy/index.php?title=CompareTidalFilters
for a comparison and short description.
See my function below. My earlier self made some poor variable name
choices. The 'low_bound' variable is actually where frequencies
greater are set to zero ('factor[freq low_bound] = 0.0'), then
factor is ramped from 0 at 'low_bound' to 1 at 'high_bound'. To
filter out tidal signals if your water elevations are hourly then
'low_bound' = 1/30.0 and 'high_bound' = 1/40.0. Having this gradual
change in the frequency domain rather than an abrupt change makes a
better filter.
def fft_lowpass(nelevation, low_bound, high_bound):
Performs a low pass filter on the nelevation series.
low_bound and high_bound specifies the boundary of the filter.
import numpy.fft as F
if len(nelevation) % 2:
result = F.rfft(nelevation, len(nelevation))
else:
result = F.rfft(nelevation)
freq = F.fftfreq(len(nelevation))[:len(nelevation)/2]
factor = np.ones_like(result)
factor[freq low_bound] = 0.0
sl = np.logical_and(high_bound freq, freq low_bound)
a = factor[sl]
# Create float array of required length and reverse
a = np.arange(len(a) + 2).astype(float)[::-1]
# Ramp from 1 to 0 exclusive
a = (a/a[0])[1:-1]
# Insert ramp into factor
factor[sl] = a
result = result * factor
print 'result=', len(result)
relevation = F.irfft(result, len(nelevation))
print 'result=', len(relevation)
return relevation
Kindest regards,
Tim
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Strange behavior with boolean slices...
I have done this before, but am now really confused. Created an array 'day' specifying the 'f' type In [29]: day Out[29]: array([ 5., 5.], dtype=float32) # Have a mask... In [30]: mask Out[30]: array([ True, False], dtype=bool) # So far, so good... In [31]: day[mask] Out[31]: array([ 5.], dtype=float32) In [32]: day[mask] = 10 # What? In [33]: day Out[33]: array([ 10., 10.], dtype=float32) So I created an integer array 'a' In [38]: a Out[38]: array([11, 1]) In [39]: a[mask] Out[39]: array([11]) In [40]: a[mask] = 12 # This is what I expect. In [41]: a Out[41]: array([12, 1]) Am I missing something? Is this supposed to happen? Version 1.7.1. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Strange behavior with boolean slices...
Figured it out. I created 'day' as a broadcast array. Does this catch other people? Basically changing day[0] would change the entire 'day' array. I guess all other elements of the day array are views of day[0]. Made a copy and everything works as expected. Kindest regards, Tim On Sun, Aug 25, 2013 at 8:44 PM, Eric Firing efir...@hawaii.edu wrote: On 2013/08/25 2:30 PM, Cera, Tim wrote: I have done this before, but am now really confused. Created an array 'day' specifying the 'f' type In [29]: day Out[29]: array([ 5., 5.], dtype=float32) # Have a mask... In [30]: mask Out[30]: array([ True, False], dtype=bool) # So far, so good... In [31]: day[mask] Out[31]: array([ 5.], dtype=float32) In [32]: day[mask] = 10 # What? In [33]: day Out[33]: array([ 10., 10.], dtype=float32) I'm not getting that with 1.7.0: In [2]: np.__version__ Out[2]: '1.7.0' In [3]: mask = np.array([True, False], dtype=bool) In [4]: day = np.array([5, 5], dtype=np.float32) In [5]: day Out[5]: array([ 5., 5.], dtype=float32) In [6]: mask Out[6]: array([ True, False], dtype=bool) In [7]: day[mask] Out[7]: array([ 5.], dtype=float32) In [8]: day[mask] = 10 In [9]: day Out[9]: array([ 10., 5.], dtype=float32) Eric So I created an integer array 'a' In [38]: a Out[38]: array([11, 1]) In [39]: a[mask] Out[39]: array([11]) In [40]: a[mask] = 12 # This is what I expect. In [41]: a Out[41]: array([12, 1]) Am I missing something? Is this supposed to happen? Version 1.7.1. Kindest regards, Tim ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Strange behavior with boolean slices...
Pardon the noise. The behavior is described right there in the documentation of broadcast_arrays. Kindest regards, Tim On Sun, Aug 25, 2013 at 8:53 PM, Cera, Tim t...@cerazone.net wrote: Figured it out. I created 'day' as a broadcast array. Does this catch other people? Basically changing day[0] would change the entire 'day' array. I guess all other elements of the day array are views of day[0]. Made a copy and everything works as expected. Kindest regards, Tim On Sun, Aug 25, 2013 at 8:44 PM, Eric Firing efir...@hawaii.edu wrote: On 2013/08/25 2:30 PM, Cera, Tim wrote: I have done this before, but am now really confused. Created an array 'day' specifying the 'f' type In [29]: day Out[29]: array([ 5., 5.], dtype=float32) # Have a mask... In [30]: mask Out[30]: array([ True, False], dtype=bool) # So far, so good... In [31]: day[mask] Out[31]: array([ 5.], dtype=float32) In [32]: day[mask] = 10 # What? In [33]: day Out[33]: array([ 10., 10.], dtype=float32) I'm not getting that with 1.7.0: In [2]: np.__version__ Out[2]: '1.7.0' In [3]: mask = np.array([True, False], dtype=bool) In [4]: day = np.array([5, 5], dtype=np.float32) In [5]: day Out[5]: array([ 5., 5.], dtype=float32) In [6]: mask Out[6]: array([ True, False], dtype=bool) In [7]: day[mask] Out[7]: array([ 5.], dtype=float32) In [8]: day[mask] = 10 In [9]: day Out[9]: array([ 10., 5.], dtype=float32) Eric So I created an integer array 'a' In [38]: a Out[38]: array([11, 1]) In [39]: a[mask] Out[39]: array([11]) In [40]: a[mask] = 12 # This is what I expect. In [41]: a Out[41]: array([12, 1]) Am I missing something? Is this supposed to happen? Version 1.7.1. Kindest regards, Tim ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecation of financial routines
On Mon, Aug 19, 2013 at 2:37 AM, Juan Luis Cano juanlu...@gmail.com wrote: As now master is open for 1.9, following the discussion opened here https://github.com/numpy/numpy/issues/2880 it was suggested that we deprecate and eventually remove the financial functions in NumPy, because they pollute the main namespace and some are unimplemented. We could put them in a separate package, in case it doesn't exist yet. Nathaniel Smith and Ralf Gommers already gave +1, and Charles Harris suggested bringing this up in the mailing list. When I was initially working with the docs it galled me to find documented, but unimplemented financial functions. I spent the time to implement all of the unimplemented functions. As an example see https://github.com/numpy/numpy/pull/190. I just glanced through the code and all functions are there, implemented and documented, so I don't know where that comment came from in https://github.com/numpy/numpy/issues/2880. Definitely in 1.7. About whether they should stay or go, I vote 0. I see financial functions as an absolute requirement in engineering (though often engineers allow financial optimization and decisions to default to others, IMO a big mistake). Financial analysis in science? Probably not so much, which is my guess as to why the discussion was brought up. Since I wrote a couple of the financial functions, you would think I might vote -1 to deprecation, but the reason I wrote the functions was to remove the NotImplemented errors. They really bothered me. I thought that if the functions were already included in numpy, they must be useful to someone. For me, typically I do any financial work in a spreadsheet - that is why I vote 0. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Is there a way to reset an accumulate function?
On Wed, Oct 24, 2012 at 4:47 AM, Robert Kern robert.k...@gmail.com wrote: How about this? def nancumsum(x): nans = np.isnan(x) x = np.array(x) x[nans] = 0 reset_idx = np.zeros(len(x), dtype=int) reset_idx[nans] = np.arange(len(x))[nans] reset_idx = np.maximum.accumulate(reset_idx) cumsum = np.cumsum(x) cumsum = cumsum - cumsum[reset_idx] return cumsum Thank you for putting in the time to look at this. It doesn't work for the first group of numbers if x[0] is non-zero. Could perhaps concatenate a np.nan at the beginning to force a reset and adjust the returned array to not include the dummy value... def nancumsum(x): x = np.concatenate(([np.nan], x)) nans = np.isnan(x) x = np.array(x) x[nans] = 0 reset_idx = np.zeros(len(x), dtype=int) reset_idx[nans] = np.arange(len(x))[nans] reset_idx = np.maximum.accumulate(reset_idx) cumsum = np.cumsum(x) cumsum = cumsum - cumsum[reset_idx] return cumsum[1:] a array([ 4., 1., 2., 0., 18., 5., 6., 0., 8., 9.], dtype=float32) If no np.nan, then 'nancumsum' and 'np.cumsum' should be the same... np.cumsum(a) array([ 4., 5., 7., 7., 25., 30., 36., 36., 44., 53.], dtype=float32) nancumsum(a) array([ 4., 5., 7., 7., 25., 30., 36., 36., 44., 53.]) a[3] = np.nan np.cumsum(a) array([ 4., 5., 7., nan, nan, nan, nan, nan, nan, nan], dtype=float32) nancumsum(a) array([ 4., 5., 7., 0., 18., 23., 29., 29., 37., 46.]) Excellent! Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Is there a way to reset an accumulate function?
I have an array that is peppered throughout in random spots with 'nan'. I would like to use 'cumsum', but I want it to reset the accumulation to 0 whenever a 'nan' is encountered. Is there a way to do this? Aside from a loop - which is what I am going to setup here in a moment. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
On Sun, Oct 14, 2012 at 8:24 PM, Zachary Pincus zachary.pin...@yale.eduwrote: It would be useful for the author of the PR to post a detailed comparison of this functionality with scipy.ndimage.generic_filter, which appears to have very similar functionality. I'll be durned. I created neighbor because I didn't find what I wanted, and to find now that I just didn't look in the right place is well ... Let's just say that I went for a long run last night. Searching for ndimage, I found that is has been around a long, long time. First in numarray, then moved to scipy. Really I could only nitpick about minor differences - kinda like a primary political campaign. On the face of it though, generic_filter looks better. First off it is written in C so likely will be faster and more efficient memory use. I didn't look at optimizing neighbor at all and at least my part of it is pure Python. Of course for all of the small differences, I like my choices better. :-) I would like to make a mild suggestion. Emphasis on mild. Maybe ndimage, in all or in part, should be brought into (back into?) Numpy and renamed. About the PR. Given that the neighbor functionality exists already, I will close the PR later today. Move along, nothing to see here... Side note: I wrote arraypad with the future idea that it would become easyish to include that functionality in other places, for example in neighbor. A Don't Repeat Yourself idea. Previously I had only seen Fortran pad capabilities in some of the Fast Fourier Transform functions. The generic_filter function includes several padding functions - written in C. This means that if arraypad needs be more efficient we have C code to base a better arraypad. Another side node: The measurements functions in ndimage are called zonal functions in the GIS field. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Fwd: [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
For the neighbor module, the neighborhood is input specified by the 'weight' array. All values in the neighborhood are processed by a function. In the geosciences, ArcGIS is a very important tool and the neighbor module is very loosely modeled after http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=An%20overview%20of%20the%20Neighborhood%20tools If the language is confusing, now is the time to change the names. Kindest regards, Tim On Fri, Oct 12, 2012 at 8:33 AM, Sturla Molden stu...@molden.no wrote: On 10.10.2012 15:42, Nathaniel Smith wrote: This PR submitted a few months ago adds a substantial new API to numpy, so it'd be great to get more review. No-one's replied yet, though... Any thoughts, anyone? Is it useful, could it be better...? Fast neighbor search is what scipy.spatial.cKDTree is designed for. There is an brand new version in SciPy master. Sturla ___ 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
Re: [Numpy-discussion] Fwd: [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
If you followed the link http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=An%20overview%20of%20the%20Neighborhood%20tools note that the current neighborhood implementation that we are talking about implements the ArcGIS 'Focal*' functionality, not the 'Block*' ones. Note also that ArcGIS is limited to 2-d, and a 3x3 neighborhood. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Fwd: [numpy] ENH: Initial implementation of a 'neighbor' calculation (#303)
On Wed, Oct 10, 2012 at 1:58 AM, Travis E. Oliphant notificati...@github.com wrote: I'm not sure what to make of no comments on this PR. This seems like a useful addition. @timcera https://github.com/timcera are you still interested in having this PR merged? Yes. I mentioned in PR comments that the lack of discussion is because my code engenders speechless awe in anyone who looks at it. :-) Of course speechless awe can come from two different reasons! Hopefully it is because my code is so awesome. Seriously, I really wanted some input, especially after I found #31https://github.com/numpy/numpy/issues/31 . On Wed, Oct 10, 2012 at 7:24 AM, Eric Moore notificati...@github.com wrote: This seems to be trying to solve a very similar problem to #31https://github.com/numpy/numpy/issues/31 Internally I implemented something like rolling window, but I don't return the windows. Instead the contents of the windows are used for calculation of each windows 'central' cell in the results array. After seeing the rolling window function I thought it might be nice to bring that out into a callable function, so that similar functionality would be available. That particular function isn't useful to me directly, but perhaps others? Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Multidimensional neighbours
I have a pull request for a neighborhood function at https://github.com/numpy/numpy/pull/303 . I think IMHO it handles these problems quite handily. It does rely on my pad routine that is in Numpy 1.7, so you would need to get the 1.7 beta installed or install the development branch. For your example you would just create a weight array, and a function that returns a scalar value from the collected neighborhood values. Untested, but workflow is something like: inputarr = np.random.random(9*9*9) inputarr = inputarr.reshape((9,9,9)) weight = np.ones((3,3,3)) ans = neighbor(inputarr, weight, np.mean, pad = None) In place of 'np.mean' you can define your own function - game of life function for example. The PR has not had much activity, so if you can review/comment/program that would be appreciated. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Looking for the most important bugs, documentation needs, etc.
For documentation we have docstrings for each function and tutorial-style docs (http://docs.scipy.org/doc/numpy/user/, http://scipy-lectures.github.com/intro/numpy/index.html) . All docstrings should have clear usage examples, but I'm actually finding it quite hard to find functions that don't have any right now. The only one I could dig up so quickly is corrcoef(). There must be a few more. The documentation wiki has a little known feature to list functions that do not have docstrings and docstrings that do not have examples. Go to http://docs.scipy.org/numpy/search/ and click on the 'No Examples' or 'No Documentation' links. Same searches are available with scipy at http://docs.scipy.org/scipy/search/, which Ralf already pointed out needs the most work. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
Similar to http://scicomp.stackexchange.com there is http://meta.programmers.stackexchange.com/ intended for programmers. Darn it, there are choices involved! I had proposed http://meta.programmers.stackexchange.com/ on this mailing list earlier and no-one seemed interested, but maybe now the time is right. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
You are correct, I meant http://programmers.stackexchange.com/ And on a site like stackexchange I could actually edit my post instead of my mistake being permanent. :-) Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
A little more research shows that we could have a http://numpy.stackexchange.com. The requirements are just to have people involved. See http://area51.stackexchange.com/faq for more info. Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Meta: help, devel and stackoverflow
That is really funny. Looking through the posts, there wasn't any spam (could have been deleted), but it wasn't used as much as I would think. Have to attract people who answer questions. Early on the registration seemed to be a problem. Solace, the software behind ask.scipy.org looks pretty nice, EXCEPT that the last commit was in 2009. On the other have it could be that it has reached perfection. :-) Kindest regards, Tim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
