On Wed, 2020-04-29 at 05:26 -0500, Juan Nunez-Iglesias wrote:
> Hi everyone, and thank you Ralf for carrying the flag in my absence.
> =D
>
> Sebastian, the *primary* motivation behind avoiding detach() in
> PyTorch is listed in original post of the PyTorch issue:
>
> > People not very familiar w
On Wed, Apr 29, 2020 at 12:27 PM Juan Nunez-Iglesias
wrote:
>
>
> Ralf, you said you don't want warnings — even for sparse arrays? That was
> an area of concern for you on the PyTorch discussion side.
>
Providing a boolean keyword argument and then raising a warning every time
anyone uses that k
Hi everyone, and thank you Ralf for carrying the flag in my absence. =D
Sebastian, the *primary* motivation behind avoiding detach() in PyTorch is
listed in original post of the PyTorch issue:
> People not very familiar with `requires_grad` and cpu/gpu Tensors might go
> back and forth with num
On Tue, Apr 28, 2020 at 5:03 PM Sebastian Berg
wrote:
> On Tue, 2020-04-28 at 11:51 +0200, Ralf Gommers wrote:
>
> > > So arguably, there is no type-safety concern due to `.detach()`.
> >
> > I'm not sure what the question is here; no one mentioned type-safety.
> > The
> > PyTorch maintainers ha
On Tue, 2020-04-28 at 09:58 -0500, Sebastian Berg wrote:
> On Tue, 2020-04-28 at 11:51 +0200, Ralf Gommers wrote:
>
> > > So arguably, there is no type-safety concern due to `.detach()`.
> >
> > I'm not sure what the question is here; no one mentioned type-
> > safety.
> > The
> > PyTorch mainta
On Tue, 2020-04-28 at 11:51 +0200, Ralf Gommers wrote:
> > So arguably, there is no type-safety concern due to `.detach()`.
>
> I'm not sure what the question is here; no one mentioned type-safety.
> The
> PyTorch maintainers have already said they're fine with adding a
> force
> keyword.
But t
y to be careful with this.
Get Outlook for iOS<https://aka.ms/o0ukef>
From: NumPy-Discussion
on behalf of
Ralf Gommers
Sent: Tuesday, April 28, 2020 11:51:13 AM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Proposal: add `force=`
On Mon, Apr 27, 2020 at 12:10 AM Sebastian Berg
wrote:
> On Sat, 2020-04-25 at 10:52 -0700, Stephan Hoyer wrote:
> > On Sat, Apr 25, 2020 at 10:40 AM Ralf Gommers > >
> > wrote:
> >
> > >
> > > On Fri, Apr 24, 2020 at 12:35 PM Eric Wieser <
> > > wieser.eric+nu...@gmail.com>
> > > wrote:
> > >
>
On Sat, 2020-04-25 at 10:52 -0700, Stephan Hoyer wrote:
> On Sat, Apr 25, 2020 at 10:40 AM Ralf Gommers >
> wrote:
>
> >
> > On Fri, Apr 24, 2020 at 12:35 PM Eric Wieser <
> > wieser.eric+nu...@gmail.com>
> > wrote:
> >
> > > Perhaps worth mentioning that we've discussed this sort of API
> > >
On Sat, Apr 25, 2020 at 10:40 AM Ralf Gommers
wrote:
>
>
> On Fri, Apr 24, 2020 at 12:35 PM Eric Wieser
> wrote:
>
>> Perhaps worth mentioning that we've discussed this sort of API before, in
>> https://github.com/numpy/numpy/pull/11897.
>>
>> Under that proposal, the api would be something like
On Fri, Apr 24, 2020 at 12:35 PM Eric Wieser
wrote:
> Perhaps worth mentioning that we've discussed this sort of API before, in
> https://github.com/numpy/numpy/pull/11897.
>
> Under that proposal, the api would be something like:
>
> * `copy=True` - always copy, like it is today
> * `copy=False`
On Fri, 2020-04-24 at 10:12 -0700, Stephan Hoyer wrote:
> On Fri, Apr 24, 2020 at 6:31 AM Sebastian Berg <
> sebast...@sipsolutions.net>
> wrote:
>
> > One thing to note is that `__array__` is actually asked to return a
> > copy AFAIK.
>
> The documentation on __array__ seems to quite limited, un
On Fri, Apr 24, 2020 at 6:31 AM Sebastian Berg
wrote:
> One thing to note is that `__array__` is actually asked to return a
> copy AFAIK.
The documentation on __array__ seems to quite limited, unfortunately. The
most I can find are a few sentences here:
https://numpy.org/doc/stable/reference/ar
On Fri, 2020-04-24 at 11:34 +0100, Eric Wieser wrote:
> Perhaps worth mentioning that we've discussed this sort of API
> before, in
> https://github.com/numpy/numpy/pull/11897.
>
> Under that proposal, the api would be something like:
>
> * `copy=True` - always copy, like it is today
> * `copy=Fa
Perhaps worth mentioning that we've discussed this sort of API before, in
https://github.com/numpy/numpy/pull/11897.
Under that proposal, the api would be something like:
* `copy=True` - always copy, like it is today
* `copy=False` - copy if needed, like it is today
* `copy=np.never_copy` - never
Hi everyone,
> One bit of expressivity we would miss is “copy if necessary, but otherwise
> don’t bother”, but there are workarounds to this.
After a side discussion with Stéfan van der Walt, we came up with
`allow_copy=True`, which would express to the downstream library that we don’t
mind wa
On Tue, Apr 21, 2020 at 1:07 AM Juan Nunez-Iglesias
wrote:
> Hello NumPy-ers!
>
> The __array__ method is a great little tool to allow interoperability with
> NumPy. Briefly, calling `np.array()` or `np.asarray()` on an object with an
> `__array__` method, one can get a NumPy representation of th
Hello NumPy-ers!
The __array__ method is a great little tool to allow interoperability with
NumPy. Briefly, calling `np.array()` or `np.asarray()` on an object with an
`__array__` method, one can get a NumPy representation of that object, which
may or may not involve data copying (this is up to
18 matches
Mail list logo
