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
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
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
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 :
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
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,
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
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,
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
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
.
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
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
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
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
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
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
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
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
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 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,
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
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
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
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
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
-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
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
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
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
On Oct 29, 2011, at 7:24 PM, Eric Firing wrote:
On 10/29/2011 12:57 PM, Charles R Harris wrote:
On Sat, Oct 29, 2011 at 4:47 PM, Eric Firing efir...@hawaii.edu
mailto:efir...@hawaii.edu wrote:
On 10/29/2011 12:02 PM, Olivier Delalleau wrote:
I haven't been following the
___
NumPy-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
is the counter-argument to this proposal?
-Travis
On Oct 27, 2011, at 7:31 PM, Matthew Brett wrote:
Hi,
On Tue, Oct 25, 2011 at 7:56 PM, Travis Oliphant oliph...@enthought.com
wrote:
So, I am very interested in making sure I remember the details of the
counterproposal.What I recall
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-Discussion@scipy.org
http
for everybody!
Cheers!
Ben Root
___
NumPy-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
, Travis Oliphant oliph...@enthought.com
wrote:
It is a shame that Nathaniel and perhaps Matthew do not feel like their
voice was heard. I wish I could have participated more fully in some of
the discussions. I don't know if I could have really helped, but I would
have liked to have tried
Hi all,
At the recent US SciPy conference and at other times in the past I have been
approached about the possibility of creating a foundation to support the
development of SciPy and NumPy.
I know there are varying opinions about that, but I am generally very
supportive of the idea and would
to legal matters: starting your own non-profit is
to joining an existing umbrella non-profit as CVS is to git. (And in
fact git is also a SF Conservancy member.)
My $0.02,
-- Nathaniel
On Tue, Oct 4, 2011 at 1:58 PM, Travis Oliphant teoliph...@gmail.com wrote:
Hi all,
At the recent US SciPy
Hi all,
Has there been a discussion of a 1.7.x release of NumPy? There are a few
new features that should go into the 1.x release of NumPy, that don't require
the ABI changes of 2.0.I thought I had heard Mark talk in support of such a
thing.
What are the plans for the release of
___
NumPy-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-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
@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-Discussion@scipy.org
http://mail.scipy.org
there is a difference.
Konrad.
___
NumPy-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
Hi all,
I want to first apologize for stepping into this discussion a bit late and for
not being able to participate adequately. However, I want to offer a couple
of perspectives, and my opinion about what we should do as well as clarify what
I have instructed Mark to do as part of his
___
NumPy-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
--
Dr. Edward Schofield
Python Charmers
+61 (0)405 676 229
http://pythoncharmers.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
---
Travis Oliphant
Enthought, Inc.
oliph
.
___
NumPy-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
-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-Discussion
On Apr 11, 2011, at 3:55 PM, Charles R Harris wrote:
On Mon, Apr 11, 2011 at 2:31 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Mon, Apr 11, 2011 at 12:37 PM, Robert Kern robert.k...@gmail.com wrote:
On Mon, Apr 11, 2011 at 13:54, Skipper Seabold jsseab...@gmail.com wrote:
All,
We
___
NumPy-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
---
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/listinfo/numpy-discussion
testing on 64-bit Windows would be great, that usually
turns up new issues so the sooner the better.
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
---
Travis Oliphant
://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-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
I like the thoughts on core-architecture. These are all things that we were
not able to do as part of the NumPy for .NET discussions, but with the right
interested parties could be acted upon.
I like the lower two levels if, as I assume, they are basically aimed at
allocating,
, etc.) to be
incorporated in the generalized calculation structure.
-Travis
On Jan 28, 2011, at 9:25 AM, Lluís wrote:
Travis Oliphant writes:
This concept has as one use-case, the deferred arrays that Mark Wiebe
has proposed.
Interesting, I didn't read about that.
In fact, I
301 - 400 of 678 matches
Mail list logo
