Re: [Numpy-discussion] Numpy integers to integer powers again again

[Nathaniel Smith]

On Mon, Oct 24, 2016 at 3:41 PM, Charles R Harris
 wrote:
> Hi All,
>
> I've been thinking about this some (a lot) more and have an alternate
> proposal for the behavior of the `**` operator
>
> if both base and power are numpy/python scalar integers, convert to python
> integers and call the `**` operator. That would solve both the precision and
> compatibility problems and I think is the option of least surprise. For
> those who need type preservation and modular arithmetic, the np.power
> function remains, although the type conversions can be surpirising as it
> seems that the base and power should  play different roles in determining
> the type, at least to me.
> Array, 0-d or not, are treated differently from scalars and integers raised
> to negative integer powers always raise an error.
>
> I think this solves most problems and would not be difficult to implement.
>
> Thoughts?

My main concern about this is that it adds more special cases to numpy
scalars, and a new behavioral deviation between 0d arrays and scalars,
when ideally we should be trying to reduce the
duplication/discrepancies between these. It's also inconsistent with
how other operations on integer scalars work, e.g. regular addition
overflows rather than promoting to Python int:

In [8]: np.int64(2 ** 63 - 1) + 1
/home/njs/.user-python3.5-64bit/bin/ipython:1: RuntimeWarning:
overflow encountered in long_scalars
  #!/home/njs/.user-python3.5-64bit/bin/python3.5
Out[8]: -9223372036854775808

So I'm inclined to try and keep it simple, like in your previous
proposal... theoretically of course it would be nice to have the
perfect solution here, but at this point it feels like we might be
overthinking this trying to get that last 1% of improvement. The thing
where 2 ** -1 returns 0 is just broken and bites people so we should
definitely fix it, but beyond that I'm not sure it really matters
*that* much what we do, and "special cases aren't special enough to
break the rules" and all that.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Numpy integers to integer powers again again

[Charles R Harris]

Hi All,

I've been thinking about this some (a lot) more and have an alternate
proposal for the behavior of the `**` operator

   - if both base and power are numpy/python scalar integers, convert to
   python integers and call the `**` operator. That would solve both the
   precision and compatibility problems and I think is the option of least
   surprise. For those who need type preservation and modular arithmetic, the
   np.power function remains, although the type conversions can be surpirising
   as it seems that the base and power should  play different roles in
   determining the type, at least to me.
   - Array, 0-d or not, are treated differently from scalars and integers
   raised to negative integer powers always raise an error.

I think this solves most problems and would not be difficult to implement.

Thoughts?

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

Re: [Numpy-discussion] padding options for diff

[Stephan Hoyer]

This looks like a welcome addition in functionality! It will be nice to be
able to finally (soft) deprecate ediff1d.

On Mon, Oct 24, 2016 at 5:44 AM, Matthew Harrigan <
harrigan.matt...@gmail.com> wrote:

> I posted a pull request  which
> adds optional padding kwargs "to_begin" and "to_end" to diff.  Those
> options are based on what's available in ediff1d.  It closes this issue
> 
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] padding options for diff

[Matthew Harrigan]

I posted a pull request  which
adds optional padding kwargs "to_begin" and "to_end" to diff.  Those
options are based on what's available in ediff1d.  It closes this issue

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