Move slogdet to linalg instead of numpy

[goyaladitya05]

Description

slogdet belongs to the linalg submodule (as in NumPy, JAX, PyTorch, and TensorFlow), but was mistakenly placed in numpy.py across all backends. This PR moves it to linalg.py where it belongs. Also improvised the tests.

Updated logdet in math.py (JAX and NumPy backends) to import slogdet from linalg instead of numpy.

Contributor Agreement

Please check all boxes below before submitting your PR for review:

• I am a human, and not a bot.
• I will be responsible for responding to review comments in a timely manner.
• I will work with the maintainers to push this PR forward until submission.

Note: Failing to adhere to this agreement may result in your future PRs no longer being reviewed.

[gemini-code-assist]

Code Review

This pull request migrates the slogdet operation from keras.ops.numpy to keras.ops.linalg across all backends and introduces a manual implementation for the OpenVINO backend. Feedback points out missing imports in the OpenVINO backend and an incorrect output dtype specification in the Slogdet operation for complex and integer inputs. Additionally, the slogdet docstring must include a code example to comply with the Keras API design guidelines.

[goyaladitya05]

apperently after improvisation, this test fails for the openvino backend (the backend implementaion might have bugs). To keep the scope of this PR solely for the refactor, added it to the exclusion list for now. Will address this in #22673.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 33.03571% with 75 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.04%. Comparing base (638444f) to head (9d68f95).
⚠️ Report is 4 commits behind head on master.

Files with missing lines	Patch %	Lines
keras/src/backend/openvino/linalg.py	4.00%	72 Missing ⚠️
keras/api/_tf_keras/keras/ops/__init__.py	0.00%	1 Missing ⚠️
keras/api/_tf_keras/keras/ops/linalg/__init__.py	0.00%	1 Missing ⚠️
keras/src/ops/linalg.py	95.65%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #22678      +/-   ##
==========================================
+ Coverage   77.13%   83.04%   +5.90%     
==========================================
  Files         596      596              
  Lines       68989    68999      +10     
  Branches    10790    10790              
==========================================
+ Hits        53216    57297    +4081     
+ Misses      12939     8886    -4053     
+ Partials     2834     2816      -18     

Flag	Coverage Δ
keras	82.85% <33.03%> (+5.86%)	⬆️
keras-jax	58.95% <28.57%> (+<0.01%)	⬆️
keras-numpy	54.78% <26.78%> (+<0.01%)	⬆️
keras-openvino	59.37% <21.42%> (-0.10%)	⬇️
keras-tensorflow	60.50% <27.67%> (?)
keras-torch	59.29% <27.67%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[hertschuh]

The issue is that slogdet has been in numpy for years. Moving is would be a breaking change.

It would stop working for people who have been doing keras.ops.numpy.slogdet.

And also, Functional models serialized with slodget will refer to keras.src.ops.numpy.Slogdet, so we can't move it otherwise deserialization will fail.

What we can do is add an alias in the export. If we really want to move the code to linalg.py, it's doable, but we need to have a alias of the Slogdet class in numpy.py (I think importing it would be enough).

[goyaladitya05]

The issue is that slogdet has been in numpy for years. Moving is would be a breaking change.

It would stop working for people who have been doing keras.ops.numpy.slogdet.

And also, Functional models serialized with slodget will refer to keras.src.ops.numpy.Slogdet, so we can't move it otherwise deserialization will fail.

Then I think it would be better to leave it as it is, because it's not really causing any issues at the moment.
Thanks for the review!