Add support for complex64 in QR decomposition

[2400032275]

Fixes #2039

Updated the QR decomposition function to support complex64 data type in addition to float32 and float64.

Due Diligence

• General:
  • title of the PR is suitable to appear in the Release Notes
• Implementation:
  • unit tests: all split configurations tested
  • unit tests: multiple dtypes tested
  • NEW unit tests: MPS tested (1 MPI process, 1 GPU)
  • benchmarks: created for new functionality
  • benchmarks: performance improved or maintained
  • documentation updated where needed

Description

Issue/s resolved: #

Changes proposed:

Type of change

Memory requirements

Performance

Does this change modify the behaviour of other functions? If so, which?

yes / no

[github-actions]

Thank you for the PR!

[github-actions]

Thank you for the PR!

[mrfh92]

@2400032275 thanks for taking up this issue 👍. I have two suggestions if you want to complete this PR:

• So far, you have added support for complex64 (the complex counterpart of float32), but complex128 (the complex double precision) is still excluded
• In order to test whether QR really works with the additional datatypes you would need to add corresponding tests in heat/core/linalg/tests/test_qr.py, where in lines 14 and 81 the datatypes that are used for tests are defined.

If you need any help, feel free to ask :)

[brownbaerchen]

I think we have two ways of proceeding

• Remove any type checking and just leave it to torch to decide what it accepts for serial factorization
• Use the general type check with issubdtype

If the first one works, I would prefer that, but I am not sure. So maybe stick with the latter.

I definitely agree that this cannot be merged without being tested.

[brownbaerchen]

A better check would be

from ..types import issubdtype, floating, complex
if not issubdtype(A.dtype, floating) and not issubdtype(A.dtype, complex):

which would automatically work with all precision versions of these types. In particular, ones that will be added in the future.