[Numpy-discussion] Numpy FFT normalization options issue (addition of new option)

[cvav]

Issue #16126: https://github.com/numpy/numpy/issues/16126
PR #16476: https://github.com/numpy/numpy/pull/16476
numpy.fft docs (v1.18):
https://numpy.org/doc/1.18/reference/routines.fft.html

Hello all, 
I was advised to write on the numpy mailing list, after this week's
community meeting led to some general discussions on the normalization
schemes used in the FFT functions.

My post has to do with issue #16126, which asks for the addition of a new
option for the "norm" argument for the FFT functions; "norm" controls the
way the forward (direct) and backward (inverse) transforms are normalized,
and the two currently supported options are "norm=None" (default) and
"norm=ortho". The "ortho" option uses the orthonormal Fourier basis
functions, which translates to both the forward and backward transforms
being scaled by 1/sqrt(n), where n is the number of Fourier modes (and data
points). The default "None" option scales the forward transform by 1
(unscaled) and the backward by 1/n. 

The new added option, called for now "norm=inverse", is the exact opposite
of the default option; i.e. it scales the forward transform by 1/n and the
backward by 1. In terms of using the FFT for spectral methods or
approximation problems, these are the three scaling schemes one encounters;
the transform itself is the same, with only a constant factor being the
difference. But having all three scaling options built in the fft and ifft
functions makes the code cleaner and it's easier to stay consistent.

I've submitted a PR for this change, and would be happy to get comments and
feedback on the implementation and anything else that hasn't been
considered. Thanks!

Chris



--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Improving Complex Comparison/Ordering in Numpy

[Rakesh Vasudevan]

Hi all,

As a follow up to gh-15981 , I
would like to propose a change to bring complex dtype(s) comparison
operators and related functions, in line with respective cpython
implementations.

The current state of complex dtype comparisons/ordering as summarised in
the issue is as follows:

# In python

>> cnum = 1 + 2j
>> cnum_two = 1 + 3j

# Doing a comparision yields
>> cnum > cnum_two

TypeError: '>' not supported between instances of 'complex' and 'complex'


# Doing the same in Numpy scalar comparision

>> np.array(cnum) > np.array(cnum_two)

# Yields

False


*NOTE*: only >, <, >= , <= do not work on complex numbers in python ,
equality (==) does work

similarly sorting uses comparison operators behind to sort complex values.
Again this behavior diverges from the default python behavior.

# In native python
>> clist = [cnum, cnum_2]
>> sorted(clist, key=lambda c: (c.real, c.imag))
[(1+2j), (1+3j)]

# In numpy

>> np.sort(clist) #Uses the default comparision order

# Yields same result

# To get a cpython like sorting call we can do the following in numpy
np.take_along_axis(clist, np.lexsort((clist.real, clist.imag), 0), 0)


This proposal aims to bring parity between default python handling of
complex numbers and handling complex types in numpy

This is a two-step process


   1. Sort complex numbers in a pythonic way , accepting key arguments, and
   deprecate usage of sort() on complex numbers without key argument
  1. Possibly extend this to max(), min(), if it makes sense to do so.
  2. Since sort() is being updated for complex numbers, searchsorted()
  is also a good candidate for implementing this change.
   2. Once this is done, we can deprecate the usage of comparison operators
   (>, <, >= , <=) on complex dtypes




*Handling sort() for complex numbers*
There are two approaches we can take for this


   1. update sort() method, to have a ‘key’ kwarg. When key value is
   passed, use lexsort to get indices and continue sorting of it. We could
   support lambda function keys like python, but that is likely to be very
   slow.
   2. Create a new wrapper function sort_by() (placeholder name, Requesting
   name suggestions/feedback)That essentially acts like a syntactic sugar for
  1. np.take_along_axis(clist, np.lexsort((clist.real, clist.imag), 0),
  0)


   1. Improve the existing sort_complex() method with the new key search
   functionality (Though the change will only reflect for complex dtypes).

We could choose either method, both have pros and cons , approach 1 makes
the sort function signature, closer to its python counterpart, while using
approach 2 provides a better distinction between the two approaches for
sorting. The performance on approach 1 function would vary, due to the key
being an optional argument. Would love the community’s thoughts on this.


*Handling min() and max() for complex numbers*

Since min and max are essentially a set of comparisons, in python they are
not allowed on complex numbers

>> clist = [cnum, cnum_2]
>>> min(clist)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: '<' not supported between instances of 'complex' and 'complex'

# But using keys argument again works
min(clist, key=lambda c: (c.real, c.imag))

