ryankert01 opened a new pull request, #1415:
URL: https://github.com/apache/mahout/pull/1415

   ### Related Issues
   
   Closes #907
   
   ### Changes
   
   - [ ] Bug fix
   - [ ] New feature
   - [x] Refactoring
   - [ ] Documentation
   - [ ] Test
   - [ ] CI/CD pipeline
   - [ ] Other
   
   ### Why
   
   Follow-up to the review thread on #881. `validate_tensor()` re-checked
   `is_pytorch_tensor(tensor)` even though its **only** caller already
   guarantees the object is a `torch.Tensor`:
   
   - `validate_tensor` has a single call site: `QdpEngine::encode_from_pytorch`
     (`engine.rs:209`).
   - `encode_from_pytorch` is only reached from the `encode()` dispatcher
     (`engine.rs:125`), and that branch is already gated by
     `is_pytorch_tensor(data)?` at `engine.rs:119`.
   
   So the inner check was dead weight on the real execution path. The
   function's actual job is validating *device placement* — the
   `device.type != "cpu"` guard, which is what already rejects non-CPU
   backends (CUDA/MPS/XLA/HPU). The old name `validate_tensor` didn't convey
   that, hence the rename suggested in the issue.
   
   ### How
   
   - Removed the redundant `is_pytorch_tensor` check (and its now-dead
     `"Object is not a PyTorch Tensor"` error arm) from the helper.
   - Renamed `validate_tensor` → `validate_tensor_cpu`, with a doc comment
     stating the caller-side contract (caller has already confirmed it is a
     `torch.Tensor`) and that it rejects non-CPU backends.
   - Updated the import and call site in `engine.rs`.
   
   No behavior change on any supported path. Verified with
   `cargo check` (`--cfg qdp_no_cuda`) and `cargo fmt --check`.
   
   ## Checklist
   
   - [x] Added or updated unit tests for all changes
   - [x] Added or updated documentation for all changes


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to