Re: [Numpy-discussion] Roadmap proposal, v3

[Ralf Gommers]

On Thu, Jul 26, 2018 at 12:41 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> > Obviously the string dtype proposal in the roadmap is only a sketch at
> this point :).
> >
> > I do think that options listed currently (encoded strings with
> fixed-width storage and variable length strings) cover the breadth of
> proposals from last time. We may not want to implement all of them in
> NumPy, but I think we can agree that there are use cases for all them, even
> if only as external dtypes?
>
> Maybe :-) — but I totally agree that more complete handling of strings
> should be on the roadmap.
>
> > Would it help to add "and/or" after the first bullet? Mostly I care
> about having like to have "improve string dtypes" in some form on the
> roadmap, and thought it would be helpful to list the concrete proposals
> that I recall.
>
> Sure, something like and/or that makes it clear that the details are
> yet to be determined would be great.
>
> > The actual design choices (especially if we proposal to change any
> default behavior) will certainly need a NEP.
>

+1 the roadmap just contains topics/directions of interest. It's not the
place for any technical decisions.

Related note: we are now using the "wish list" issue label for anything
that is too small to put on a roadmap or write a NEP for. Right now there's
a lot of random stuff in that label though ([1]), so I think we have to
clean that up. Examples of good wish list items that are on there now:

- Document API generation with setup.py, genapi.py, etc. (gh-9203)
- Feature request: signal broadcasting is OK over core dimension (gh-8811)
- Multidimensional fftfreq/rfftfreq (gh-9094)

I plan to go through and remove the label from issues that don't fit in the
next couple of days.

Cheers,
Ralf

[1]
https://github.com/numpy/numpy/issues?q=is%3Aopen+is%3Aissue+label%3A%2223+-+Wish+List%22
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Roadmap proposal, v3

[Chris Barker - NOAA Federal]

> Obviously the string dtype proposal in the roadmap is only a sketch at this 
> point :).
>
> I do think that options listed currently (encoded strings with fixed-width 
> storage and variable length strings) cover the breadth of proposals from last 
> time. We may not want to implement all of them in NumPy, but I think we can 
> agree that there are use cases for all them, even if only as external dtypes?

Maybe :-) — but I totally agree that more complete handling of strings
should be on the roadmap.

> Would it help to add "and/or" after the first bullet? Mostly I care about 
> having like to have "improve string dtypes" in some form on the roadmap, and 
> thought it would be helpful to list the concrete proposals that I recall.

Sure, something like and/or that makes it clear that the details are
yet to be determined would be great.

> The actual design choices (especially if we proposal to change any default 
> behavior) will certainly need a NEP.

Then that will be the place to hash out the details — perfect.

I just got a little concerned that s not-well vetted solution was
getting nailed down in the roadmap.

-CHB
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Roadmap proposal, v3

[Stephan Hoyer]

On Wed, Jul 25, 2018 at 4:02 PM Stefan van der Walt 
wrote:

> Hi Chris,
>
> On Wed, 25 Jul 2018 08:13:26 -0700, Chris Barker - NOAA Federal wrote:
> > For example, I am very wary of putting a non-fixed width encoding (e.g.
> > Utf-8) in a fixed width field.
> >
> > But this PR is not the place to discuss that.
>
> Since you've followed that discussion closely, can you push a commit to
> my PR with text that more accurately captures the situation?
>
> Thanks!
> Stéfan
>

Hi Chris,

Obviously the string dtype proposal in the roadmap is only a sketch at this
point :).

I do think that options listed currently (encoded strings with fixed-width
storage and variable length strings) cover the breadth of proposals from
last time. We may not want to implement all of them in NumPy, but I think
we can agree that there are use cases for all them, even if only as
external dtypes?

Would it help to add "and/or" after the first bullet? Mostly I care about
having like to have "improve string dtypes" in some form on the roadmap,
and thought it would be helpful to list the concrete proposals that I
recall. The actual design choices (especially if we proposal to change any
default behavior) will certainly need a NEP.

Best,
Stephan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Roadmap proposal, v3

[Stefan van der Walt]

Hi Chris,

On Wed, 25 Jul 2018 08:13:26 -0700, Chris Barker - NOAA Federal wrote:
> For example, I am very wary of putting a non-fixed width encoding (e.g.
> Utf-8) in a fixed width field.
> 
> But this PR is not the place to discuss that.

Since you've followed that discussion closely, can you push a commit to
my PR with text that more accurately captures the situation?

Thanks!
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] update to numpy-1.5.0 gives new warnings from scipy

[Sebastian Berg]

On Wed, 2018-07-25 at 07:44 -0400, Neal Becker wrote:
> After update to numpy-1.5.0, I'm getting warnings from scipy.
> These probably come from my code using convolve.  Does scipy need
> updating?
> 

Probably yes, I am a bit surprised we did not notice it before if it is
in scipy (or maybe scipy is already fixed?). This may be one of the
more controversial new warnings, so lets see if it comes up more. Right
now it seems not to affect much, I guess.
If the correct thing to do is to use the list as an array, then the
easiest solution maybe to do:

z[index,] = x  # note the additional `,`
# or alternatively of course: z[np.asarray(index)] = x

Otherwise, you will have to use `tuple(index)` to make sure numpy
interprets it as a multi-dimensional index.

The problem here, that this solves, is that if you have `z[some_list]`
currently numpy basically guesses whether you want a multi-dimensional
index or not.

- Sebastian


> /home/nbecker/.local/lib/python3.6/site-
> packages/scipy/fftpack/basic.py:160: FutureWarning: Using a non-tuple 
> sequence for multidimensional indexing is deprecated; use
> `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be
> interpreted as an array index, `arr[np.array(seq)]`, which will
> result either in an error or a different result.
>   z[index] = x
> /home/nbecker/.local/lib/python3.6/site-
> packages/scipy/signal/signaltools.py:491: FutureWarning: Using a non-
> tuple sequence for multidimensional indexing is deprecated; use
> `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be
> interpreted as an array index, `arr[np.array(seq)]`, which will
> result either in an error or a different result.
>   return x[reverse].conj()
> /home/nbecker/.local/lib/python3.6/site-
> packages/scipy/signal/signaltools.py:251: FutureWarning: Using a non-
> tuple sequence for multidimensional indexing is deprecated; use
> `arr[tuple(seq)]` instead of `arr[seq]`. In the future this will be
> interpreted as an array index, `arr[np.array(seq)]`, which will
> result either in an error or a different result.
>   in1zpadded[sc] = in1.copy()
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Roadmap proposal, v3

[Chris Barker - NOAA Federal]

Great work, thanks!

I see this:


 “- Fixed width encoded strings (utf8, latin1, ...)”

And a bit of discussion in the PR.

But I think there are key questions to be addressed in handling strings in
numpy. I know we’ve had a lot of discussion about it on this list over the
years — but is there a place that has captured that discussion / and or we
can start a new one?

For example, I am very wary of putting a non-fixed width encoding (e.g.
Utf-8) in a fixed width field.

But this PR is not the place to discuss that.

-CHB



Sent from my iPhone

On Jul 24, 2018, at 3:21 PM, Hameer Abbasi 
wrote:

Hey Stefan/Ralf/Stephan,

This looks nice, generally what the community agrees on. Great work, and
thanks for putting this together.

Best regards,
Hameer Abbasi
Sent from Astro  for Mac

On 24. Jul 2018 at 21:04, Stefan van der Walt  wrote:


Hi everyone,

Please take a look at the latest roadmap proposal:

https://github.com/numpy/numpy/pull/11611

This is a living document, so can easily be modified in the future, but
we'd like to get in place a document that corresponds fairly closely
with current community priorities.

Best regards,
Stéfan
___
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] update to numpy-1.5.0 gives new warnings from scipy

[Ralf Gommers]

On Wed, Jul 25, 2018 at 11:44 AM, Neal Becker  wrote:

> After update to numpy-1.5.0, I'm getting warnings from scipy.
> These probably come from my code using convolve.  Does scipy need updating?
>

Should already be fixed in scipy master.

Cheers,
Ralf



> /home/nbecker/.local/lib/python3.6/site-packages/scipy/fftpack/basic.py:160:
> FutureWarning: Using a non-tuple sequence for multidimensional indexing is
> deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this
> will be interpreted as an array index, `arr[np.array(seq)]`, which will
> result either in an error or a different result.
>   z[index] = x
> /home/nbecker/.local/lib/python3.6/site-packages/scipy/signal/signaltools.py:491:
> FutureWarning: Using a non-tuple sequence for multidimensional indexing is
> deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this
> will be interpreted as an array index, `arr[np.array(seq)]`, which will
> result either in an error or a different result.
>   return x[reverse].conj()
> /home/nbecker/.local/lib/python3.6/site-packages/scipy/signal/signaltools.py:251:
> FutureWarning: Using a non-tuple sequence for multidimensional indexing is
> deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this
> will be interpreted as an array index, `arr[np.array(seq)]`, which will
> result either in an error or a different result.
>   in1zpadded[sc] = in1.copy()
>
> ___
> 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] update to numpy-1.5.0 gives new warnings from scipy

[Neal Becker]

After update to numpy-1.5.0, I'm getting warnings from scipy.
These probably come from my code using convolve.  Does scipy need updating?

/home/nbecker/.local/lib/python3.6/site-packages/scipy/fftpack/basic.py:160:
FutureWarning: Using a non-tuple sequence for multidimensional indexing is
deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this
will be interpreted as an array index, `arr[np.array(seq)]`, which will
result either in an error or a different result.
  z[index] = x
/home/nbecker/.local/lib/python3.6/site-packages/scipy/signal/signaltools.py:491:
FutureWarning: Using a non-tuple sequence for multidimensional indexing is
deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this
will be interpreted as an array index, `arr[np.array(seq)]`, which will
result either in an error or a different result.
  return x[reverse].conj()
/home/nbecker/.local/lib/python3.6/site-packages/scipy/signal/signaltools.py:251:
FutureWarning: Using a non-tuple sequence for multidimensional indexing is
deprecated; use `arr[tuple(seq)]` instead of `arr[seq]`. In the future this
will be interpreted as an array index, `arr[np.array(seq)]`, which will
result either in an error or a different result.
  in1zpadded[sc] = in1.copy()
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion