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 at
=*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
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 tak
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
> wrote:
>
>> I am starting
On Jun 25, 2012, at 3:25 PM, Charles R Harris wrote:
>
>
> On Mon, Jun 25, 2012 at 11:56 AM, Perry Greenfield
> 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
>
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
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, 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 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 th
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
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
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 W
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
> cons
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
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 think
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 cor
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
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:
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 u
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
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
>>
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
. If this is what you mean by style changes and it ends
up changing array to Array and int32 to Int32, it's not just a style
change, it will break 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.
consistency at it's worst. We *just* 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 yo
't available in numpy,
and only in odd ways in numarray--and it was a bug there [I feel I
can say that without contradiction :-)]. Now that the compatibility
can of worms is open, fixing this is a small thing compared to the
other issue being raised.
Perry Greenfield
___
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 g
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/),
On May 11, 2007, at 9:56 AM, Gary Ruben wrote:
> This is great Perry,
>
> I think this will help to convince our department's astronomer(s) to
> learn and maybe use Python for teaching.
> By the way, if you do a global search for "numarray" in your document,
> you'll pick up a few pieces of uncha
On May 11, 2007, at 1:06 PM, Anne Archibald wrote:
> On 10/05/07, Perry Greenfield <[EMAIL PROTECTED]> wrote:
>> I have updated the "Using Python for Interactive Data Analysis"
>> tutorial to use numpy instead of numarray (finally!). There are
>> further imp
I have updated the "Using Python for Interactive Data Analysis"
tutorial to use numpy instead of numarray (finally!). There are
further improvements I would like to make in its organization and
formatting (in the process including suggestions others have made to
that end), but I'd rather ge
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
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 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
(e.g., 50 elements, it's all overhead. In that size
range, lists will usually be much faster.
Perry Greenfield
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.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
A few comments regarding what I think justifies some sort of standard
to be part of Python (understanding that there are various ways that
it could be done, so I'm not commenting on the specifics here directly).
I don't there is any harm in making the standard numpy-centric. In
fact, I think
36 matches
Mail list logo
