Evan Alferez 64ab523462 [Docs][C++] Use kFloat64 in TensorOptions example to illustrate dtype override (#167467) (#184457) ...

## Summary

Fixes #167467.

The C++ `TensorOptions` example in `docs/cpp/source/api/aten/creation.md` explicitly sets `.dtype(torch::kFloat32)`, which is exactly the documented default listed in the immediately-following **Defaults** section of the same page. As a result the example doesn't actually demonstrate the point of `TensorOptions` — overriding the defaults — for the `dtype` axis.

This PR switches the example (and its matching assertion) to `kFloat64` so it shows a real override of the `kFloat32` default, while leaving `layout` / `device` / `requires_grad` overrides untouched.

## Problem

`docs/cpp/source/api/aten/creation.md` currently has:

```cpp
auto options =
  torch::TensorOptions()
    .dtype(torch::kFloat32)      // <- same as the documented default
    .layout(torch::kStrided)
    .device(torch::kCUDA, 1)
    .requires_grad(true);

torch::Tensor tensor = torch::full({3, 4}, /*value=*/123, options);

assert(tensor.dtype() == torch::kFloat32);
```

…and 7 lines later the same page says:

> **Defaults:** Any axis you omit takes its default value: `kFloat32` for dtype, `kStrided` for layout, `kCPU` for device, and `false` for `requires_grad`.

So the only axes the example actually *overrides* are `device` and `requires_grad`; the `.dtype(...)` call is a no-op vs. the documented default.

## Solution

Change both the example call and the assertion from `kFloat32` to `kFloat64`. That makes `.dtype(...)` an actual override, matching the spirit of the surrounding prose ("creating a `TensorOptions` object" by configuring its axes). `kFloat64` is the same dtype suggested in @malfet's review of PR #167474 ("better example would be to change value of `dtype` to `kFloat64`") and is what PR #171406 implemented before going stale.

## Prior art

Two earlier attempts on this issue were approved on substance but couldn't merge:

- #167474 — first attempt, flipped the surrounding prose ("64-bit float" → "32-bit float") instead of the code. Approved by @malfet who suggested the inverse: change the example dtype to `kFloat64`. Went stale.
- #171406 — implemented exactly the `kFloat32` → `kFloat64` change here. Approved by @jbschlosser, who tried to merge it (`@pytorchbot merge`), but the merge failed on EasyCLA: `The commit ... is not authorized under a signed CLA`. PR then went stale.

The original prose "64-bit float, strided tensor that requires a gradient, and lives on CUDA device 1" that #167467 originally cited was rewritten by the C++ docs restructure (#174096), so the wording mismatch is already gone — but the example still uses the default `dtype`, which is the substantive thing the issue and the maintainer feedback were after.

## Out of scope

- The **Defaults** section a few lines below still correctly documents `kFloat32` as the dtype default — left untouched.
- The "shorthand" examples further down the page (`torch::ones(10, torch::kFloat32)`, etc.) intentionally use `kFloat32` to show the shorthand syntax against the default and are unrelated to the "override the default" point. Left untouched.

## Test plan

- [ ] Docs-only change to a single Markdown code block — no Python/C++ behavior changes, no test changes needed.
- [ ] CI docs build / link-check to confirm the C++ docs page still renders.

## Related

- #167467 — original issue (still open)
- #167474 — prior attempt, approved by @malfet with the kFloat64 suggestion
- #171406 — prior attempt, approved by @jbschlosser, merge blocked on EasyCLA, went stale
- #174096 — C++ docs restructure that moved this content into `docs/cpp/source/api/aten/creation.md` and rewrote the surrounding prose

Pull Request resolved: https://github.com/pytorch/pytorch/pull/184457
Approved by: https://github.com/malfet

2026-05-21 23:48:28 +00:00

..

accessors.md

…

creation.md

…

index.md

…

indexing.md

…

tensor.md

…