[Numpy-discussion] Created NumPy 1.7.x branch

[josef.pktd at gmail.com]

On Mon, Jun 25, 2012 at 8:25 PM,  <josef.pktd at gmail.com> wrote:
> On Mon, Jun 25, 2012 at 8:10 PM, Travis Oliphant <travis at continuum.io> 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
>> entirely.
>
> 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.

just to add a bit more information, given the existence of both poly's

nobody had to rewrite  flipping order in scipy.signal.residuez
    b, a = map(asarray, (b, a))
    gain = a[0]
    brev, arev = b[::-1], a[::-1]
    krev, brev = polydiv(brev, arev)
    if krev == []:
        k = []
    else:
        k = krev[::-1]
    b = brev[::-1]

while my arma_process class can start at the same time with
    def __init__(self, ar, ma, nobs=None):
        self.ar = np.asarray(ar)
        self.ma = np.asarray(ma)
        self.arpoly = np.polynomial.Polynomial(self.ar)
        self.mapoly = np.polynomial.Polynomial(self.ma)

As a downstream user of numpy and observer of the mailing list for a
few years, I think the gradual improvements have gone down pretty
well. At least I haven't seen any mayor complaints on the mailing
list.

For me, the big problem was numpy 1.4.0 where several packages where
not available because of binary compatibility, NaN's didn't concern me
much, current incomplete transition to new MinGW and gcc is currently
a bit of a problem.

Purely as an observer, my impression was also that the internal numpy
c source cleanup, started by David C., I guess, didn't cause any big
problems that would have created lots of complaints on the numpy
mailing list.

Josef

>
> Josef
>
>>
>> --
>> Travis Oliphant
>> (on a mobile)
>> 512-826-7480
>>
>>
>> On Jun 25, 2012, at 7:01 PM, Charles R Harris <charlesr.harris at gmail.com>
>> wrote:
>>
>>
>>
>> On Mon, Jun 25, 2012 at 4:21 PM, Perry Greenfield <perry at stsci.edu> wrote:
>>>
>>>
>>> On Jun 25, 2012, at 3:25 PM, Charles R Harris wrote:
>>>
>>> >
>>> >
>>> > On Mon, Jun 25, 2012 at 11:56 AM, Perry Greenfield <perry at 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 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.
>>
>> Chuck
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>