On Fri, 2019-06-07 at 13:19 -0500, Sebastian Berg wrote:
> On Fri, 2019-06-07 at 07:18 +0200, Ralf Gommers wrote:
> >
> > On Fri, Jun 7, 2019 at 1:37 AM Nathaniel Smith
> > wrote:
> > > My intuition is that what users actually want is for *native
> > > Python
> > > types* to be treated as having
On Thu, 2019-06-06 at 19:34 -0400, Allan Haldane wrote:
> On 6/6/19 12:46 PM, Sebastian Berg wrote:
> > On Thu, 2019-06-06 at 11:57 -0400, Allan Haldane wrote:
> > > I think dtype-based casting makes a lot of sense, the problem is
> > > backward compatibility.
> > >
> > > Numpy casting is weird in
On Fri, 2019-06-07 at 07:18 +0200, Ralf Gommers wrote:
>
>
> On Fri, Jun 7, 2019 at 1:37 AM Nathaniel Smith wrote:
> > My intuition is that what users actually want is for *native Python
> > types* to be treated as having 'underspecified' dtypes, e.g. int is
> > happy to coerce to int8/int32/int
On Wed, Jun 5, 2019 at 4:42 PM Sebastian Berg
wrote:
I think the best approach is that if the user gave unambiguous types
as inputs to operators then the output should be the same dtype, or
type corresponding to the common promotion type of the inputs.
If the input type is not specified, I agree
On Fri, Jun 7, 2019 at 1:19 AM Ralf Gommers wrote:
>
>
> On Fri, Jun 7, 2019 at 1:37 AM Nathaniel Smith wrote:
>
>>
>> My intuition is that what users actually want is for *native Python
>> types* to be treated as having 'underspecified' dtypes, e.g. int is
>> happy to coerce to int8/int32/int64
