Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend the NORM2 intrinsic function to COMPLEX argument #340

Open
nncarlson opened this issue Sep 27, 2024 · 4 comments
Open

Extend the NORM2 intrinsic function to COMPLEX argument #340

nncarlson opened this issue Sep 27, 2024 · 4 comments

Comments

@nncarlson
Copy link

nncarlson commented Sep 27, 2024

It would be useful to extend the norm2 intrinsic function to complex arrays, so that
norm2(z) returns sqrt(sum(conjg(z)* z)). Note that dot_product already appropriately handles the case of complex arrays so that in the case of a rank-1 array this is equivalent to sqrt(dot_product(z,z)).

This is such an obvious extension of norm2 that is is puzzling why it wasn't included in the first place. There must be implementation difficulties (e.g., the standard recommendation "that the processor compute the result without undue overflow or underflow") for it to have been omitted.

Edit: sqrt(sum(conjg(z),z)) --> sqrt(sum(conjg(z)*z))

@klausler
Copy link

Did you mean sqrt(sum(conjg(z) * z))?

@nncarlson
Copy link
Author

Did you mean sqrt(sum(conjg(z) * z))?

Um, yeah... That was dumb of me.

@PierUgit
Copy link
Contributor

PierUgit commented Oct 2, 2024

There must be implementation difficulties (e.g., the standard recommendation "that the processor compute the result without undue overflow or underflow") for it to have been omitted.

I can't see which difficulties, actually. The complex array would be internally treated as a real array of twice the size:
$\sqrt{ \sum_i ( conjg(z_i)*z_i ) } = \sqrt{ \sum_i ( z_i\%re^2 ) + \sum_i ( z_i\%im^2 ) ) }$

So in practice the over/underflow protections could be applied the same way.

@klausler
Copy link

klausler commented Oct 2, 2024

There must be implementation difficulties (e.g., the standard recommendation "that the processor compute the result without undue overflow or underflow") for it to have been omitted.

I can't see which difficulties, actually. The complex array would be internally treated as a real array of twice the size: ∑ i ( c o n j g ( z i ) ∗ z i ) = ∑ i ( z i % r e 2 ) + ∑ i ( z i % i m 2 ) )

So in practice the over/underflow protections could be applied the same way.

I agree.

The technique that I use in f18 is to make one pass over the data, keeping both the maximum magnitude element value and a running sum of (x(i)/currmax) squared, adjusting that as necessary when larger maxima are found. (Maybe I should make two passes, one to find the true maximum and another to compute the sum of squares of scaled values, but that's how it works today.). Seems easy to adapt this to COMPLEX arguments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants