https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.76.0 2023-06-17T00:56:01+00:00 2023-06-17T00:56:01+00:00 Trevor Gross tmgross@umich.edu 2023-06-10T16:06:17+00:00 urn:sha1:22d00dcd47e0b8e18eb254966750fb523c726e4e 2021-07-17T05:30:34+00:00 Alex Huszagh ahuszagh@gmail.com 2021-07-17T05:30:34+00:00 urn:sha1:8752b403695a8830913571f0fd5ebfcf1483db37 Implementation is based off fast-float-rust, with a few notable changes. - Some unsafe methods have been removed. - Safe methods with inherently unsafe functionality have been removed. - All unsafe functionality is documented and provably safe. - Extensive documentation has been added for simpler maintenance. - Inline annotations on internal routines has been removed. - Fixed Python errors in src/etc/test-float-parse/runtests.py. - Updated test-float-parse to be a library, to avoid missing rand dependency. - Added regression tests for #31109 and #31407 in core tests. - Added regression tests for #31109 and #31407 in ui tests. - Use the existing slice primitive to simplify shared dec2flt methods - Remove Miri ignores from dec2flt, due to faster parsing times. - resolves #85198 - resolves #85214 - resolves #85234 - fixes #31407 - fixes #31109 - fixes #53015 - resolves #68396 - closes https://github.com/aldanor/fast-float-rust/issues/15 2021-03-01T18:41:16+00:00 David Tolnay dtolnay@gmail.com 2021-03-01T07:51:30+00:00 urn:sha1:bd51dea6934d5c583fe9c8bc806e6287cac43f90 This table is used twice in core::num::dec2flt::algorithm::power_of_ten. According to the semantics of const, a separate huge definition of the table is inlined at both places. fn power_of_ten(e: i16) -> Fp { assert!(e >= table::MIN_E); let i = e - table::MIN_E; let sig = table::POWERS.0[i as usize]; let exp = table::POWERS.1[i as usize]; Fp { f: sig, e: exp } } Theoretically this gets cleaned up by optimization passes, but in practice I am experiencing a miscompile from LTO on this code. Making the table a static, which would only be defined a single time and not require attention from LTO, eliminates the miscompile and seems semantically more appropriate anyway. A separate bug report on the LTO bug is forthcoming. 2020-04-10T13:09:58+00:00 Guillaume Gomez guillaume1.gomez@gmail.com 2019-11-21T12:57:40+00:00 urn:sha1:38eb369fa4d06e55869a8fae62796a7b0085a5bd 2020-02-08T04:49:40+00:00 Chris Simpkins git.simpkins@gmail.com 2020-02-08T04:49:40+00:00 urn:sha1:f38e2701d862379eca06475d196438038ca72564 2019-11-30T04:17:09+00:00 David Tolnay dtolnay@gmail.com 2019-11-30T03:38:59+00:00 urn:sha1:d353a4c2672b6688899a833b022d9f75a7090b60 2018-12-26T04:08:33+00:00 Mark Rousskov mark.simulacrum@gmail.com 2018-12-25T15:56:47+00:00 urn:sha1:2a663555ddf36f6b041445894a8c175cd1bc718c 2016-01-12T21:25:16+00:00 Robin Kruppe robin.kruppe@gmail.com 2015-12-30T13:01:42+00:00 urn:sha1:dad1df6c1ab8fa06e9c5a28a6849e61fcdaa5008 Add tables of small powers of ten used in the fast path. The tables are redundant: We could also use the big, more accurate table and round the value to the correct type (in fact we did just that before this commit). However, the rounding is extra work and slows down the fast path. Because only very small exponents enter the fast path, the table and thus the space overhead is negligible. Speed-wise, this is a clear win on a [benchmark] comparing the fast path to a naive, hand-optimized, inaccurate algorithm. Specifically, this change narrows the gap from a roughly 5x difference to a roughly 3.4x difference. [benchmark]: https://gist.github.com/Veedrac/dbb0c07994bc7882098e 2015-08-08T15:15:25+00:00 Robin Kruppe robin.kruppe@gmail.com 2015-07-26T13:44:24+00:00 urn:sha1:b7e39a1c2dd24fd4110c22c70cad254365b0ffd3 fast decimal-to-float conversions.