Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[BUG] numeric_limits for f16 inherits storage-type return values

オープン 初心者向け
#3,260 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
70/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
cpp
領域
backend

調査の方向性

cpp/base/f16.hpp を開き、std::numeric_limits<base::f16> の特殊化を読んでください。これは numeric_limits<storage_type> から派生し、quiet_NaN()/signaling_NaN() だけをオーバーライドしています。base::f16 を返す min()、lowest()、max()、epsilon()、round_error() のオーバーライドを追加し、storage_type の基底実装から変換してください。呼び出し元が報告されていないため、cpp テストスイートに、これらのメンバーが base::f16 を返すことを表明する static_assert または小さな C++ テストを追加してください。完了とは、コンパイルが通り、アサーションがパスすることを意味します。

索引モデルが issue の本文から書いたものです。

説明

Affected code

cpp/base/f16.hpp, std::numeric_limits<base::f16<T>>

Behavior

The specialization derives from std::numeric_limits<base::f16<T>::storage_type> and overrides only quiet_NaN() and signaling_NaN() to return base::f16<T>. Other value-returning members such as min(), lowest(), max(), epsilon(), and round_error() are inherited with the storage type as their return type, rather than base::f16<T> as required by the numeric_limits<T> interface. This makes the public specialization's signatures inconsistent with its advertised type even if an implicit conversion is available at a call site.

This is based on the visible specialization; no C++ build or test was run. There is no tracked caller demonstrating the downstream compile/runtime impact.

主要言語
C++
スター
9.2k
フォーク
726
PR マージ指標
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

activeloopai/deeplake のほかの issue

activeloopai/deeplake の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。