On Thu, 18 Feb 2021 at 10:11, Ralf Gommers wrote:
>
>
>
> On Wed, Feb 17, 2021 at 9:26 PM Oscar Benjamin
> wrote:
>>
>> On Wed, 17 Feb 2021 at 10:36, Ralf Gommers wrote:
>> >
>> > On Wed, Feb 17, 2021 at 12:26 AM Stefan van der Walt
>> > wrote:
>> >>
>> >> Ralf has been working towards this i
On Wed, Feb 17, 2021 at 9:26 PM Oscar Benjamin
wrote:
> On Wed, 17 Feb 2021 at 10:36, Ralf Gommers wrote:
> >
> > On Wed, Feb 17, 2021 at 12:26 AM Stefan van der Walt <
> stef...@berkeley.edu> wrote:
> >>
> >> Ralf has been working towards this idea, but having a well-organised
> namespace of ut
On Wed, Feb 17, 2021 at 2:37 AM Ralf Gommers wrote:
>
>
> On Wed, Feb 17, 2021 at 12:26 AM Stefan van der Walt
> wrote:
>
>> On Tue, Feb 16, 2021, at 07:49, Joseph Fox-Rabinovitz wrote:
>>
>> I'm getting a generally lukewarm not negative response. Should we put it
>> to a vote?
>>
>>
>> Things h
On Wed, 17 Feb 2021 at 10:36, Ralf Gommers wrote:
>
> On Wed, Feb 17, 2021 at 12:26 AM Stefan van der Walt
> wrote:
>>
>> Ralf has been working towards this idea, but having a well-organised
>> namespace of utility functions outside of the core NumPy API would be
>> helpful in allowing expansi
On Wed, Feb 17, 2021 at 12:26 AM Stefan van der Walt
wrote:
> On Tue, Feb 16, 2021, at 07:49, Joseph Fox-Rabinovitz wrote:
>
> I'm getting a generally lukewarm not negative response. Should we put it
> to a vote?
>
>
> Things here don't typically get decided by vote—I think you'll have to
> build
On Tue, Feb 16, 2021, at 07:49, Joseph Fox-Rabinovitz wrote:
> I'm getting a generally lukewarm not negative response. Should we put it to a
> vote?
Things here don't typically get decided by vote—I think you'll have to build
towards consensus. It may be overkill to write a NEP, but outlining a
I'm getting a generally lukewarm not negative response. Should we put it to
a vote?
- Joe
On Fri, Feb 12, 2021, 16:06 Robert Kern wrote:
> On Fri, Feb 12, 2021 at 3:42 PM Ralf Gommers
> wrote:
>
>>
>> On Fri, Feb 12, 2021 at 9:21 PM Robert Kern
>> wrote:
>>
>>> On Fri, Feb 12, 2021 at 1:47 PM
On Fri, Feb 12, 2021 at 3:42 PM Ralf Gommers wrote:
>
> On Fri, Feb 12, 2021 at 9:21 PM Robert Kern wrote:
>
>> On Fri, Feb 12, 2021 at 1:47 PM Ralf Gommers
>> wrote:
>>
>>>
>>> On Fri, Feb 12, 2021 at 7:25 PM Sebastian Berg <
>>> sebast...@sipsolutions.net> wrote:
>>>
Right, my initi
On Fri, Feb 12, 2021 at 9:21 PM Robert Kern wrote:
> On Fri, Feb 12, 2021 at 1:47 PM Ralf Gommers
> wrote:
>
>>
>> On Fri, Feb 12, 2021 at 7:25 PM Sebastian Berg <
>> sebast...@sipsolutions.net> wrote:
>>
>>> On Fri, 2021-02-12 at 10:08 -0500, Robert Kern wrote:
>>> > On Fri, Feb 12, 2021 at 9:4
On Fri, Feb 12, 2021 at 1:47 PM Ralf Gommers wrote:
>
> On Fri, Feb 12, 2021 at 7:25 PM Sebastian Berg
> wrote:
>
>> On Fri, 2021-02-12 at 10:08 -0500, Robert Kern wrote:
>> > On Fri, Feb 12, 2021 at 9:45 AM Joseph Fox-Rabinovitz <
>> > jfoxrabinov...@gmail.com> wrote:
>> >
>> > >
>> > >
>> > >
On Fri, Feb 12, 2021 at 7:25 PM Sebastian Berg
wrote:
> On Fri, 2021-02-12 at 10:08 -0500, Robert Kern wrote:
> > On Fri, Feb 12, 2021 at 9:45 AM Joseph Fox-Rabinovitz <
> > jfoxrabinov...@gmail.com> wrote:
> >
> > >
> > >
> > > On Fri, Feb 12, 2021, 09:32 Robert Kern
> > > wrote:
> > >
> > > >
On Fri, 2021-02-12 at 10:08 -0500, Robert Kern wrote:
> On Fri, Feb 12, 2021 at 9:45 AM Joseph Fox-Rabinovitz <
> jfoxrabinov...@gmail.com> wrote:
>
> >
> >
> > On Fri, Feb 12, 2021, 09:32 Robert Kern
> > wrote:
> >
> > > On Fri, Feb 12, 2021 at 5:15 AM Eric Wieser <
> > > wieser.eric+nu...@gm
On Fri, Feb 12, 2021 at 9:45 AM Joseph Fox-Rabinovitz <
jfoxrabinov...@gmail.com> wrote:
>
>
> On Fri, Feb 12, 2021, 09:32 Robert Kern wrote:
>
>> On Fri, Feb 12, 2021 at 5:15 AM Eric Wieser
>> wrote:
>>
>>> > There might be some linear algebraic reason why those axis positions
>>> make sense, b
On Fri, Feb 12, 2021, 09:32 Robert Kern wrote:
> On Fri, Feb 12, 2021 at 5:15 AM Eric Wieser
> wrote:
>
>> > There might be some linear algebraic reason why those axis positions
>> make sense, but I’m not aware of it...
>>
>> My guess is that the historical motivation was to allow grayscale `(H,
On Fri, Feb 12, 2021 at 5:15 AM Eric Wieser
wrote:
> > There might be some linear algebraic reason why those axis positions
> make sense, but I’m not aware of it...
>
> My guess is that the historical motivation was to allow grayscale `(H, W)`
> images to be converted into `(H, W, 1)` images so t
On Fri, 2021-02-12 at 11:13 +0100, Ralf Gommers wrote:
> On Fri, Feb 12, 2021 at 3:32 AM Juan Nunez-Iglesias
>
> wrote:
>
> > both napari and scikit-image use atleast_ a few times. I don’t have
> > many
> > examples of where I used nd because it didn’t exist. But I have the
> > very
> > distinct
> There might be some linear algebraic reason why those axis positions make
sense, but I’m not aware of it...
My guess is that the historical motivation was to allow grayscale `(H, W)`
images to be converted into `(H, W, 1)` images so that they can be
broadcast against `(H, W, 3)` RGB images.
Eri
On Fri, Feb 12, 2021 at 3:32 AM Juan Nunez-Iglesias
wrote:
> both napari and scikit-image use atleast_ a few times. I don’t have many
> examples of where I used nd because it didn’t exist. But I have the very
> distinct impression of needing it repeatedly. In some places, I’ve used
> `np.broadcas
both napari and scikit-image use atleast_ a few times. I don’t have many
examples of where I used nd because it didn’t exist. But I have the very
distinct impression of needing it repeatedly. In some places, I’ve used
`np.broadcast_to` to signal the same intention, where `atleast_nd` would have
I did a quick search of matplotlib, and found a few uses of all three
functions:
*
https://github.com/matplotlib/matplotlib/blob/fed55c63a314351cd39a12783f385009782c06e1/lib/matplotlib/_layoutgrid.py#L441-L446
This one isn't really numpy at all, and is really just a shorthand for
normalizing an
My original usecase for these was dealing with output data from Matlab
where those users would use `squeeze()` quite liberally. In addition, there
was the problem of the implicit squeeze() in the numpy's loadtxt() for
which I added the ndmin kwarg for in case an input CSV file had just one
row or n
On Thu, Feb 11, 2021 at 9:42 AM Benjamin Root wrote:
> for me, I find that the at_least{1,2,3}d functions are useful for
> sanitizing inputs. Having an at_leastnd() function can be viewed as a step
> towards cleaning up the API, not cluttering it (although, deprecations of
> the existing function
> I find that the at_least{1,2,3}d functions are useful for sanitizing
inputs
IMO, this type of "sanitization" goes against "In the face of ambiguity,
refuse the temptation to guess".
Instead of using `at_least{n}d`, it could be argued that `if np.ndim(x) !=
n: raise ValueError` is a safer bet, wh
The original functions appear to have been written for things like *stack
originally, which actually goes a long way to explaining the inconsistent
argument list.
- Joe
On Thu, Feb 11, 2021, 12:41 Benjamin Root wrote:
> for me, I find that the at_least{1,2,3}d functions are useful for
> saniti
for me, I find that the at_least{1,2,3}d functions are useful for
sanitizing inputs. Having an at_leastnd() function can be viewed as a step
towards cleaning up the API, not cluttering it (although, deprecations of
the existing functions probably should be long given how long they have
existed).
O
On Wed, Feb 10, 2021 at 9:48 PM Juan Nunez-Iglesias
wrote:
> I totally agree with the namespace clutter concern, but honestly, I would
> use `atleast_nd` with its `pos` argument (I might rename it to `position`,
> `axis`, or `axis_position`) any day over `at_least{1,2,3}d`, for which I
> had no i
I totally agree with the namespace clutter concern, but honestly, I would use
`atleast_nd` with its `pos` argument (I might rename it to `position`, `axis`,
or `axis_position`) any day over `at_least{1,2,3}d`, for which I had no idea
where the new axes would end up.
So, I’m in favour of includi
On Wed, 2021-02-10 at 17:31 -0500, Joseph Fox-Rabinovitz wrote:
> I've created PR#18386 to add a function called atleast_nd to numpy
> and
> numpy.ma. This would generalize the existing atleast_1d, atleast_2d,
> and
> atleast_3d functions.
>
> I proposed a similar idea about four and a half years
I've created PR#18386 to add a function called atleast_nd to numpy and
numpy.ma. This would generalize the existing atleast_1d, atleast_2d, and
atleast_3d functions.
I proposed a similar idea about four and a half years ago:
https://mail.python.org/pipermail/numpy-discussion/2016-July/075722.html,
29 matches
Mail list logo
