Re: [Numpy-discussion] Long term plans for dropping Python 2.7

[CJ Carey]

What do we think about the trade-offs of having a shared 2.7/3.x codebase
going forward?

As Python3 adds more nontrivial features, keeping compatibility with 2.7
becomes more burdensome.

Will there be a separate py2-numpy branch/repo at some point before ending
support?


On Apr 15, 2017 4:48 AM, "Julian Taylor" 
wrote:

> On 15.04.2017 02:19, Charles R Harris wrote:
> > Hi All,
> >
> > It may be early to discuss dropping support for Python 2.7, but there is
> > a disturbance in the force that suggests that it might be worth looking
> > forward to the year 2020 when Python itself will drop support for 2.7.
> > There is also a website, http://www.python3statement.org
> > , where several projects in the
> > scientific python stack have pledged to be Python 2.7 free by that
> > date.  Given that, a preliminary discussion of the subject might be
> > interesting, if only to gather information of where the community
> > currently stands.
> >
> > Chuck
> >
> >
>
> I am very against planning to drop it.
> Numpy is the lowest part of the scipy stack so it is not our decision to
> do so and we don't gain that much by doing so.
> Lets discuss this in 3 years or when the distributions kick out
> python2.7 (which won't happen before ~2022). There is no point doing so
> now.
> Also PyPy does not plan on dropping 2.7 by that time.
>
> Also before we even consider this we need to fix our python3 support.
> This means getting the IO functions
> (https://github.com/numpy/numpy/pull/4208) in order and adding a string
> type that people are less reluctant to use than the 4 byte unicode we
> currently offer.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] proposed changes to array printing in 1.14

[CJ Carey]

Is it feasible/desirable to provide a doctest runner that ignores
whitespace? That would allow downstream projects to fix their doctests on
1.14+ with a one-line change, without breaking tests on 1.13.

On Fri, Jun 30, 2017 at 11:11 AM, Allan Haldane 
wrote:

> On 06/30/2017 03:55 AM, Juan Nunez-Iglesias wrote:
>
>> To reiterate my point on a previous thread, I don't think this should
>> happen until NumPy 2.0. This *will* break a massive number of doctests, and
>> what's worse, it will do so in a way that makes it difficult to support
>> doctesting for both 1.13 and 1.14. I don't see a big enough benefit to
>> these changes to justify breaking everyone's tests before an API-breaking
>> version bump.
>>
>
> I am still on the fence about exactly how annoying this change would be,
> and it is is good to hear whether this affects you and how badly.
>
> Yes, someone would have to spend an hour removing a hundred spaces in
> doctests, and the 1.13 to 1.14 period is trickier (but virtualenv helps).
> But none of your end users are going to have their scripts break, there are
> no new warnings or exceptions.
>
> A followup questions is, to what degree can we compromise? Would it be
> acceptable to skip the big change #1, but keep the other 3 changes? I
> expect they affect far fewer doctests. Or, for instance, I could scale back
> #1 so it only affects size-1 (or perhaps, only size-0) arrays. What amount
> of change would be OK, and how is changing a small number of doctests
> different from changing more?
>
> Also, let me clarify the motivations for the changes. As Marten noted,
> change #2 is what motivated all the other changes. Currently 0d arrays
> print in their own special way which was making it very hard to implement
> fixes to voidtype str/repr, and the datetime and other 0d reprs are weird.
> The fix is to make 0d arrays print using the same code-path as higher-d
> ndarrays, but then we ended up with reprs like "array( 1.)" because of the
> space for the sign position. So I removed the space from the sign position
> for all float arrays. But as I noted I probably could remove it for only
> size-1 or 0d arrays and still fix my problem, even though I think it might
> be pretty hacky to implement in the numpy code.
>
> Allan
>
>
>
>
>
>> On 30 Jun 2017, 6:42 AM +1000, Marten van Kerkwijk <
>> m.h.vankerkw...@gmail.com>, wrote:
>>
>>> To add to Allan's message: point (2), the printing of 0-d arrays, is
>>> the one that is the most important in the sense that it rectifies a
>>> really strange situation, where the printing cannot be logically
>>> controlled by the same mechanism that controls >=1-d arrays (see PR).
>>>
>>> While point 3 can also be considered a bug fix, 1 & 4 are at some
>>> level matters of taste; my own reason for supporting their
>>> implementation now is that the 0-d arrays already forces me (or,
>>> specifically, astropy) to rewrite quite a few doctests, and I'd rather
>>> have everything in one go -- in this respect, it is a pity that this
>>> is separate from the earlier change in printing for structured arrays
>>> (which was also much for the better, but broke a lot of doctests).
>>>
>>> -- Marten
>>>
>>>
>>>
>>> On Thu, Jun 29, 2017 at 3:38 PM, Allan Haldane 
>>> wrote:
>>>
 Hello all,

 There are various updates to array printing in preparation for numpy
 1.14. See https://github.com/numpy/numpy/pull/9139/

 Some are quite likely to break other projects' doc-tests which expect a
 particular str or repr of arrays, so I'd like to warn the list in case
 anyone has opinions.

 The current proposed changes, from most to least painful by my
 reckoning, are:

 1.
 For float arrays, an extra space previously used for the sign position
 will now be omitted in many cases. Eg, `repr(arange(4.))` will now
 return 'array([0., 1., 2., 3.])' instead of 'array([ 0., 1., 2., 3.])'.

 2.
 The printing of 0d arrays is overhauled. This is a bit finicky to
 describe, please see the release note in the PR. As an example of the
 effect of this, the `repr(np.array(0.))` now prints as 'array(0.)`
 instead of 'array(0.0)'. Also the repr of 0d datetime arrays is now like
 "array('2005-04-04', dtype='datetime64[D]')" instead of
 "array(datetime.date(2005, 4, 4), dtype='datetime64[D]')".

 3.
 User-defined dtypes which did not properly implement their `repr` (and
 `str`) should do so now. Otherwise it now falls back to
 `object.__repr__`, which will return something ugly like
 ``. (Previously you could depend on
 only implementing the `item` method and the repr of that would be
 printed. But no longer, because this risks infinite recursions.).

 4.
 Bool arrays of size 1 with a 'True' value will now omit a space, so that
 `repr(array([True]))` is now 'array([True])' instead of
 'array([ True])'.

 Allan
 ___
>

Re: [Numpy-discussion] Interface numpy arrays to Matlab?

[CJ Carey]

Looks like Transplant can handle this use-case.

Blog post: http://bastibe.de/2015-11-03-matlab-engine-performance.html
GitHub link: https://github.com/bastibe/transplant

I haven't given it a try myself, but it looks promising.

On Mon, Aug 28, 2017 at 4:21 PM, Stephan Hoyer  wrote:

> If you can use Octave instead of Matlab, I've had a very good experience
> with Oct2Py:
> https://github.com/blink1073/oct2py
>
> On Mon, Aug 28, 2017 at 12:20 PM, Neal Becker  wrote:
>
>> I've searched but haven't found any decent answer.  I need to call Matlab
>> from python.  Matlab has a python module for this purpose, but it doesn't
>> understand numpy AFAICT.  What solutions are there for efficiently
>> interfacing numpy arrays to Matlab?
>>
>> Thanks,
>> Neal
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] argmax() indexes to value

[CJ Carey]

You could move some of the cost to index-creation time by converting the
per-row indices into flattened indices:

In [1]: a = np.random.random((5, 6))


In [2]: i = a.argmax(axis=1)


In [3]: a[np.arange(len(a)), i]

Out[3]: array([0.95774465, 0.90940106, 0.98025448, 0.97836906, 0.80483784])

In [4]: f = np.ravel_multi_index((np.arange(len(a)), i), a.shape)


In [5]: a.flat[f]

Out[5]: array([0.95774465, 0.90940106, 0.98025448, 0.97836906, 0.80483784])


I haven't benchmarked, but I suspect this will be faster if you're using
the same index multiple times.
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Indexing question

[CJ Carey]

Or as a one-liner:

out[np.arange(len(x)), x] = 1

If NEP 21 is accepted (
https://numpy.org/neps/nep-0021-advanced-indexing.html) this would be even
simpler:

out.vindex[:, x] = 1

Was there ever a decision about that NEP? I didn't follow the discussion
too closely at the time.

On Thu, May 20, 2021 at 10:06 AM Neal Becker  wrote:

> Thanks!
>
> On Thu, May 20, 2021 at 9:53 AM Robert Kern  wrote:
> >
> > On Thu, May 20, 2021 at 9:47 AM Neal Becker  wrote:
> >>
> >> This seems like something that can be done with indexing, but I
> >> haven't found the solution.
> >>
> >> out is a 2D array is initialized to zeros.  x is a 1D array whose
> >> values correspond to the columns of out.  For each row in out, set
> >> out[row,x[row]] = 1.  Here is working code:
> >> def orthogonal_mod (x, nbits):
> >> out = np.zeros ((len(x), 1< >> for e in range (len (x)):
> >> out[e,x[e]] = 1
> >> return out
> >>
> >> Any idea to do this without an explicit python loop?
> >
> >
> >
> > i = np.arange(len(x))
> > j = x[i]
> > out[i, j] = 1
> >
> > --
> > Robert Kern
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
>
> --
> Those who don't understand recursion are doomed to repeat it
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion