Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭 适合新手
#3,260 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 5 天内回复

还没有人认领这个 Issue。

评估

难度
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()。为 min()、lowest()、max()、epsilon() 和 round_error() 添加返回 base::f16 的重写,从 storage_type 的基类实现进行转换。由于没有报告调用方,请在 cpp 测试套件中添加一个 static_assert 或小型 C++ 测试,断言这些成员返回 base::f16;完成意味着它能编译并且断言通过。

由索引模型根据 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.3k
派生
724
PR 合并指标
30 天内没有已合并 PR

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

activeloopai/deeplake 的其他 Issue

查看 activeloopai/deeplake 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。