[Numpy-discussion] Created NumPy 1.7.x branch
Mon Jun 25 19:25:54 CDT 2012
On Mon, Jun 25, 2012 at 8:10 PM, Travis Oliphant <firstname.lastname@example.org> wrote:
> You are still missing the point that there was already a choice that was
> made in the previous class --- made in Numeric actually.
> You made a change to that. It is the change that is 'gratuitous'. The pain
> and unnecessary overhead of having two competing standards is the problem
> --- not whether one is 'right' or not. That is a different discussion
I remember there was a discussion about the order of the coefficients
on the mailing list and all in favor of the new order, IIRC. I cannot
find the thread. I know I was.
At least I'm switching pretty much to the new polynomial classes, and
don't really care about the inherited choice before that any more.
So, I'm pretty much in favor of updating, if new choices are more
convenient and more familiar to new users.
> Travis Oliphant
> (on a mobile)
> On Jun 25, 2012, at 7:01 PM, Charles R Harris <email@example.com>
> On Mon, Jun 25, 2012 at 4:21 PM, Perry Greenfield <firstname.lastname@example.org> wrote:
>> On Jun 25, 2012, at 3:25 PM, Charles R Harris wrote:
>> > On Mon, Jun 25, 2012 at 11:56 AM, Perry Greenfield <email@example.com>
>> > 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 involved in developing them, and for which it is
>> > particularly difficult to break away. But there are plenty of other
>> > areas where it isn't that hard.
>> > I'd characterize the process a bit differently. I would agree that it
>> > is pretty hard to get someone who has been using matlab or IDL for
>> > many years to transition. That doesn't happen very often (if it does,
>> > it's because all the other people they work with are using a different
>> > tool and they are forced to). I think we are targeting the younger
>> > people; those that do not have a lot of experience tied up in matlab
>> > or IDL. For example, IDL is very well established in astronomy, and
>> > we've seen few make that switch if they already have been using IDL
>> > for a while. But we are seeing many more younger astronomers choose
>> > Python over IDL these days.
>> > I didn't bring up the Astronomy experience, but I think that is a
>> > special case because it is a fairly small area and to some extent
>> > you had the advantage of a supported center, STSci, maintaining some
>> > software. There are also a lot of amateurs who can appreciate the
>> > low costs and simplicity of Python.
>> > The software engineers use tends to be set early, in college or in
>> > their first jobs. I suspect that these days professional astronomers
>> > spend a number of years in graduate school where they have time to
>> > experiment a bit. That is a nice luxury to have.
>> Sure. But it's not unusual for an invasive technology (that's us) to
>> take root in certain niches before spreading more widely.
>> Another way of looking at such things is: is what we are seeking to
>> replace that much worse? If the gains are marginal, then it is very
>> hard to displace. But if there are significant advantages, eventually
>> they will win through. I tend to think Python and the scientific stack
>> does offer the potential for great advantages over IDL or matlab. But
>> that doesn't make it easy.
> I didn't say we couldn't make inroads. The original proposition was that we
> needed a polynomial class compatible with Matlab. I didn't think
> compatibility with Matlab mattered so much in that case because not many
> people switch, as you have agreed is the case, and those who start fresh, or
> are the adventurous sort, can adapt without a problem. In other words, IMHO,
> it wasn't a pressing issue and could be decided on the merits of the
> interface, which I thought of in terms of series approximation. In
> particular, it wasn't a 'gratuitous' choice as I had good reasons to do
> things the way I did.
> NumPy-Discussion mailing list
> NumPy-Discussion mailing list
More information about the NumPy-Discussion