We could use a similar key kwarg for min() and max() in python, but
question remains how we handle the keys, in this use case , naive way would
be to sort() on keys and take last or first element, which is likely going
to be slow. Requesting suggestions on approaching this.

*Comments on isclose()*
Both python and numpy use the absolute value/magnitude for comparing if two
values are close enough. Hence I do not see this change affecting this
function.

Requesting feedback and suggestions on the above.

Thank you,

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

Re: [Numpy-discussion] Improving Complex Comparison/Ordering in Numpy

[Brock Mendel]

Corresponding pandas issue:
https://github.com/pandas-dev/pandas/issues/28050

On Thu, Jun 4, 2020 at 9:17 PM Rakesh Vasudevan 
wrote:

> Hi all,
>
> As a follow up to gh-15981 ,
> I would like to propose a change to bring complex dtype(s) comparison
> operators and related functions, in line with respective cpython
> implementations.
>
> The current state of complex dtype comparisons/ordering as summarised in
> the issue is as follows:
>
> # In python
>
> >> cnum = 1 + 2j
> >> cnum_two = 1 + 3j
>
> # Doing a comparision yields
> >> cnum > cnum_two
>
> TypeError: '>' not supported between instances of 'complex' and 'complex'
>
>
> # Doing the same in Numpy scalar comparision
>
> >> np.array(cnum) > np.array(cnum_two)
>
> # Yields
>
> False
>
>
> *NOTE*: only >, <, >= , <= do not work on complex numbers in python ,
> equality (==) does work
>
> similarly sorting uses comparison operators behind to sort complex values.
> Again this behavior diverges from the default python behavior.
>
> # In native python
> >> clist = [cnum, cnum_2]
> >> sorted(clist, key=lambda c: (c.real, c.imag))
> [(1+2j), (1+3j)]
>
> # In numpy
>
> >> np.sort(clist) #Uses the default comparision order
>
> # Yields same result
>
> # To get a cpython like sorting call we can do the following in numpy
> np.take_along_axis(clist, np.lexsort((clist.real, clist.imag), 0), 0)
>
>
> This proposal aims to bring parity between default python handling of
> complex numbers and handling complex types in numpy
>
> This is a two-step process
>
>
>1. Sort complex numbers in a pythonic way , accepting key arguments,
>and deprecate usage of sort() on complex numbers without key argument
>   1. Possibly extend this to max(), min(), if it makes sense to do
>   so.
>   2. Since sort() is being updated for complex numbers,
>   searchsorted() is also a good candidate for implementing this change.
>2. Once this is done, we can deprecate the usage of comparison
>operators (>, <, >= , <=) on complex dtypes
>
>
>
>
> *Handling sort() for complex numbers*
> There are two approaches we can take for this
>
>
>1. update sort() method, to have a ‘key’ kwarg. When key value is
>passed, use lexsort to get indices and continue sorting of it. We could
>support lambda function keys like python, but that is likely to be very
>slow.
>2. Create a new wrapper function sort_by() (placeholder name,
>Requesting name suggestions/feedback)That essentially acts like a syntactic
>sugar for
>   1. np.take_along_axis(clist, np.lexsort((clist.real, clist.imag),
>   0), 0)
>
>
>1. Improve the existing sort_complex() method with the new key search
>functionality (Though the change will only reflect for complex dtypes).
>
> We could choose either method, both have pros and cons , approach 1 makes
> the sort function signature, closer to its python counterpart, while using
> approach 2 provides a better distinction between the two approaches for
> sorting. The performance on approach 1 function would vary, due to the key
> being an optional argument. Would love the community’s thoughts on this.
>
>
> *Handling min() and max() for complex numbers*
>
> Since min and max are essentially a set of comparisons, in python they are
> not allowed on complex numbers
>
> >> clist = [cnum, cnum_2]
> >>> min(clist)
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: '<' not supported between instances of 'complex' and 'complex'
>
> # But using keys argument again works
> min(clist, key=lambda c: (c.real, c.imag))
>
> We could use a similar key kwarg for min() and max() in python, but
> question remains how we handle the keys, in this use case , naive way would
> be to sort() on keys and take last or first element, which is likely going
> to be slow. Requesting suggestions on approaching this.
>
> *Comments on isclose()*
> Both python and numpy use the absolute value/magnitude for comparing if
> two values are close enough. Hence I do not see this change affecting this
> function.
>
> Requesting feedback and suggestions on the above.
>
> Thank you,
>
> Rakesh
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion