[BUG] numeric_limits for f16 inherits storage-type return values
Maintainers usually reply within 5 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 70/100
Research direction
Open cpp/base/f16.hpp and read the std::numeric_limits<base::f16> specialization: it derives from numeric_limits<storage_type> and only overrides quiet_NaN()/signaling_NaN(). Add overrides for min(), lowest(), max(), epsilon() and round_error() that return base::f16, converting from the storage-type base implementations. Because no caller is reported, add a static_assert or small C++ test in the cpp test suite asserting those members return base::f16; done means it compiles and the assertions pass.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- C++
- Stars
- 9.2k
- Forks
- 726
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from activeloopai/deeplake
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
activeloopai/deeplake#3259 ·
Maintainers usually reply within 5 days
-
[BUG] MMDetection COCO crowd filtering calls values() on a listPossibly taken @dajiaohuang claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
activeloopai/deeplake#3256 ·
Maintainers usually reply within 5 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
activeloopai/deeplake#3254 · 1 comment ·
Maintainers usually reply within 5 days
-
Failed full extension builds still update the incremental build modePossibly taken @tushar-2606 claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
activeloopai/deeplake#3247 · 1 comment ·
Maintainers usually reply within 5 days
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
activeloopai/deeplake#3245 ·
Maintainers usually reply within 5 days
All issues in activeloopai/deeplake
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
hipRTC lit tests compile against /opt/rocm's LLVM instead of the ROCm under test (ci/ hardcodes LLVM_PATH)Possibly taken @bernardogv claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
請增加教學：數字後的句號Open
Difficulty 1/5 Under an hour Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
Maintainers usually reply within 1 day