<div dir="ltr"><div>Your approach sounds good to me.<br></div><div><br></div><div>Thanks,</div><div><br></div><div>Yu<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 23, 2020 at 11:51 AM Chris Vavaliaris <<a href="mailto:cv1038@wildcats.unh.edu">cv1038@wildcats.unh.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chris Vavaliaris wrote<br>
> Hello,<br>
> <br>
> - my first reaction would be that the less argument names we change at a<br>
> time the better, so that we don't confuse people or cause codes written<br>
> with<br>
> previous NumPy versions to break. Personally I always think of "ortho" as<br>
> "orthonormal", which immediately brings "unit norm" to mind, but I have no<br>
> problem whatsoever with changing its name to "unitary" or maybe "unit",<br>
> which I'd probably choose if we were writing the routines from scratch. <br>
> <br>
> - In terms of the "inverse" name option, I do believe that it'd be a<br>
> confusing choice since "inverse" is used to describe the inverse FFT; if<br>
> we<br>
> choose to stick with a name that's based on the fact that this scaling is<br>
> opposite to the "norm=None" option, then I'd suggest "norm=opposite" as a<br>
> better choice. However, following Ross' comment, I think we could choose a<br>
> name based on the fact that the forward transform is now scaled by `n`,<br>
> instead of the backward one as in the default "norm=None". In this case,<br>
> I'd<br>
> suggest "norm=forward", which we can also nicely abbreviate to the<br>
> 4-character form "norm=forw" if desirable.<br>
> <br>
> Chris<br>
> <br>
> <br>
> Feng Yu wrote<br>
>> Hi,<br>
>> <br>
>> 1. The wikipedia pages of CFT and DFT refer to norm='ortho' as 'unitary'.<br>
>> Since we are in general working with complex numbers, I do suggest<br>
>> unitary<br>
>> over ortho.<br>
>> (<a href="https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Fourier_transform#Other_conventions</a>) and (<br>
>> <a href="https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Discrete_Fourier_transform#The_unitary_DFT</a>)<br>
>> <br>
>> 2. I share Chris's concern about 'inverse', but I could not come up with<br>
>> a<br>
>> nice name.<br>
>> <br>
>> 3. Now that we are at this, should we also describe the corresponding<br>
>> continuum limit of FFT and iFFT in the documentation?<br>
>> <br>
>> A paragraph doing so could potentially also help people diagnose some of<br>
>> the normalization factor errors. I assumed it is common that one needs to<br>
>> translate a CFT into DFT when coding a paper up, and the correct<br>
>> compensation to the normalization factors will surface if one does the<br>
>> math. -- I had the impression 1 / N corresponds to 1 / 2pi if the<br>
>> variable<br>
>> is angular frequency, but it's been a while since I did that last time.<br>
>> <br>
>> - Yu<br>
>> <br>
>> NumPy-Discussion mailing list<br>
> <br>
>> NumPy-Discussion@<br>
> <br>
>> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
> <br>
> <br>
> <br>
> <br>
> <br>
> --<br>
> Sent from: <a href="http://numpy-discussion.10968.n7.nabble.com/" rel="noreferrer" target="_blank">http://numpy-discussion.10968.n7.nabble.com/</a><br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
<br>
> NumPy-Discussion@<br>
<br>
> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
<br>
Hello all, <br>
the discussion on this topic has been stagnant for the past couple of weeks,<br>
so I just wanted to ask if anyone has any alternative names for the new<br>
normalization option that would like to share. <br>
<br>
If not, I'd suggest that we move on with "norm=forward", which seems to be a<br>
more straightforward choice than the "norm=inverse" naming alternative. I<br>
can wait a couple of days for possible new recommendations to be submitted,<br>
and will then recommit to the open PR to account for the new kwarg name. <br>
<br>
In terms of the name for the "norm=ortho" option, I suggest that we keep it<br>
as is for now so that we don't introduce two API changes at once. If<br>
desired, we can discuss it separately and open a new PR introducing a name<br>
such as "norm=unitary" or "unit" as recommended in previous messages. I'm<br>
happy to handle that if you think it'd be a useful change.<br>
<br>
Chris<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://numpy-discussion.10968.n7.nabble.com/" rel="noreferrer" target="_blank">http://numpy-discussion.10968.n7.nabble.com/</a><br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>