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/whatever, float is happy to coerce
> to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
On behalf of the SciPy development team I'm pleased to announce
the release of SciPy 1.2.2, which is a bug fix release. This is part
of the long-term support (LTS) branch that includes Python 2.7.
Sources and binary wheels can be found at:
I haven't read all the thread super carefully, so I might have missed
something, but I think we might want to look at this together with the
special rule for scalar casting.
IIUC, the basic end-user problem that motivates all thi sis: when you
have a simple Python constant whose exact dtype is
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 a number of ways: The array + array casting
>> is
>> unexpected to many
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 a number of ways: The array + array casting
> is
> unexpected to many users (eg, uint64 + int64 -> float64), and the
>
I think dtype-based casting makes a lot of sense, the problem is
backward compatibility.
Numpy casting is weird in a number of ways: The array + array casting is
unexpected to many users (eg, uint64 + int64 -> float64), and the
casting of array + scalar is different from that, and value based.
On Wed, 2019-06-05 at 21:35 -0400, Marten van Kerkwijk wrote:
> Hi Sebastian,
>
> Tricky! It seems a balance between unexpected memory blow-up and
> unexpected wrapping (the latter mostly for integers).
>
> Some comments specifically on your message first, then some more
> general related ones.
On Wed, 2019-06-05 at 17:14 -0700, Tyler Reddy wrote:
> A few thoughts:
>
> - We're not trying to achieve systematic guards against integer
> overflow / wrapping in ufunc inner loops, right? The performance
> tradeoffs for a "result-based" casting / exception handling addition
> would presumably
On Wed, Jun 5, 2019 at 10:42 PM Sebastian Berg
wrote:
> Hi all,
>
> TL;DR:
>
> Value based promotion seems complex both for users and ufunc-
> dispatching/promotion logic. Is there any way we can move forward here,
> and if we do, could we just risk some possible (maybe not-existing)
> corner
