Comments (4)
Per the author of P0631, we should submit an update to the documentation at https://docs.microsoft.com/en-us/cpp/c-runtime-library/math-constants?view=vs-2019 after implementing this feature.
from stl.
This should be pretty straight forward, right?
Should it just support concepts or not?
from stl.
- Requiring concepts support seems reasonable.
- License discipline is important. I don't think we should refer to any of the References in WG21-P0631. For example, the MIT license is different from our Apache License v2.0 with LLVM Exception.
- It's fine to obtain pure mathematical constants from sources like Wolfram Alpha.
- In general, it is incorrect to round an infinitely-precise real number to 64-bit
double
and then round it again to 32-bitfloat
; see LWG-2403 for an explicit example. (Note: compilers themselves mishandle this; at least two front-ends parse3.14f
asdouble
then round tofloat
. Clang handles it correctly.) This is very rare, and reportedly, none of the real numbers in<numbers>
trigger this twice-rounding issue (for IEEE 64/32). However, it still makes me nervous to see decimal constants in source code (how do I know if they've been rounded too early?) and also nervous to seedouble
rounded tofloat
. I think what I'd like to see is a program that takes the pure mathematical constants and usescharconv
orstrtod/strtof
to round them to 64-bit/32-bit, then print them out as hexadecimal floating-point. Then the header can havedouble
andfloat
hexfloat constants, which will be nice and fast to parse, and alleviate my concerns. (I observe that Wolfram Alpha will give me 3,648 significant digits forsqrt(3)
; 768 significant digits is sufficient fordouble
and more than enough forfloat
.) Alternatively, the program could double-check that for these values, roundingdouble
tofloat
is binary-identical to directly converting decimal tofloat
; I would then acceptstatic_cast<_Floating>(0x1.abcd1234p0)
in the header, since that would be more convenient than having specializations forfloat
.
from stl.
Thanks for the direction!
One question, if it's dependant on concepts, what do I do re: <yvals_core>
. There doesn't seem to be a "conditionally implemented" section.
Or could a non-concepts version also been provided via a type alias to side-step that?
template <class _Ty>
using _Floating = enable_if_t<is_floating_point_v<_Ty>, _Ty>;
Edit: I ask because I already did that.
I currently have it implemented using decimal and with the same amount of sig figs as M_PI
et al.
The test program shows both what I have currently and from_chars
result in the same hexfloat (unless I've cocked it up, which is likely). Would you still prefer then as hexadecimal?
from stl.
Related Issues (20)
- P3142R0 Printing Blank Lines With `println()` HOT 2
- Vector algorithms with element size dispatch: standardize dispatching? HOT 2
- CWG-2387 cleanups: Remove `inline`/`_INLINE_VAR` from `constexpr` variable templates
- `vector_algorithms.cpp`: Remove the distinction between SSE2 and SSE4.2 HOT 7
- `<yvals_core.h>`: Update `_MSVC_STL_UPDATE` to April 2024
- Surprising behaviour with std::ranges::views::pairwise and std::ranges::to HOT 3
- LWG-3738 has not been implemented? HOT 1
- `<algorithm>`: `find_last` is lacking `_Could_compare_equal_to_value_type` check
- No thread-safe annotations for mutex and related classes HOT 3
- Q2 2024 priorities
- `<ranges>`: Poor error message when `ranges::to` cannot find a way to create the result
- operator delete calls _free_dbg(_UNKNOWN_BLOCK) in debug builds and it crashes when the user has replaced malloc() and free() HOT 11
- Ranges and lambdas weirdness HOT 4
- `<numeric>`: reduce/scan algorithms aren't enforcing their Mandates HOT 2
- `<tuple>`: Confusing diagnostic for `get<T>()` when the type doesn't occur exactly once
- `<ranges>`: `iota_view` and `_Counted_fn` inconsistently use `_STL_ASSERT` for precondition checking HOT 3
- Wiki: `Benchmarking-the-STL.md` mentions obsolete `BENCHMARK_TEMPLATE<N>` macros
- Wiki: `Benchmarking-the-STL.md` diverges from `README.md`
- `README.md`: Update working draft revision to N4981
- `<type_traits>`: `__vectorcall` _should_ be rejected on ARM64EC but isn't HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stl.