Hi everyone,
There have been some wonderfully vigorous discussions over the past few months
that have made it clear that we need some clarity about how decisions will be
made in the NumPy community.
When we were a smaller bunch of people it seemed easier to come to an agreement
and
.
-Travis
On Dec 3, 2011, at 9:42 PM, Matthew Brett wrote:
Hi Travis,
On Sat, Dec 3, 2011 at 6:18 PM, Travis Oliphant teoliph...@gmail.com wrote:
Hi everyone,
There have been some wonderfully vigorous discussions over the past few
months that have made it clear that we need some
http://mail.scipy.org/mailman/listinfo/numpy-discussion
---
Travis Oliphant
Enthought, Inc.
oliph...@enthought.com
1-512-536-1057
http://www.enthought.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman
I like the idea. Is there resolution to the NA question?
--
Travis Oliphant
(on a mobile)
512-826-7480
On Dec 5, 2011, at 2:43 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate
has quieted down, so
-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
---
Travis Oliphant
Enthought, Inc.
oliph...@enthought.com
1-512-536-1057
http://www.enthought.com
___
NumPy-Discussion mailing list
NumPy
This is really excellent. I would like to take a stab at getting this pulled
in to the code base --- and fixing the GIL issue --- if someone hasn't beat me
to it.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Dec 20, 2011, at 9:24 PM, Geoffrey Irving irv...@naml.us wrote:
Hello
I agree with Dag, NumPy should provide consistent handling of empty arrays.
It does require some work, but it should be at least declared a bug when it
doesn't.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Dec 28, 2011, at 7:45 AM, Dag Sverre Seljebotn d.s.seljeb
That was an extremely helpful and useful post.
Thank you Ondrej for sharing it and taking the time to provide that insight.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Dec 29, 2011, at 12:51 AM, Ondrej Certik ond...@certik.cz wrote:
On Mon, Dec 5, 2011 at 4:22 AM, Perry
A categorical type (or enum type) is an important dtype to add to NumPy. It
would be very nice if the option existed to make the categorical dtype
dynamic in that the categories can grow as more data is added or inserted
into the array. This would effectively allow binning of data on
No. All of the PyTypeObject objects for the NumPy array scalars are
explicitly part of the NumPy C API so you have no choice but to depend
on that (to get the best performance). If you want to ONLY check for
int64 at the C API level, I did a bit of digging and the relevant type
definitions
It is a straightforward thing to implement a registry mechanism for Python
that by-passes imp.find_module (i.e. using sys.meta_path). You could imagine
creating the registry file for a package or distribution (much like Dag
described) and push that to every node during distribution.
The
I think the problem here is one of delegation and information.
I'm not even sure how the web-pages get updated at this point. Does anyone on
this list know?I think it would be a great idea to move to github pages for
the NumPy project at least.
-Travis
On Jan 19, 2012, at 12:39 AM,
Can you determine where the problem is, precisely.In other words, can you
verify that c is not getting filled in correctly?
You are no doubt going to get overflow in the summation as you have a uint8
parameter. But, having that overflow be exactly '0' would be surprising.
Can you
I also agree that an exception should be raised at the very least.
It might also be possible to make the NumPy any, all, and sum functions behave
like the builtins when given a generator. It seems worth exploring at least.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Jan 31
interpret a generator expression, but in the context of streaming or deferred
arrays.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Jan 31, 2012, at 4:22 PM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Jan 31, 2012 at 22:17, Travis Oliphant tra...@continuum.io wrote:
I also
On Feb 1, 2012, at 7:04 PM, Mark Wiebe wrote:
On Wed, Feb 1, 2012 at 3:29 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
The macro PyArray_RemoveLargest has been replaced by PyArray_RemoveSmallest
(which seems strange), but I wonder if this documentation still makes sense.
My
Thanks! What a great doc page.
-Travis
On Feb 1, 2012, at 8:31 PM, Mark Wiebe wrote:
On Wed, Feb 1, 2012 at 6:14 PM, Travis Oliphant tra...@continuum.io wrote:
On Feb 1, 2012, at 7:04 PM, Mark Wiebe wrote:
On Wed, Feb 1, 2012 at 3:29 PM, Charles R Harris charlesr.har...@gmail.com
://marketingstartups.com/2009/05/28/the-first-six-steps-of-getting-your-startup-noticed/
-Travis
On Feb 1, 2012, at 8:31 PM, Mark Wiebe wrote:
On Wed, Feb 1, 2012 at 6:14 PM, Travis Oliphant tra...@continuum.io wrote:
On Feb 1, 2012, at 7:04 PM, Mark Wiebe wrote:
On Wed, Feb 1, 2012 at 3
This seems odd to me. Unraveling what is going on (so far):
Let a = np.complex64(1j) and b = A()
* np.complex64.__add__ is calling np.add
* np.add(a, b) needs to search for an add loop that matches the input
types and it finds one with signature
Hey Andreas,
As previously described: what changes the type of np.complex64(1j) during the
A() call is that when a is an array scalar it is converted to an object array
because that is the only signature that matches. During this conversion, what
is extracted from the object array is piped
On Feb 2, 2012, at 12:58 PM, Ralf Gommers wrote:
On Thu, Feb 2, 2012 at 6:36 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Thu, Feb 2, 2012 at 9:58 AM, Bruce Southey bsout...@gmail.com wrote:
On 02/01/2012 02:53 PM, Charles R Harris wrote:
Hi All,
Two things here.
I see your time machine is in full working order :-)
--
Travis Oliphant
(on a mobile)
512-826-7480
On Feb 2, 2012, at 4:18 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Wed, Feb 1, 2012 at 7:13 PM, Travis Oliphant tra...@continuum.io wrote:
Hey Mark,
I spent some quality time with your
release of June 2012.
Thanks,
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Feb 4, 2012, at 11:37 AM, Charles R Harris charlesr.har...@gmail.com wrote:
Hi All,
In the discussion on deprecating old macros in 1.7 as part of pull request
189 the issue of how to move numpy
:
On Sat, Feb 4, 2012 at 3:03 PM, Travis Oliphant tra...@continuum.io wrote:
We are spending a lot of time on NumPy and will be for the next few
months. I think that 1.8 will be a better long term release. We need a few
more fundamental features yet.
Look for a roadmap document
Fortunately that's not the case. All that Mark is advocating is not allowing
changing the *itself* in place. You are still free to change the dtype of the
array in order to change the field names without making a data copy.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Feb 5
On Feb 7, 2012, at 4:02 AM, Pauli Virtanen wrote:
Hi,
06.02.2012 20:41, Ralf Gommers kirjoitti:
[clip]
I've created https://github.com/scipy/scipy.github.com and gave you
permissions on that. So with that for the built html and
https://github.com/scipy/scipy.org-new for the sources, that
This comes up from time to time.This is an example of what is described at
the top of page 84 of Guide to NumPy. Also read Chapter 17 to get the
explanation of how fancy indexing is implemented if you really want to
understand the issues.
When you mix fancy-indexing with simple indexing,
On Feb 7, 2012, at 12:24 PM, Sturla Molden wrote:
On 07.02.2012 19:17, Benjamin Root wrote:
print x.shape
(2, 3, 4)
print x[0, :, :].shape
(3, 4)
print x[0, :, idx].shape
(2, 3)
That looks like a bug to me. The length of the first dimension should be
the same.
What you are
On Feb 8, 2012, at 8:29 AM, Sturla Molden wrote:
On 08.02.2012 06:01, Travis Oliphant wrote:
Recall that the shape of the output with fancy indexing is determined by
broadcasting together the indexing objects and using that as the shape of
the output:
x[ind1, ind2] will produce
On Feb 8, 2012, at 11:17 AM, josef.p...@gmail.com wrote:
On Wed, Feb 8, 2012 at 10:29 AM, Sturla Molden stu...@molden.no wrote:
On 08.02.2012 15:49, Travis Oliphant wrote:
This sort of thing would take time, but is not out of the question in my
mind because I suspect the number of users
On Feb 8, 2012, at 4:19 PM, Robert Kern wrote:
On Wed, Feb 8, 2012 at 22:11, Travis Oliphant tra...@continuum.io wrote:
On Feb 8, 2012, at 11:17 AM, josef.p...@gmail.com wrote:
On Wed, Feb 8, 2012 at 10:29 AM, Sturla Molden stu...@molden.no wrote:
On 08.02.2012 15:49, Travis Oliphant
.
Best,
-Travis
On Feb 10, 2012, at 3:25 AM, David Cournapeau wrote:
On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant tra...@continuum.io wrote:
I think supporting Python 2.5 and above is completely fine
I propose to give Francesc Alted commit rights to the NumPy project. Francesc
will be working full time on NumPy for several months and it will enable him to
participate in pull requests.
Francesc Alted has been very active in the larger Python for Science community
and has written
How to people feel about moving the issue tracking for NumPy to Github?It
looks like they have improved their issue tracking quite a bit and the workflow
and integration with commits looks quite good from what I can see.
Here is one tool I saw that might help in the migration:
, at 2:06 PM, Benjamin Root wrote:
On Saturday, February 11, 2012, Travis Oliphant tra...@continuum.io wrote:
How to people feel about moving the issue tracking for NumPy to Github?
It looks like they have improved their issue tracking quite a bit and the
workflow and integration
be a good opportunity for others who
would like to get some experience with NumPy.
-Travis
On Feb 11, 2012, at 2:53 PM, Charles R Harris wrote:
On Sat, Feb 11, 2012 at 1:44 PM, Travis Oliphant tra...@continuum.io wrote:
This is good feedback.
It looks like there are 2 concerns
I'm wondering about using one of these commercial issue tracking plans for
NumPy and would like thoughts and comments.Both of these plans allow Open
Source projects to have unlimited plans for free.
YouTrack from JetBrains:
http://www.jetbrains.com/youtrack/features/issue_tracking.html
I think the following is what you want:
neighborhoods[range(9),perf[neighbourhoods].argmax(axis=1)]
-Travis
On Feb 13, 2012, at 1:26 PM, William Furnass wrote:
np.array( [neighbourhoods[i][perf[neighbourhoods].argmax(axis=1)[i]]
for i in xrange(neighbourhoods.shape[0])] )
On Mon, Feb 13, 2012 at 12:12 AM, Travis Oliphant tra...@continuum.io wrote:
I'm wondering about using one of these commercial issue tracking plans for
NumPy and would like thoughts and comments.Both of these plans allow Open
Source projects to have unlimited plans for free.
Free
Hmmm. This seems like a regression. The scalar casting API was fairly
intentional.
What is the reason for the change?
--
Travis Oliphant
(on a mobile)
512-826-7480
On Feb 13, 2012, at 6:25 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
I recently noticed a change
worked to stay true to the Numeric casting
rules incorporating the changes to prevent scalar upcasting due to the absence
of single precision Numeric literals in Python.
We will need to look in detail at what has changed. I will write a test to do
that.
Thanks,
Travis
--
Travis Oliphant
with all the possible discussions
that can take place :-) )
Best regards,
-Travis
On Feb 13, 2012, at 10:31 PM, Mark Wiebe wrote:
On Mon, Feb 13, 2012 at 8:04 PM, Travis Oliphant tra...@continuum.io wrote:
I disagree with your assessment of the subscript operator, but I'm sure we
On Feb 13, 2012, at 10:14 PM, Charles R Harris wrote:
On Mon, Feb 13, 2012 at 9:04 PM, Travis Oliphant tra...@continuum.io wrote:
I disagree with your assessment of the subscript operator, but I'm sure we
will have plenty of time to discuss that. I don't think it's correct to
compare
No argument on any of this. It's just that this needs to happen at NumPy
2.0, not in the NumPy 1.X series. I think requiring a re-compile is
far-less onerous than changing the type-coercion subtly in a 1.5 to 1.6
release. That's my major point, and I'm surprised others are
No argument on any of this. It's just that this needs to happen at NumPy
2.0, not in the NumPy 1.X series. I think requiring a re-compile is
far-less onerous than changing the type-coercion subtly in a 1.5 to 1.6
release. That's my major point, and I'm surprised others are
You might be right, Chuck. I would like to investigate more, however.
What I fear is that there are *a lot* of users still on NumPy 1.3 and NumPy
1.5. The fact that we haven't heard any complaints, yet, does not mean to
me that we aren't creating headache for people later who have
The lack of commutativity wasn't in precision, it was in the typecodes, and
was there from the beginning. That caused confusion. A current cause of
confusion is the many to one relation of, say, int32 and long, longlong which
varies platform to platform. I think that confusion is a more
For reference, here is the table that shows the actual changes between 1.5.1
and 1.6.1 at least on 64-bit platforms in terms of type-casting. I updated the
comparison code to throw out changes that are just spelling differences (i.e.
where 1.6.1 chooses to create an output dtype with an 'L'
Technically, when you write an extension module you really should use
import_array(); in the init method of the extensions module. This ensures
that the C-API is loaded so that the API -table is available if your C++ code
uses the C-API at all.
In this case you are just using some #defines
the
Foundation directors to evolve over time.
Best regards,
-Travis
regards,
David
On Tue, Feb 14, 2012 at 9:03 AM, Travis Oliphant tra...@continuum.io wrote:
For reference, here is the table that shows the actual changes between 1.5.1
and 1.6.1 at least on 64-bit platforms in terms
On Feb 14, 2012, at 7:04 AM, Henry Gomersall wrote:
On Mon, 2012-02-13 at 22:56 -0600, Travis Oliphant wrote:
But, I am also aware of *a lot* of users who never voice their opinion
on this list, and a lot of features that they want and need and are
currently working around the limitations
As you can see there were changes in each release. Most of these were
minor prior to the change from 1.5.1 to 1.6.1. I am still reviewing the
changes from 1.5.1 to 1.6.1.At first blush, it looks like there are a
lot of changes to swallow that are not necessarily minor.I really
- The packaging quagmire? This continues to be a problem, though
python3 does have new improvements to distutils. I'm not really up to
speed on the situation, to be frank. If we want to bring this up,
someone will have to provide a solid reference or volunteer to do it
in person.
I
There is a mailing list for numfocus that you can sign up for if you would
like to be part of those discussions. Let me know if you would like more
information about that.John Hunter, Fernando Perez, me, Perry
Greenfield, and Jarrod Millman are the initial board of the Foundation.
Travis, it's very good to see that the release manager role can be filled
going forward (it's not the most popular job), but I think the way it should
work is that people volunteer for this role and then the community agrees on
giving a volunteer that role.
I actually started
When we selected the name NumFOCUS just a few weeks ago, we created the list
for numfocus and then I signed everyone up for that list who was on the
other one. I apologize if anyone felt left out. That is not my
intention.
My point is that there are two ways go to about this
I have to agree with Mathew here, to a point. There has been discussions of
these groups before, but I don't recall any announcement of this group. Of
course, now that it has been announced, maybe a link to it should be
prominent on the numpy/scipy pages(maybe others?). It should also
Your points are well taken. However, my point is that this has been
discussed on an open mailing list. Things weren't *as* open as they could
have been, perhaps, in terms of board selection. But, there was opportunity
for people to provide input.
I am on the numpy, scipy,
It certainly would help people keep the NumPy web-site up to date. Thanks
Ognen.
-Travis
On Feb 15, 2012, at 7:18 AM, Ognen Duzlevski wrote:
On Wed, Feb 15, 2012 at 5:13 AM, Scott Sinclair
scott.sinclair...@gmail.com wrote:
On 8 February 2012 00:03, Travis Oliphant tra...@continuum.io
On Feb 15, 2012, at 9:17 AM, Charles R Harris wrote:
On Tue, Feb 14, 2012 at 1:24 PM, Ralf Gommers ralf.gomm...@googlemail.com
wrote:
On Tue, Feb 14, 2012 at 7:25 PM, Travis Oliphant tra...@continuum.io wrote:
On Feb 14, 2012, at 3:32 AM, David Cournapeau wrote:
Hi Travis
Yes, the PyArray_FromAny steals a reference to the dtype object. This is done
so you can build one on the fly doing something like
PyArray_DescrFromType(NPY_DOUBLE) inline with the PyArray_FromAny call.
-Travis
On Feb 15, 2012, at 4:23 PM, Larsen, Brian A wrote:
Hello all,
the
This has been a clarifying discussion for some people. I'm glad people are
speaking up. I believe in the value of consensus and the value of users
opinions.I want to make sure that people who use NumPy and haven't yet
learned how to contribute, feel like they have a voice. I have
Mark Wiebe and I have been discussing off and on (as well as talking with
Charles) a good way forward to balance two competing desires:
* addition of new features that are needed in NumPy
* improving the code-base generally and moving towards a more
maintainable NumPy
I know
here?
On Thu, Feb 16, 2012 at 1:11 PM, Travis Oliphant tra...@continuum.io wrote:
I'm not a big fan of design-by-committee as I haven't seen it be very
successful in creating new technologies. It is pretty good at enforcing
the status-quo. If I felt like that is what NumPy needed I would
The OS X slaves (especially PPC) are very valuable for testing.We have an
intern who could help keep the build-bots going if you would give her access to
those machines.
Thanks for being willing to offer them.
-Travis
On Feb 16, 2012, at 6:36 PM, Matthew Brett wrote:
Hi,
On Thu,
of things I see needed in the
code. The details will emerge in the coming weeks and months.
Thanks,
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Feb 18, 2012, at 3:46 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote:
On Thu, Feb 16, 2012 at 11:39 PM, Travis Oliphant tra
* NumPy 1.8 to come out in July which will have as many ABI-compatible
feature enhancements as we can add while improving test coverage and code
cleanup. I will post to this list more details of what we plan to address
with it later.Included for possible inclusion are:
On Feb 18, 2012, at 4:03 PM, Matthew Brett wrote:
Hi,
On Sat, Feb 18, 2012 at 1:57 PM, Travis Oliphant tra...@continuum.io wrote:
The C/C++ discussion is just getting started. Everyone should keep in mind
that this is not something that is going to happening quickly
The decision will not be made until NumPy 2.0 work is farther along. The
most likely outcome is that Mark will develop something quite nice in C++
which he is already toying with, and we will either choose to use it in
NumPy to build 2.0 on --- or not. I'm interested in sponsoring
I have written up a summary of my views here:
http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-porting-numpy-to-pypy.html
-Travis
On Feb 19, 2012, at 9:45 AM, xavier.gn...@gmail.com wrote:
Hi,
I'm trying to understand what's going on with :
Interesting you bring this up. I actually have a working prototype of using
Python to emit LLVM. I will be showing it at the HPC tutorial that I am
giving at PyCon.I will be making this available after PyCon to a wider
audience as open source.
It uses llvm-py (modified to work with
Hey all,
From what I can tell, the master branch is still ABI compatible with NumPy
1.7. Is that true?
I'd like to relabel the version of the master branch to 1.8.Does anyone see
any problems with that?
Thanks,
-Travis
___
Definitely!
Thanks for the reminder.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Feb 23, 2012, at 1:01 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote:
On Thu, Feb 23, 2012 at 3:37 AM, Travis Oliphant teoliph...@gmail.com wrote:
Hey all,
From what I can tell
This is actually on my short-list as well --- it just didn't make it to the
list.
In fact, we have someone starting work on it this week. It is his first
project so it will take him a little time to get up to speed on it, but he will
contact Wes and work with him and report progress to this
Hey all,
I would like to gather concrete information about NumPy users and have some
data to look at regarding the user base and features that are of interest.
We have been putting together a survey that I would love feedback on from
members of this list. If you have time and are
I will just let Jay know that he should coordinate with you.It would be
helpful for him to have someone to collaborate with on this.
I'm looking forward to seeing your code. Definitely don't hold back on our
account. We will adapt to whatever you can offer.
Best regards,
-Travis
On
The architecture of this system should separate the iteration across the I/O
from the transformation *on* the data. It should also allow the ability to
plug-in different transformations at a low-level --- some thought should go
into the API of the low-level transformation.Being able to
I just received word that NumPy has a license to use TeamCity and YouTrack for
NumPy development.
YouTrack is a really nice issue tracker: http://www.jetbrains.com/youtrack/
TeamCity is a really nice Continuous Integration system:
http://www.jetbrains.com/teamcity/
I'm planning to set
branch is some months away were it to happen.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Feb 28, 2012, at 9:51 PM, Fernando Perez fperez@gmail.com wrote:
On Tue, Feb 28, 2012 at 4:49 PM, Bryan Van de Ven bry...@continuum.io wrote:
Just my own $0.02 regarding this issue: I am
I Would like to hear the opinions of others on that point, but yes, I think
that is an appropriate procedure.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Feb 29, 2012, at 10:54 AM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Wed, Feb 29, 2012 at 1:46 AM, Travis
Hi all,
I've been thinking a lot about the masked array implementation lately. I
finally had the time to look hard at what has been done and now am of the
opinion that I do not think that 1.7 can be released with the current state of
the masked array implementation *unless* it is clearly
Mind, Mark only had a few weeks to write code. I think the unfinished state
is a direct function of that.
I have heard from several users that they will *not use the missing data* in
NumPy as currently implemented, and I can now see why.For better or for
worse, my approach to
The place this is used inside of setup.py is here:
https://github.com/numpy/numpy/blob/master/numpy/core/setup.py#L14
I really dislike this build feature, it repeatedly trips me up. In my
opinion, the build should be changed to always do separate compilation, and
the single file mode
.
Travis
--
Travis Oliphant
(on a mobile)
512-826-7480
On Mar 6, 2012, at 8:07 AM, David Cournapeau courn...@gmail.com wrote:
On Tue, Mar 6, 2012 at 6:20 AM, Robert Kern robert.k...@gmail.com wrote:
On Tue, Mar 6, 2012 at 03:53, David Cournapeau courn...@gmail.com wrote:
Hi
Hey all,
I gave a lightning talk this morning on numba which is the start of a Python
compiler to machine code through the LLVM tool-chain. It is proof of concept
stage only at this point (use it only if you are interested in helping develop
the code at this point). The only thing that
On Mar 11, 2012, at 1:59 AM, Mic wrote:
what is the difference to http://www.python.org/dev/peps/pep-3146/ ?
To fully expound the difference would take a lot of discussion. But,
summarizing:
* Numba is not nearly as ambitious as US (Numba will be fine with some
user-directed
On Mar 13, 2012, at 12:58 AM, Dag Sverre Seljebotn wrote:
On 03/10/2012 10:35 PM, Travis Oliphant wrote:
Hey all,
I gave a lightning talk this morning on numba which is the start of a
Python compiler to machine code through the LLVM tool-chain. It is proof
of concept stage only
(Mark F., how does the above match how you feel about this?)
I would like collaboration, but from a technical perspective I think
this would be much more involved than just dumping the AST to an IR
and generating some code from there. For vector expressions I think
sharing code would be
On Mar 21, 2012, at 11:48 PM, Yan Tang wrote:
Hi,
I am really confused on the np array or record array, and cannot understand
how it works.
What I want to do is that I have a normal python two dimensional array/list:
a = [['2000-01-01', 2],['2000-01-02', 3]]
I want to convert it
While namespaces are a really good idea, I'm not a big fan of both module
namespaces and underscore namespaces. It seems pretty redundant to me to have
pad.pad_mean.
On the other hand, one could argue that pad.mean could be confused with
calculating the mean of a padded array. So, it
On Mar 29, 2012, at 11:52 AM, Nathaniel Smith wrote:
On Thu, Mar 29, 2012 at 5:38 PM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Mar 29, 2012 at 5:13 PM, Travis Oliphant tra...@continuum.io wrote:
While namespaces are a really good idea, I'm not a big fan of both module
namespaces
On Mar 29, 2012, at 12:53 PM, Tim Cera wrote:
I was hoping pad would get finished some day. Maybe 1.9?
You have been a great sport about this process. I think it will result in
something quite nice.
Alright - I do like the idea of passing a function to pad, with a bunch of
The idea is to allow people to test-out YouTrack for a few weeks and get to
know it while we migrate bugs to it. it looks like it is straightforward to
export the data out of YouTrack should we eventually decide to use something
else.
The idea is to host it on an external server (Rackspace
The idea of using constants instead of strings throughout NumPy is an
interesting one, but should be pushed to another thread and not hold up this
particular PR.
I like the suggestion of Nathaniel. Let's get the PR committed with a
single-function interface. I like having the array as the
I like the strings, maybe that is not the best, but yes I would like to defer
that discussion. Having the string representation does allow 'pad()' to make
some checks on inputs to the built in functions.
About whether to have pad('mean', a, 5) or pad(a, 'mean', 5) - I don't
care. It
On the one hand it is nice to be explicit. On the other hand it is nice to
have keyword arguments.
In this case it is very true that pad(a) would not be very clear. Most clear,
though, would be: pad(a, width=5, mode='mean'). You could use keyword
arguments with None as the default and
The plan is use a different issue tracker. We are trying out YouTrack right
now and hope to export the Trac database into YouTrack.
-Travis
the plOn Apr 2, 2012, at 3:16 PM, Pauli Virtanen wrote:
31.03.2012 18:19, Pauli Virtanen kirjoitti:
I moved projects.scipy.org Tracs to run on
,
02.04.2012 22:47, Travis Oliphant kirjoitti:
The plan is use a different issue tracker.
We are trying out YouTrack right now and hope to
export the Trac database into YouTrack.
Certainly, I'm aware :)
However, was the plan to also migrate the Scipy Trac? I understood the
answer
Which version of NumPy are you using. This could be an artefact of the new
casting rules.
This used to work. So, yes, this is definitely a bug.
-Travis
On Apr 5, 2012, at 10:54 PM, Chris Laumann wrote:
Hi all-
I've been trying to use numpy arrays of ints as arrays of bit fields
, 2012, at 12:45 AM, Charles R Harris wrote:
On Thu, Apr 5, 2012 at 11:39 PM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Thu, Apr 5, 2012 at 11:16 PM, Travis Oliphant tra...@continuum.io wrote:
Which version of NumPy are you using. This could be an artefact of the new
casting
1 - 100 of 678 matches
Mail list logo
