]> git.proxmox.com Git - rustc.git/blame - src/libcore/num/dec2flt/mod.rs
New upstream version 1.13.0+dfsg1
[rustc.git] / src / libcore / num / dec2flt / mod.rs
CommitLineData
e9174d1e
SL
1// Copyright 2015 The Rust Project Developers. See the COPYRIGHT
2// file at the top-level directory of this distribution and at
3// http://rust-lang.org/COPYRIGHT.
4//
5// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
6// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
7// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
8// option. This file may not be copied, modified, or distributed
9// except according to those terms.
10
11//! Converting decimal strings into IEEE 754 binary floating point numbers.
12//!
13//! # Problem statement
14//!
15//! We are given a decimal string such as `12.34e56`. This string consists of integral (`12`),
16//! fractional (`45`), and exponent (`56`) parts. All parts are optional and interpreted as zero
17//! when missing.
18//!
19//! We seek the IEEE 754 floating point number that is closest to the exact value of the decimal
20//! string. It is well-known that many decimal strings do not have terminating representations in
21//! base two, so we round to 0.5 units in the last place (in other words, as well as possible).
22//! Ties, decimal values exactly half-way between two consecutive floats, are resolved with the
23//! half-to-even strategy, also known as banker's rounding.
24//!
25//! Needless to say, this is quite hard, both in terms of implementation complexity and in terms
26//! of CPU cycles taken.
27//!
28//! # Implementation
29//!
30//! First, we ignore signs. Or rather, we remove it at the very beginning of the conversion
31//! process and re-apply it at the very end. This is correct in all edge cases since IEEE
32//! floats are symmetric around zero, negating one simply flips the first bit.
33//!
34//! Then we remove the decimal point by adjusting the exponent: Conceptually, `12.34e56` turns
35//! into `1234e54`, which we describe with a positive integer `f = 1234` and an integer `e = 54`.
36//! The `(f, e)` representation is used by almost all code past the parsing stage.
37//!
38//! We then try a long chain of progressively more general and expensive special cases using
39//! machine-sized integers and small, fixed-sized floating point numbers (first `f32`/`f64`, then
40//! a type with 64 bit significand, `Fp`). When all these fail, we bite the bullet and resort to a
41//! simple but very slow algorithm that involved computing `f * 10^e` fully and doing an iterative
42//! search for the best approximation.
43//!
44//! Primarily, this module and its children implement the algorithms described in:
45//! "How to Read Floating Point Numbers Accurately" by William D. Clinger,
46//! available online: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.4152
47//!
48//! In addition, there are numerous helper functions that are used in the paper but not available
49//! in Rust (or at least in core). Our version is additionally complicated by the need to handle
50//! overflow and underflow and the desire to handle subnormal numbers. Bellerophon and
51//! Algorithm R have trouble with overflow, subnormals, and underflow. We conservatively switch to
52//! Algorithm M (with the modifications described in section 8 of the paper) well before the
53//! inputs get into the critical region.
54//!
55//! Another aspect that needs attention is the ``RawFloat`` trait by which almost all functions
56//! are parametrized. One might think that it's enough to parse to `f64` and cast the result to
57//! `f32`. Unfortunately this is not the world we live in, and this has nothing to do with using
58//! base two or half-to-even rounding.
59//!
60//! Consider for example two types `d2` and `d4` representing a decimal type with two decimal
61//! digits and four decimal digits each and take "0.01499" as input. Let's use half-up rounding.
62//! Going directly to two decimal digits gives `0.01`, but if we round to four digits first,
63//! we get `0.0150`, which is then rounded up to `0.02`. The same principle applies to other
64//! operations as well, if you want 0.5 ULP accuracy you need to do *everything* in full precision
65//! and round *exactly once, at the end*, by considering all truncated bits at once.
66//!
67//! FIXME Although some code duplication is necessary, perhaps parts of the code could be shuffled
68//! around such that less code is duplicated. Large parts of the algorithms are independent of the
69//! float type to output, or only needs access to a few constants, which could be passed in as
70//! parameters.
71//!
72//! # Other
73//!
74//! The conversion should *never* panic. There are assertions and explicit panics in the code,
75//! but they should never be triggered and only serve as internal sanity checks. Any panics should
76//! be considered a bug.
77//!
78//! There are unit tests but they are woefully inadequate at ensuring correctness, they only cover
79//! a small percentage of possible errors. Far more extensive tests are located in the directory
80//! `src/etc/test-float-parse` as a Python script.
81//!
82//! A note on integer overflow: Many parts of this file perform arithmetic with the decimal
83//! exponent `e`. Primarily, we shift the decimal point around: Before the first decimal digit,
84//! after the last decimal digit, and so on. This could overflow if done carelessly. We rely on
85//! the parsing submodule to only hand out sufficiently small exponents, where "sufficient" means
86//! "such that the exponent +/- the number of decimal digits fits into a 64 bit integer".
87//! Larger exponents are accepted, but we don't do arithmetic with them, they are immediately
88//! turned into {positive,negative} {zero,infinity}.
e9174d1e
SL
89
90#![doc(hidden)]
91#![unstable(feature = "dec2flt",
92 reason = "internal routines only exposed for testing",
93 issue = "0")]
94
e9174d1e
SL
95use fmt;
96use str::FromStr;
97
9cc50fc6 98use self::parse::{parse_decimal, Decimal, Sign, ParseResult};
e9174d1e
SL
99use self::num::digits_to_big;
100use self::rawfp::RawFloat;
101
102mod algorithm;
103mod table;
104mod num;
105// These two have their own tests.
106pub mod rawfp;
107pub mod parse;
108
109macro_rules! from_str_float_impl {
9cc50fc6 110 ($t:ty) => {
e9174d1e
SL
111 #[stable(feature = "rust1", since = "1.0.0")]
112 impl FromStr for $t {
113 type Err = ParseFloatError;
114
115 /// Converts a string in base 10 to a float.
116 /// Accepts an optional decimal exponent.
117 ///
118 /// This function accepts strings such as
119 ///
120 /// * '3.14'
121 /// * '-3.14'
122 /// * '2.5E10', or equivalently, '2.5e10'
123 /// * '2.5E-10'
124 /// * '.' (understood as 0)
125 /// * '5.'
126 /// * '.5', or, equivalently, '0.5'
127 /// * 'inf', '-inf', 'NaN'
128 ///
129 /// Leading and trailing whitespace represent an error.
130 ///
131 /// # Arguments
132 ///
133 /// * src - A string
134 ///
135 /// # Return value
136 ///
137 /// `Err(ParseFloatError)` if the string did not represent a valid
138 /// number. Otherwise, `Ok(n)` where `n` is the floating-point
139 /// number represented by `src`.
140 #[inline]
141 fn from_str(src: &str) -> Result<Self, ParseFloatError> {
142 dec2flt(src)
143 }
144 }
145 }
146}
9cc50fc6
SL
147from_str_float_impl!(f32);
148from_str_float_impl!(f64);
e9174d1e
SL
149
150/// An error which can be returned when parsing a float.
7453a54e
SL
151///
152/// This error is used as the error type for the [`FromStr`] implementation
153/// for [`f32`] and [`f64`].
154///
155/// [`FromStr`]: ../str/trait.FromStr.html
54a0048b
SL
156/// [`f32`]: ../../std/primitive.f32.html
157/// [`f64`]: ../../std/primitive.f64.html
9e0c209e 158#[derive(Debug, Clone, PartialEq, Eq)]
e9174d1e
SL
159#[stable(feature = "rust1", since = "1.0.0")]
160pub struct ParseFloatError {
161 kind: FloatErrorKind
162}
163
9e0c209e 164#[derive(Debug, Clone, PartialEq, Eq)]
e9174d1e
SL
165enum FloatErrorKind {
166 Empty,
167 Invalid,
168}
169
170impl ParseFloatError {
171 #[unstable(feature = "int_error_internals",
172 reason = "available through Error trait and this method should \
173 not be exposed publicly",
174 issue = "0")]
175 #[doc(hidden)]
176 pub fn __description(&self) -> &str {
177 match self.kind {
178 FloatErrorKind::Empty => "cannot parse float from empty string",
179 FloatErrorKind::Invalid => "invalid float literal",
180 }
181 }
182}
183
184#[stable(feature = "rust1", since = "1.0.0")]
185impl fmt::Display for ParseFloatError {
186 fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
187 self.__description().fmt(f)
188 }
189}
190
9cc50fc6 191fn pfe_empty() -> ParseFloatError {
e9174d1e
SL
192 ParseFloatError { kind: FloatErrorKind::Empty }
193}
194
9cc50fc6 195fn pfe_invalid() -> ParseFloatError {
e9174d1e
SL
196 ParseFloatError { kind: FloatErrorKind::Invalid }
197}
198
199/// Split decimal string into sign and the rest, without inspecting or validating the rest.
200fn extract_sign(s: &str) -> (Sign, &str) {
201 match s.as_bytes()[0] {
202 b'+' => (Sign::Positive, &s[1..]),
203 b'-' => (Sign::Negative, &s[1..]),
204 // If the string is invalid, we never use the sign, so we don't need to validate here.
205 _ => (Sign::Positive, s),
206 }
207}
208
209/// Convert a decimal string into a floating point number.
210fn dec2flt<T: RawFloat>(s: &str) -> Result<T, ParseFloatError> {
211 if s.is_empty() {
212 return Err(pfe_empty())
213 }
214 let (sign, s) = extract_sign(s);
215 let flt = match parse_decimal(s) {
54a0048b 216 ParseResult::Valid(decimal) => convert(decimal)?,
3157f602
XL
217 ParseResult::ShortcutToInf => T::infinity2(),
218 ParseResult::ShortcutToZero => T::zero2(),
e9174d1e 219 ParseResult::Invalid => match s {
3157f602
XL
220 "inf" => T::infinity2(),
221 "NaN" => T::nan2(),
e9174d1e
SL
222 _ => { return Err(pfe_invalid()); }
223 }
224 };
225
226 match sign {
227 Sign::Positive => Ok(flt),
228 Sign::Negative => Ok(-flt),
229 }
230}
231
232/// The main workhorse for the decimal-to-float conversion: Orchestrate all the preprocessing
233/// and figure out which algorithm should do the actual conversion.
234fn convert<T: RawFloat>(mut decimal: Decimal) -> Result<T, ParseFloatError> {
235 simplify(&mut decimal);
236 if let Some(x) = trivial_cases(&decimal) {
237 return Ok(x);
238 }
e9174d1e
SL
239 // Remove/shift out the decimal point.
240 let e = decimal.exp - decimal.fractional.len() as i64;
241 if let Some(x) = algorithm::fast_path(decimal.integral, decimal.fractional, e) {
242 return Ok(x);
243 }
244 // Big32x40 is limited to 1280 bits, which translates to about 385 decimal digits.
7453a54e
SL
245 // If we exceed this, we'll crash, so we error out before getting too close (within 10^10).
246 let upper_bound = bound_intermediate_digits(&decimal, e);
247 if upper_bound > 375 {
e9174d1e
SL
248 return Err(pfe_invalid());
249 }
250 let f = digits_to_big(decimal.integral, decimal.fractional);
251
252 // Now the exponent certainly fits in 16 bit, which is used throughout the main algorithms.
253 let e = e as i16;
254 // FIXME These bounds are rather conservative. A more careful analysis of the failure modes
255 // of Bellerophon could allow using it in more cases for a massive speed up.
256 let exponent_in_range = table::MIN_E <= e && e <= table::MAX_E;
7453a54e 257 let value_in_range = upper_bound <= T::max_normal_digits() as u64;
e9174d1e
SL
258 if exponent_in_range && value_in_range {
259 Ok(algorithm::bellerophon(&f, e))
260 } else {
261 Ok(algorithm::algorithm_m(&f, e))
262 }
263}
264
265// As written, this optimizes badly (see #27130, though it refers to an old version of the code).
266// `inline(always)` is a workaround for that. There are only two call sites overall and it doesn't
267// make code size worse.
268
269/// Strip zeros where possible, even when this requires changing the exponent
270#[inline(always)]
271fn simplify(decimal: &mut Decimal) {
272 let is_zero = &|&&d: &&u8| -> bool { d == b'0' };
273 // Trimming these zeros does not change anything but may enable the fast path (< 15 digits).
274 let leading_zeros = decimal.integral.iter().take_while(is_zero).count();
275 decimal.integral = &decimal.integral[leading_zeros..];
276 let trailing_zeros = decimal.fractional.iter().rev().take_while(is_zero).count();
277 let end = decimal.fractional.len() - trailing_zeros;
278 decimal.fractional = &decimal.fractional[..end];
279 // Simplify numbers of the form 0.0...x and x...0.0, adjusting the exponent accordingly.
280 // This may not always be a win (possibly pushes some numbers out of the fast path), but it
281 // simplifies other parts significantly (notably, approximating the magnitude of the value).
282 if decimal.integral.is_empty() {
283 let leading_zeros = decimal.fractional.iter().take_while(is_zero).count();
284 decimal.fractional = &decimal.fractional[leading_zeros..];
285 decimal.exp -= leading_zeros as i64;
286 } else if decimal.fractional.is_empty() {
287 let trailing_zeros = decimal.integral.iter().rev().take_while(is_zero).count();
288 let end = decimal.integral.len() - trailing_zeros;
289 decimal.integral = &decimal.integral[..end];
290 decimal.exp += trailing_zeros as i64;
291 }
292}
293
7453a54e
SL
294/// Quick and dirty upper bound on the size (log10) of the largest value that Algorithm R and
295/// Algorithm M will compute while working on the given decimal.
296fn bound_intermediate_digits(decimal: &Decimal, e: i64) -> u64 {
297 // We don't need to worry too much about overflow here thanks to trivial_cases() and the
298 // parser, which filter out the most extreme inputs for us.
299 let f_len: u64 = decimal.integral.len() as u64 + decimal.fractional.len() as u64;
300 if e >= 0 {
301 // In the case e >= 0, both algorithms compute about `f * 10^e`. Algorithm R proceeds to
302 // do some complicated calculations with this but we can ignore that for the upper bound
303 // because it also reduces the fraction beforehand, so we have plenty of buffer there.
304 f_len + (e as u64)
305 } else {
306 // If e < 0, Algorithm R does roughly the same thing, but Algorithm M differs:
307 // It tries to find a positive number k such that `f << k / 10^e` is an in-range
308 // significand. This will result in about `2^53 * f * 10^e` < `10^17 * f * 10^e`.
309 // One input that triggers this is 0.33...33 (375 x 3).
310 f_len + (e.abs() as u64) + 17
311 }
312}
313
e9174d1e
SL
314/// Detect obvious overflows and underflows without even looking at the decimal digits.
315fn trivial_cases<T: RawFloat>(decimal: &Decimal) -> Option<T> {
316 // There were zeros but they were stripped by simplify()
317 if decimal.integral.is_empty() && decimal.fractional.is_empty() {
3157f602 318 return Some(T::zero2());
e9174d1e 319 }
7453a54e
SL
320 // This is a crude approximation of ceil(log10(the real value)). We don't need to worry too
321 // much about overflow here because the input length is tiny (at least compared to 2^64) and
322 // the parser already handles exponents whose absolute value is greater than 10^18
323 // (which is still 10^19 short of 2^64).
e9174d1e
SL
324 let max_place = decimal.exp + decimal.integral.len() as i64;
325 if max_place > T::inf_cutoff() {
3157f602 326 return Some(T::infinity2());
e9174d1e 327 } else if max_place < T::zero_cutoff() {
3157f602 328 return Some(T::zero2());
e9174d1e
SL
329 }
330 None
331}