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

[Sebastian Berg]

On Fri, 2020-06-26 at 21:53 -0700, leofang wrote:
> Hi all,
> 
> 
> Since I brought this issue from CuPy to Numpy, I'd like to see a
> decision
> made sooner than later so that downstream libraries like SciPy and
> CuPy can
> act accordingly. I think norm='forward' is fine. If there're still
> people
> unhappy with it after my reply, I'd suggest norm='reverse'. It has
> the same
> meaning, but is less confusing (than 'inverse' or other choices on
> the
> table) to me.
> 

I expect "forward" is good (if I misread something please correct me),
and I think we can go ahead with it, sorry for the delay.  However, I
have send an email to scipy-dev, since we should give them at least a
heads-up, and if you do not mind, I would wait a few days to actually
merge (although we can also simply reverse, as long as CuPy does not
have a release with it).

It might be nice to expand the kwarg docs slightly with a sentence for
each normalization mode?  Refering to `np.fft` docs is good, but if we
can squeeze in a short refresher and refer there for details/formula it
would be nicer.
I feel "forward" is very intuitive, but only after pointing out that it
is related to whether the fft or ifft has the normalization factor.

Cheers,

Sebastian


> 
> Best,
> Leo
> 
> 
> 
> --
> 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
> 



signature.asc
Description: This is a digitally signed message part
___
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

[Rakesh Vasudevan]

Hi all,

   Following up on this. Created a WIP PR
https://github.com/numpy/numpy/pull/16700

As stated in the original thread, We need to start by having a sort()
function for complex numbers that can do it based on keys, rather than
plain arithmetic ordering.

There are two broad ways to approach a sorting function that supports keys
(Not just for complex numbers).

   1. Add a key kwarg to the sort() (function and method). To support key
   based sorting on arrays.
   2. Use a new function on the lines off sortby(c_arr, key=(c_arr.real,
   c_arr.imag)

In this PR I have chosen approach 1 for the following reasons

   1.

   Approach 1 means it is easier to deal with both in-place method and the
   function. Since we can make the change in the c-sort function, we have
   minimal change in the python layer. This I hope results, minimal impact on
   current code that handles complex sorting. One example within numpy is is
   linalg module's svd() function.
   2.

   With approach 2 when we deprecate complex arithmetic ordering, existing
   methods using sort() for complex types, need to update their signature.

As it stands the PR does the following 3 things within the Python-C Array
method implementation of sort

   1. Checks for complex type- If array is of complex-type, it creates a
   default key(When no key is passed) which mimics the current arithmetic
   ordering in Numpy .
   2. Uses the keys to perform a Py_LexSort and generate indices.
   3. We perform the take_along_axis via C call back and copy over the
   result to the original array (pseudo in-place).

I am requesting feedback/help on implementing take_along_axis logic in C
level in an in-place manner and the approach in general.

This will further feed into max() and min() as well. Once we figure this
out. Next step would be to deprecate arithmetic ordering for complex types
(Which I think will be a PR on it's own)


Regards

Rakesh

On Thu, Jun 4, 2020 at 9:21 PM Brock Mendel  wrote:

> 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 signatu