linalg eig: generalized eigenvalue problem

[perazz]

This PR proposes to address #907: Introduce the generalized eigenvalue option, A⋅x=λ⋅B⋅x.

Proposed interface

• call eig(a, b, lambda [, right] [, left] [, overwrite_a] [, overwrite_b] [, err])
• lambda = eigvals(a, b [, err])

For comparison, the standard problem is solved with

• call eig(a, lambda [, right] [, left] [, overwrite_a] [, err])
• lambda = eigvals(a [, err])

Key facts

• generalized problem uses *GGEV LAPACK backend
• choice between standard vs. generalized problem is made via an interface, so the appropriate backend can be called. (b is not an optional argument)
• Eigenvalue scaling is performed according to the same SciPy logic

Prior art

• SciPy: eig(a, b=None, left=False, right=True, overwrite_a=False, overwrite_b=False, check_finite=True, homogeneous_eigvals=False)

cc: @jvdp1 @jalvesz @fortran-lang/stdlib

[jvdp1]

Thank you @perazz . LGTM. It is a nice extension of eig.

[perazz]

Thank you @jvdp1 for the review and for catching the docs typo. It is much more clean now.

PS I notice that sometimes loadtxt still fails in the CI. Now we have an error message, it says:
loadtxt: error <end-of-file during read, unit -129, file /home/runner/work/stdlib/stdlib/example/io/example.dat> reading line 1 of example.dat. (Intel compiler)

[jvdp1]

I notice that sometimes loadtxt still fails in the CI. Now we have an error message, it says:
loadtxt: error <end-of-file during read, unit -129, file /home/runner/work/stdlib/stdlib/example/io/example.dat> reading line 1 of example.dat.

I have a similar issue in my prodcution code. I avoid it by compiling different codes for different compilers. Quite annoying... And I don't know if it is a bug of if the standard does not specifiy this behaviour.

[perazz]

By looking at the code, I really see no issues both in the default and the specified format, so I'm tempted to think of a bug. Maybe the only potential problem comes from non-advancing I/O in number_of_columns? To answer that, I implemented a better error message 8297763, hopefully that will help us understand.

[jvdp1]

By looking at the code, I really see no issues both in the default and the specified format, so I'm tempted to think of a bug. Maybe the only potential problem comes from non-advancing I/O in number_of_columns? To answer that, I implemented a better error message 8297763, hopefully that will help us understand.

Thank you. Indeed, hopefully we can understand it soon.

[jalvesz]

LGTM @perazz! Great addition!! I read through the PR and it really looks neat.

[perazz]

Thanks again @jvdp1 @jalvesz for the reviews, let's wait another couple of days and then merge, if there are no further comments.