I'm not sure I'm crazy about leaving final decision making for a
board. A board may be a good way of carefully considering the issues,
and it could make it's own recommendation (with a sufficient
majority). But in the end I think one person needs to decide (and that
decision may go against
On Feb 15, 2012, at 3:01 PM, Matthew Brett wrote:
[...]
My 2 cents.
I think you put too much faith in formal systems. There are plenty of
examples of formal governance that fail miserably. In the end it
depends on the people and their willingness to continue cooperating.
Formal governance
On Feb 15, 2012, at 6:18 PM, Joe Harrington wrote:
Of course, balancing all of this (and our security blanket) is the
possibility of someone splitting the code if they don't like how
Continuum runs things. Perry, you've done that yourself to this
code's
predecessor, so you know the
I, like Travis, have my worries about C++. But if those actually doing
the work (and particularly the subsequent support) feel it is the best
language for implementation, I can live with that.
I particularly like the incremental and conservative approach to
introducing C++ that was proposed
On May 3, 2012, at 1:38 PM, Moroney, Catherine M (388D) wrote:
On May 3, 2012, at 10:33 AM, Moroney, Catherine M (388D) wrote:
A quick recap of the problem: a 128x512 array of 7-element vectors
(element), and a 5000-vector
training dataset (targets). For each vector in element, I want
On Jun 25, 2012, at 12:20 PM, Charles R Harris wrote:
Most folks aren't going to transition from MATLAB or IDL.
Engineers tend to stick with the tools they learned in school,
they aren't interested in the tool itself as long as they can get
their job done. And getting the job done is
On Jun 25, 2012, at 3:25 PM, Charles R Harris wrote:
On Mon, Jun 25, 2012 at 11:56 AM, Perry Greenfield pe...@stsci.edu
wrote:
It's hard to generalize that much here. There are some areas in what
you say is true, particularly if whole industries rely on libraries
that have much time
I'd like to echo what Chris is saying. It was a big annoyance with Numeric to
make it so hard to preserve the array type in ordinary expressions.
Perry
On Jan 17, 2013, at 8:04 PM, Chris Barker - NOAA Federal wrote:
On Thu, Jan 17, 2013 at 6:26 AM, Matthew Brett matthew.br...@gmail.com
We at STScI have no objection. If we have any residual dependencies, we'll then
find out and fix them.
Perry
On Sep 23, 2013, at 1:03 PM, Charles R Harris wrote:
Hi All,
I have gotten no feedback on the removal of the numarray and oldnumeric
packages. Consequently the removal will take
=*5ECC2DFF67015263
(applications are still being taken despite the date given…)
Perry Greenfield
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Feb 28, 2007, at 7:32 PM, Joe Harrington wrote:
Hi Steve,
I have taught Astronomical Data Analysis twice at Cornell using IDL,
and I will be teaching it next Fall at UCF using NumPy. Though I've
been active here in the recent past, I'm actually not a regular NumPy
user myself yet (I
faster.
Perry Greenfield
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
On Mar 24, 2007, at 2:52 PM, Bill Baxter wrote:
On 3/24/07, Steven H. Rogers [EMAIL PROTECTED] wrote:
Anne Archibald wrote:
P.S. reduce isn't even a numpy thing, it's one of python's
much-neglected lispy functions.
It looks like reduce(), map(), and filter() are going away for Python
Great!
On Mar 26, 2007, at 4:52 PM, Travis Oliphant wrote:
I've finally made the changes to fix the scalar coercion model
problems
in NumPy 1.0.1
Now, scalar coercion rules only apply when involved types are of the
same basic kind.
[...]
___
On Apr 18, 2007, at 2:14 PM, Sturla Molden wrote:
[...]
Let us assume again we have an expression like
y = a * b + c * d
where a,b,c and d are all arrays or matrices. In this case, the
overloaded * and + operators woud not return a temporary array but an
unevaluated expression of class
On Jul 16, 2007, at 9:13 AM, Yannick Copin wrote:
Hi,
I'd be interested in some astronomical utilities from the IDL
Astronomy User's
Library (http://idlastro.gsfc.nasa.gov/contents.html) converted to
python/numpy. I had a look to idl2python
(http://software.pseudogreen.org/i2py/), but
On Jul 16, 2007, at 1:19 PM, W.T. Bridgman wrote:
Perry,
I believe some of those documents are getting a bit dated. They
still refer to only supporting numarray vs Numeric. Don't those need
to be updated to specify numpy?
Yes, that's certainly true. Having said that, it's probably going
* went through the
exercise of changing Int32 to int32 and so forth and we would have to
change back again? This cannot be seriously considered.
Perry Greenfield
On Oct 2, 2007, at 1:24 PM, Jarrod Millman wrote:
Hello,
For those of you not on the Numpy developer's list, we have been
lots of code (Since it should effect the user
API...). These are API changes even if you consider case of the
class name just style.
Perry Greenfield
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman
On Oct 3, 2007, at 2:26 PM, Jarrod Millman wrote:
3) Greater time should be provided to accommodate the transition. For
example, there should not be deprecation warnings in the first
version that this API appears in. The first release of this should
not lead to nuisance messages for those
On Feb 13, 2010, at 11:24 AM, Charles R Harris wrote:
Hi All,
Since there has been talk of deprecating the numarray and numeric
compatibility
Can someone be explicit about what is mean by this deprecation?
parts of numpy for the upcoming 2.0 release I thought maybe we could
consider
We are advertising for two different positions at the Space Telescope
Science Institute (located on the Johns Hopkins University Campus in
Baltimore, Md). STScI is seeking Senior Systems Software Engineers to
develop applications to calibrate and analyze data from the Hubble and
the James
On Apr 7, 2008, at 2:29 PM, Robert Kern wrote:
On Mon, Apr 7, 2008 at 11:19 AM, Bruce Southey [EMAIL PROTECTED]
wrote:
Hi,
I think that splitting the NumPy namespace should not happen
within a
major release series because it would cause too many breakages.
Rather
it should be
On Apr 7, 2008, at 5:54 PM, Brian Granger wrote:
The only problem is that if we keep adding things to numpy that could
be in scipy, it will _never_ be clear to users where they can expect
to find things. It is already bad enough. How do I explain to a
user/student/scientist that ffts and
Hi Chris,
Didn't we remove all dependence on recarray? I could have sworn we
did that.
Perry
On Jun 26, 2008, at 12:45 PM, Christopher Hanley wrote:
Travis E. Oliphant wrote:
Stéfan van der Walt wrote:
Hi all,
I am documenting `recarray`, and have a question:
Is its use still
When you slice an array, you keep the original array in memory until
the slice is deleted. The slice uses the original array memory and is
not a copy. The second example explicitly makes a copy.
Perry
On Oct 15, 2008, at 2:31 PM, emil wrote:
Huang-Wen Chen wrote:
Robert Kern wrote:
On Oct 22, 2008, at 5:15 PM, Robert Kern wrote:
I would add another position (my own) to the Arguments neutral
towards or against the PEP:
* I really only care about having just *one* extra operator, one that
I can (ab)use for matrix multiplication. It's the only operation that
is common
On Nov 24, 2008, at 5:55 PM, Jarrod Millman wrote:
On Mon, Nov 24, 2008 at 10:45 AM, Francesc Alted
[EMAIL PROTECTED] wrote:
So, IMHO, I think it would be better to rename the inverse
trigonometric
functions from ``arc*`` to ``a*`` prefix. Of course, in order to do
that correctly, one
Hi Russell,
Have you looked at the example in our interactive data analysis
tutorial where we compute radial profiles in Python? It's not as fast
as C because of the sort, but perhaps that's fast enough for your
purposes. I wasn't sure if you had already seen that approach or not.
(I
Note that NaN generally contaminates sums and other net results (as it
should). You should filter them out (there is more than one way to do
that). But also note that the IEEE standard for floating point numbers
requires NaN != Nan. Thus any attempts to find where NaNs that way is
destined
I’ve also stayed out of this until now. I’m surprised and disheartened at the
amount of suspicion and distrust directed towards Travis. I don’t think anyone
has invested as much personal time and resources (e.g., money) towards
supporting numpy, and not just in creating it but through efforts
31 matches
Mail list logo
