blob: e62bd01fbb5ef6b32255711917b0deca6617a079 [file] [log] [blame]
ricow@chromium.org55ee8072011-09-08 16:33:10 +00001// Copyright 2011 the V8 project authors. All rights reserved.
whesse@chromium.orgcec079d2010-03-22 14:44:04 +00002// Redistribution and use in source and binary forms, with or without
3// modification, are permitted provided that the following conditions are
4// met:
5//
6// * Redistributions of source code must retain the above copyright
7// notice, this list of conditions and the following disclaimer.
8// * Redistributions in binary form must reproduce the above
9// copyright notice, this list of conditions and the following
10// disclaimer in the documentation and/or other materials provided
11// with the distribution.
12// * Neither the name of Google Inc. nor the names of its
13// contributors may be used to endorse or promote products derived
14// from this software without specific prior written permission.
15//
16// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
17// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
18// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
19// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
20// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
21// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
22// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
23// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
24// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
25// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
26// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
27
ricow@chromium.org55ee8072011-09-08 16:33:10 +000028#include "../include/v8stdint.h"
29#include "checks.h"
30#include "utils.h"
whesse@chromium.orgcec079d2010-03-22 14:44:04 +000031
32#include "fast-dtoa.h"
33
34#include "cached-powers.h"
35#include "diy-fp.h"
36#include "double.h"
37
38namespace v8 {
39namespace internal {
40
41// The minimal and maximal target exponent define the range of w's binary
42// exponent, where 'w' is the result of multiplying the input by a cached power
43// of ten.
44//
45// A different range might be chosen on a different platform, to optimize digit
46// generation, but a smaller range requires more powers of ten to be cached.
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +000047static const int kMinimalTargetExponent = -60;
48static const int kMaximalTargetExponent = -32;
whesse@chromium.orgcec079d2010-03-22 14:44:04 +000049
50
51// Adjusts the last digit of the generated number, and screens out generated
52// solutions that may be inaccurate. A solution may be inaccurate if it is
53// outside the safe interval, or if we ctannot prove that it is closer to the
54// input than a neighboring representation of the same length.
55//
56// Input: * buffer containing the digits of too_high / 10^kappa
57// * the buffer's length
58// * distance_too_high_w == (too_high - w).f() * unit
59// * unsafe_interval == (too_high - too_low).f() * unit
60// * rest = (too_high - buffer * 10^kappa).f() * unit
61// * ten_kappa = 10^kappa * unit
62// * unit = the common multiplier
63// Output: returns true if the buffer is guaranteed to contain the closest
64// representable number to the input.
65// Modifies the generated digits in the buffer to approach (round towards) w.
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +000066static bool RoundWeed(Vector<char> buffer,
67 int length,
68 uint64_t distance_too_high_w,
69 uint64_t unsafe_interval,
70 uint64_t rest,
71 uint64_t ten_kappa,
72 uint64_t unit) {
whesse@chromium.orgcec079d2010-03-22 14:44:04 +000073 uint64_t small_distance = distance_too_high_w - unit;
74 uint64_t big_distance = distance_too_high_w + unit;
75 // Let w_low = too_high - big_distance, and
76 // w_high = too_high - small_distance.
77 // Note: w_low < w < w_high
78 //
79 // The real w (* unit) must lie somewhere inside the interval
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +000080 // ]w_low; w_high[ (often written as "(w_low; w_high)")
whesse@chromium.orgcec079d2010-03-22 14:44:04 +000081
82 // Basically the buffer currently contains a number in the unsafe interval
83 // ]too_low; too_high[ with too_low < w < too_high
84 //
85 // too_high - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
86 // ^v 1 unit ^ ^ ^ ^
87 // boundary_high --------------------- . . . .
88 // ^v 1 unit . . . .
89 // - - - - - - - - - - - - - - - - - - - + - - + - - - - - - . .
90 // . . ^ . .
91 // . big_distance . . .
92 // . . . . rest
93 // small_distance . . . .
94 // v . . . .
95 // w_high - - - - - - - - - - - - - - - - - - . . . .
96 // ^v 1 unit . . . .
97 // w ---------------------------------------- . . . .
98 // ^v 1 unit v . . .
99 // w_low - - - - - - - - - - - - - - - - - - - - - . . .
100 // . . v
101 // buffer --------------------------------------------------+-------+--------
102 // . .
103 // safe_interval .
104 // v .
105 // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .
106 // ^v 1 unit .
107 // boundary_low ------------------------- unsafe_interval
108 // ^v 1 unit v
109 // too_low - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
110 //
111 //
112 // Note that the value of buffer could lie anywhere inside the range too_low
113 // to too_high.
114 //
115 // boundary_low, boundary_high and w are approximations of the real boundaries
116 // and v (the input number). They are guaranteed to be precise up to one unit.
117 // In fact the error is guaranteed to be strictly less than one unit.
118 //
119 // Anything that lies outside the unsafe interval is guaranteed not to round
120 // to v when read again.
121 // Anything that lies inside the safe interval is guaranteed to round to v
122 // when read again.
123 // If the number inside the buffer lies inside the unsafe interval but not
124 // inside the safe interval then we simply do not know and bail out (returning
125 // false).
126 //
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000127 // Similarly we have to take into account the imprecision of 'w' when finding
128 // the closest representation of 'w'. If we have two potential
129 // representations, and one is closer to both w_low and w_high, then we know
130 // it is closer to the actual value v.
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000131 //
132 // By generating the digits of too_high we got the largest (closest to
133 // too_high) buffer that is still in the unsafe interval. In the case where
134 // w_high < buffer < too_high we try to decrement the buffer.
135 // This way the buffer approaches (rounds towards) w.
136 // There are 3 conditions that stop the decrementation process:
137 // 1) the buffer is already below w_high
138 // 2) decrementing the buffer would make it leave the unsafe interval
139 // 3) decrementing the buffer would yield a number below w_high and farther
140 // away than the current number. In other words:
141 // (buffer{-1} < w_high) && w_high - buffer{-1} > buffer - w_high
142 // Instead of using the buffer directly we use its distance to too_high.
143 // Conceptually rest ~= too_high - buffer
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000144 // We need to do the following tests in this order to avoid over- and
145 // underflows.
146 ASSERT(rest <= unsafe_interval);
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000147 while (rest < small_distance && // Negated condition 1
148 unsafe_interval - rest >= ten_kappa && // Negated condition 2
149 (rest + ten_kappa < small_distance || // buffer{-1} > w_high
150 small_distance - rest >= rest + ten_kappa - small_distance)) {
151 buffer[length - 1]--;
152 rest += ten_kappa;
153 }
154
155 // We have approached w+ as much as possible. We now test if approaching w-
156 // would require changing the buffer. If yes, then we have two possible
157 // representations close to w, but we cannot decide which one is closer.
158 if (rest < big_distance &&
159 unsafe_interval - rest >= ten_kappa &&
160 (rest + ten_kappa < big_distance ||
161 big_distance - rest > rest + ten_kappa - big_distance)) {
162 return false;
163 }
164
165 // Weeding test.
166 // The safe interval is [too_low + 2 ulp; too_high - 2 ulp]
167 // Since too_low = too_high - unsafe_interval this is equivalent to
168 // [too_high - unsafe_interval + 4 ulp; too_high - 2 ulp]
169 // Conceptually we have: rest ~= too_high - buffer
170 return (2 * unit <= rest) && (rest <= unsafe_interval - 4 * unit);
171}
172
173
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000174// Rounds the buffer upwards if the result is closer to v by possibly adding
175// 1 to the buffer. If the precision of the calculation is not sufficient to
176// round correctly, return false.
177// The rounding might shift the whole buffer in which case the kappa is
178// adjusted. For example "99", kappa = 3 might become "10", kappa = 4.
179//
180// If 2*rest > ten_kappa then the buffer needs to be round up.
181// rest can have an error of +/- 1 unit. This function accounts for the
182// imprecision and returns false, if the rounding direction cannot be
183// unambiguously determined.
184//
185// Precondition: rest < ten_kappa.
186static bool RoundWeedCounted(Vector<char> buffer,
187 int length,
188 uint64_t rest,
189 uint64_t ten_kappa,
190 uint64_t unit,
191 int* kappa) {
192 ASSERT(rest < ten_kappa);
193 // The following tests are done in a specific order to avoid overflows. They
194 // will work correctly with any uint64 values of rest < ten_kappa and unit.
195 //
196 // If the unit is too big, then we don't know which way to round. For example
197 // a unit of 50 means that the real number lies within rest +/- 50. If
198 // 10^kappa == 40 then there is no way to tell which way to round.
199 if (unit >= ten_kappa) return false;
200 // Even if unit is just half the size of 10^kappa we are already completely
201 // lost. (And after the previous test we know that the expression will not
202 // over/underflow.)
203 if (ten_kappa - unit <= unit) return false;
204 // If 2 * (rest + unit) <= 10^kappa we can safely round down.
205 if ((ten_kappa - rest > rest) && (ten_kappa - 2 * rest >= 2 * unit)) {
206 return true;
207 }
208 // If 2 * (rest - unit) >= 10^kappa, then we can safely round up.
209 if ((rest > unit) && (ten_kappa - (rest - unit) <= (rest - unit))) {
210 // Increment the last digit recursively until we find a non '9' digit.
211 buffer[length - 1]++;
212 for (int i = length - 1; i > 0; --i) {
213 if (buffer[i] != '0' + 10) break;
214 buffer[i] = '0';
215 buffer[i - 1]++;
216 }
217 // If the first digit is now '0'+ 10 we had a buffer with all '9's. With the
218 // exception of the first digit all digits are now '0'. Simply switch the
219 // first digit to '1' and adjust the kappa. Example: "99" becomes "10" and
220 // the power (the kappa) is increased.
221 if (buffer[0] == '0' + 10) {
222 buffer[0] = '1';
223 (*kappa) += 1;
224 }
225 return true;
226 }
227 return false;
228}
229
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000230
231static const uint32_t kTen4 = 10000;
232static const uint32_t kTen5 = 100000;
233static const uint32_t kTen6 = 1000000;
234static const uint32_t kTen7 = 10000000;
235static const uint32_t kTen8 = 100000000;
236static const uint32_t kTen9 = 1000000000;
237
238// Returns the biggest power of ten that is less than or equal than the given
239// number. We furthermore receive the maximum number of bits 'number' has.
240// If number_bits == 0 then 0^-1 is returned
241// The number of bits must be <= 32.
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000242// Precondition: number < (1 << (number_bits + 1)).
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000243static void BiggestPowerTen(uint32_t number,
244 int number_bits,
245 uint32_t* power,
246 int* exponent) {
247 switch (number_bits) {
248 case 32:
249 case 31:
250 case 30:
251 if (kTen9 <= number) {
252 *power = kTen9;
253 *exponent = 9;
254 break;
255 } // else fallthrough
256 case 29:
257 case 28:
258 case 27:
259 if (kTen8 <= number) {
260 *power = kTen8;
261 *exponent = 8;
262 break;
263 } // else fallthrough
264 case 26:
265 case 25:
266 case 24:
267 if (kTen7 <= number) {
268 *power = kTen7;
269 *exponent = 7;
270 break;
271 } // else fallthrough
272 case 23:
273 case 22:
274 case 21:
275 case 20:
276 if (kTen6 <= number) {
277 *power = kTen6;
278 *exponent = 6;
279 break;
280 } // else fallthrough
281 case 19:
282 case 18:
283 case 17:
284 if (kTen5 <= number) {
285 *power = kTen5;
286 *exponent = 5;
287 break;
288 } // else fallthrough
289 case 16:
290 case 15:
291 case 14:
292 if (kTen4 <= number) {
293 *power = kTen4;
294 *exponent = 4;
295 break;
296 } // else fallthrough
297 case 13:
298 case 12:
299 case 11:
300 case 10:
301 if (1000 <= number) {
302 *power = 1000;
303 *exponent = 3;
304 break;
305 } // else fallthrough
306 case 9:
307 case 8:
308 case 7:
309 if (100 <= number) {
310 *power = 100;
311 *exponent = 2;
312 break;
313 } // else fallthrough
314 case 6:
315 case 5:
316 case 4:
317 if (10 <= number) {
318 *power = 10;
319 *exponent = 1;
320 break;
321 } // else fallthrough
322 case 3:
323 case 2:
324 case 1:
325 if (1 <= number) {
326 *power = 1;
327 *exponent = 0;
328 break;
329 } // else fallthrough
330 case 0:
331 *power = 0;
332 *exponent = -1;
333 break;
334 default:
335 // Following assignments are here to silence compiler warnings.
336 *power = 0;
337 *exponent = 0;
338 UNREACHABLE();
339 }
340}
341
342
343// Generates the digits of input number w.
344// w is a floating-point number (DiyFp), consisting of a significand and an
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000345// exponent. Its exponent is bounded by kMinimalTargetExponent and
346// kMaximalTargetExponent.
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000347// Hence -60 <= w.e() <= -32.
348//
349// Returns false if it fails, in which case the generated digits in the buffer
350// should not be used.
351// Preconditions:
352// * low, w and high are correct up to 1 ulp (unit in the last place). That
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000353// is, their error must be less than a unit of their last digits.
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000354// * low.e() == w.e() == high.e()
355// * low < w < high, and taking into account their error: low~ <= high~
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000356// * kMinimalTargetExponent <= w.e() <= kMaximalTargetExponent
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000357// Postconditions: returns false if procedure fails.
358// otherwise:
359// * buffer is not null-terminated, but len contains the number of digits.
360// * buffer contains the shortest possible decimal digit-sequence
361// such that LOW < buffer * 10^kappa < HIGH, where LOW and HIGH are the
362// correct values of low and high (without their error).
363// * if more than one decimal representation gives the minimal number of
364// decimal digits then the one closest to W (where W is the correct value
365// of w) is chosen.
366// Remark: this procedure takes into account the imprecision of its input
367// numbers. If the precision is not enough to guarantee all the postconditions
368// then false is returned. This usually happens rarely (~0.5%).
369//
370// Say, for the sake of example, that
371// w.e() == -48, and w.f() == 0x1234567890abcdef
372// w's value can be computed by w.f() * 2^w.e()
373// We can obtain w's integral digits by simply shifting w.f() by -w.e().
374// -> w's integral part is 0x1234
375// w's fractional part is therefore 0x567890abcdef.
376// Printing w's integral part is easy (simply print 0x1234 in decimal).
377// In order to print its fraction we repeatedly multiply the fraction by 10 and
sgjesse@chromium.org720dc0b2010-05-10 09:25:39 +0000378// get each digit. Example the first digit after the point would be computed by
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000379// (0x567890abcdef * 10) >> 48. -> 3
380// The whole thing becomes slightly more complicated because we want to stop
381// once we have enough digits. That is, once the digits inside the buffer
382// represent 'w' we can stop. Everything inside the interval low - high
383// represents w. However we have to pay attention to low, high and w's
384// imprecision.
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000385static bool DigitGen(DiyFp low,
386 DiyFp w,
387 DiyFp high,
388 Vector<char> buffer,
389 int* length,
390 int* kappa) {
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000391 ASSERT(low.e() == w.e() && w.e() == high.e());
392 ASSERT(low.f() + 1 <= high.f() - 1);
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000393 ASSERT(kMinimalTargetExponent <= w.e() && w.e() <= kMaximalTargetExponent);
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000394 // low, w and high are imprecise, but by less than one ulp (unit in the last
395 // place).
396 // If we remove (resp. add) 1 ulp from low (resp. high) we are certain that
397 // the new numbers are outside of the interval we want the final
398 // representation to lie in.
399 // Inversely adding (resp. removing) 1 ulp from low (resp. high) would yield
400 // numbers that are certain to lie in the interval. We will use this fact
401 // later on.
402 // We will now start by generating the digits within the uncertain
403 // interval. Later we will weed out representations that lie outside the safe
404 // interval and thus _might_ lie outside the correct interval.
405 uint64_t unit = 1;
406 DiyFp too_low = DiyFp(low.f() - unit, low.e());
407 DiyFp too_high = DiyFp(high.f() + unit, high.e());
408 // too_low and too_high are guaranteed to lie outside the interval we want the
409 // generated number in.
410 DiyFp unsafe_interval = DiyFp::Minus(too_high, too_low);
411 // We now cut the input number into two parts: the integral digits and the
412 // fractionals. We will not write any decimal separator though, but adapt
413 // kappa instead.
414 // Reminder: we are currently computing the digits (stored inside the buffer)
415 // such that: too_low < buffer * 10^kappa < too_high
416 // We use too_high for the digit_generation and stop as soon as possible.
417 // If we stop early we effectively round down.
418 DiyFp one = DiyFp(static_cast<uint64_t>(1) << -w.e(), w.e());
419 // Division by one is a shift.
420 uint32_t integrals = static_cast<uint32_t>(too_high.f() >> -one.e());
421 // Modulo by one is an and.
422 uint64_t fractionals = too_high.f() & (one.f() - 1);
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000423 uint32_t divisor;
424 int divisor_exponent;
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000425 BiggestPowerTen(integrals, DiyFp::kSignificandSize - (-one.e()),
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000426 &divisor, &divisor_exponent);
427 *kappa = divisor_exponent + 1;
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000428 *length = 0;
429 // Loop invariant: buffer = too_high / 10^kappa (integer division)
430 // The invariant holds for the first iteration: kappa has been initialized
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000431 // with the divisor exponent + 1. And the divisor is the biggest power of ten
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000432 // that is smaller than integrals.
433 while (*kappa > 0) {
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000434 int digit = integrals / divisor;
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000435 buffer[*length] = '0' + digit;
436 (*length)++;
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000437 integrals %= divisor;
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000438 (*kappa)--;
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000439 // Note that kappa now equals the exponent of the divisor and that the
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000440 // invariant thus holds again.
441 uint64_t rest =
442 (static_cast<uint64_t>(integrals) << -one.e()) + fractionals;
443 // Invariant: too_high = buffer * 10^kappa + DiyFp(rest, one.e())
444 // Reminder: unsafe_interval.e() == one.e()
445 if (rest < unsafe_interval.f()) {
446 // Rounding down (by not emitting the remaining digits) yields a number
447 // that lies within the unsafe interval.
448 return RoundWeed(buffer, *length, DiyFp::Minus(too_high, w).f(),
449 unsafe_interval.f(), rest,
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000450 static_cast<uint64_t>(divisor) << -one.e(), unit);
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000451 }
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000452 divisor /= 10;
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000453 }
454
455 // The integrals have been generated. We are at the point of the decimal
456 // separator. In the following loop we simply multiply the remaining digits by
457 // 10 and divide by one. We just need to pay attention to multiply associated
458 // data (like the interval or 'unit'), too.
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000459 // Note that the multiplication by 10 does not overflow, because w.e >= -60
460 // and thus one.e >= -60.
461 ASSERT(one.e() >= -60);
462 ASSERT(fractionals < one.f());
463 ASSERT(V8_2PART_UINT64_C(0xFFFFFFFF, FFFFFFFF) / 10 >= one.f());
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000464 while (true) {
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000465 fractionals *= 10;
466 unit *= 10;
467 unsafe_interval.set_f(unsafe_interval.f() * 10);
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000468 // Integer division by one.
469 int digit = static_cast<int>(fractionals >> -one.e());
470 buffer[*length] = '0' + digit;
471 (*length)++;
472 fractionals &= one.f() - 1; // Modulo by one.
473 (*kappa)--;
474 if (fractionals < unsafe_interval.f()) {
475 return RoundWeed(buffer, *length, DiyFp::Minus(too_high, w).f() * unit,
476 unsafe_interval.f(), fractionals, one.f(), unit);
477 }
478 }
479}
480
481
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000482
483// Generates (at most) requested_digits of input number w.
484// w is a floating-point number (DiyFp), consisting of a significand and an
485// exponent. Its exponent is bounded by kMinimalTargetExponent and
486// kMaximalTargetExponent.
487// Hence -60 <= w.e() <= -32.
488//
489// Returns false if it fails, in which case the generated digits in the buffer
490// should not be used.
491// Preconditions:
492// * w is correct up to 1 ulp (unit in the last place). That
493// is, its error must be strictly less than a unit of its last digit.
494// * kMinimalTargetExponent <= w.e() <= kMaximalTargetExponent
495//
496// Postconditions: returns false if procedure fails.
497// otherwise:
498// * buffer is not null-terminated, but length contains the number of
499// digits.
500// * the representation in buffer is the most precise representation of
501// requested_digits digits.
502// * buffer contains at most requested_digits digits of w. If there are less
503// than requested_digits digits then some trailing '0's have been removed.
504// * kappa is such that
505// w = buffer * 10^kappa + eps with |eps| < 10^kappa / 2.
506//
507// Remark: This procedure takes into account the imprecision of its input
508// numbers. If the precision is not enough to guarantee all the postconditions
509// then false is returned. This usually happens rarely, but the failure-rate
510// increases with higher requested_digits.
511static bool DigitGenCounted(DiyFp w,
512 int requested_digits,
513 Vector<char> buffer,
514 int* length,
515 int* kappa) {
516 ASSERT(kMinimalTargetExponent <= w.e() && w.e() <= kMaximalTargetExponent);
517 ASSERT(kMinimalTargetExponent >= -60);
518 ASSERT(kMaximalTargetExponent <= -32);
519 // w is assumed to have an error less than 1 unit. Whenever w is scaled we
520 // also scale its error.
521 uint64_t w_error = 1;
522 // We cut the input number into two parts: the integral digits and the
523 // fractional digits. We don't emit any decimal separator, but adapt kappa
524 // instead. Example: instead of writing "1.2" we put "12" into the buffer and
525 // increase kappa by 1.
526 DiyFp one = DiyFp(static_cast<uint64_t>(1) << -w.e(), w.e());
527 // Division by one is a shift.
528 uint32_t integrals = static_cast<uint32_t>(w.f() >> -one.e());
529 // Modulo by one is an and.
530 uint64_t fractionals = w.f() & (one.f() - 1);
531 uint32_t divisor;
532 int divisor_exponent;
533 BiggestPowerTen(integrals, DiyFp::kSignificandSize - (-one.e()),
534 &divisor, &divisor_exponent);
535 *kappa = divisor_exponent + 1;
536 *length = 0;
537
538 // Loop invariant: buffer = w / 10^kappa (integer division)
539 // The invariant holds for the first iteration: kappa has been initialized
540 // with the divisor exponent + 1. And the divisor is the biggest power of ten
541 // that is smaller than 'integrals'.
542 while (*kappa > 0) {
543 int digit = integrals / divisor;
544 buffer[*length] = '0' + digit;
545 (*length)++;
546 requested_digits--;
547 integrals %= divisor;
548 (*kappa)--;
549 // Note that kappa now equals the exponent of the divisor and that the
550 // invariant thus holds again.
551 if (requested_digits == 0) break;
552 divisor /= 10;
553 }
554
555 if (requested_digits == 0) {
556 uint64_t rest =
557 (static_cast<uint64_t>(integrals) << -one.e()) + fractionals;
558 return RoundWeedCounted(buffer, *length, rest,
559 static_cast<uint64_t>(divisor) << -one.e(), w_error,
560 kappa);
561 }
562
563 // The integrals have been generated. We are at the point of the decimal
564 // separator. In the following loop we simply multiply the remaining digits by
565 // 10 and divide by one. We just need to pay attention to multiply associated
566 // data (the 'unit'), too.
567 // Note that the multiplication by 10 does not overflow, because w.e >= -60
568 // and thus one.e >= -60.
569 ASSERT(one.e() >= -60);
570 ASSERT(fractionals < one.f());
571 ASSERT(V8_2PART_UINT64_C(0xFFFFFFFF, FFFFFFFF) / 10 >= one.f());
572 while (requested_digits > 0 && fractionals > w_error) {
573 fractionals *= 10;
574 w_error *= 10;
575 // Integer division by one.
576 int digit = static_cast<int>(fractionals >> -one.e());
577 buffer[*length] = '0' + digit;
578 (*length)++;
579 requested_digits--;
580 fractionals &= one.f() - 1; // Modulo by one.
581 (*kappa)--;
582 }
583 if (requested_digits != 0) return false;
584 return RoundWeedCounted(buffer, *length, fractionals, one.f(), w_error,
585 kappa);
586}
587
588
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000589// Provides a decimal representation of v.
590// Returns true if it succeeds, otherwise the result cannot be trusted.
591// There will be *length digits inside the buffer (not null-terminated).
592// If the function returns true then
593// v == (double) (buffer * 10^decimal_exponent).
594// The digits in the buffer are the shortest representation possible: no
595// 0.09999999999999999 instead of 0.1. The shorter representation will even be
596// chosen even if the longer one would be closer to v.
597// The last digit will be closest to the actual v. That is, even if several
598// digits might correctly yield 'v' when read again, the closest will be
599// computed.
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000600static bool Grisu3(double v,
601 Vector<char> buffer,
602 int* length,
603 int* decimal_exponent) {
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000604 DiyFp w = Double(v).AsNormalizedDiyFp();
605 // boundary_minus and boundary_plus are the boundaries between v and its
606 // closest floating-point neighbors. Any number strictly between
607 // boundary_minus and boundary_plus will round to v when convert to a double.
608 // Grisu3 will never output representations that lie exactly on a boundary.
609 DiyFp boundary_minus, boundary_plus;
610 Double(v).NormalizedBoundaries(&boundary_minus, &boundary_plus);
611 ASSERT(boundary_plus.e() == w.e());
612 DiyFp ten_mk; // Cached power of ten: 10^-k
613 int mk; // -k
ager@chromium.orgb61a0d12010-10-13 08:35:23 +0000614 int ten_mk_minimal_binary_exponent =
615 kMinimalTargetExponent - (w.e() + DiyFp::kSignificandSize);
616 int ten_mk_maximal_binary_exponent =
617 kMaximalTargetExponent - (w.e() + DiyFp::kSignificandSize);
lrn@chromium.org303ada72010-10-27 09:33:13 +0000618 PowersOfTenCache::GetCachedPowerForBinaryExponentRange(
619 ten_mk_minimal_binary_exponent,
620 ten_mk_maximal_binary_exponent,
621 &ten_mk, &mk);
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000622 ASSERT((kMinimalTargetExponent <= w.e() + ten_mk.e() +
623 DiyFp::kSignificandSize) &&
624 (kMaximalTargetExponent >= w.e() + ten_mk.e() +
625 DiyFp::kSignificandSize));
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000626 // Note that ten_mk is only an approximation of 10^-k. A DiyFp only contains a
627 // 64 bit significand and ten_mk is thus only precise up to 64 bits.
628
629 // The DiyFp::Times procedure rounds its result, and ten_mk is approximated
630 // too. The variable scaled_w (as well as scaled_boundary_minus/plus) are now
631 // off by a small amount.
632 // In fact: scaled_w - w*10^k < 1ulp (unit in the last place) of scaled_w.
633 // In other words: let f = scaled_w.f() and e = scaled_w.e(), then
634 // (f-1) * 2^e < w*10^k < (f+1) * 2^e
635 DiyFp scaled_w = DiyFp::Times(w, ten_mk);
636 ASSERT(scaled_w.e() ==
637 boundary_plus.e() + ten_mk.e() + DiyFp::kSignificandSize);
638 // In theory it would be possible to avoid some recomputations by computing
639 // the difference between w and boundary_minus/plus (a power of 2) and to
640 // compute scaled_boundary_minus/plus by subtracting/adding from
641 // scaled_w. However the code becomes much less readable and the speed
642 // enhancements are not terriffic.
643 DiyFp scaled_boundary_minus = DiyFp::Times(boundary_minus, ten_mk);
644 DiyFp scaled_boundary_plus = DiyFp::Times(boundary_plus, ten_mk);
645
646 // DigitGen will generate the digits of scaled_w. Therefore we have
647 // v == (double) (scaled_w * 10^-mk).
648 // Set decimal_exponent == -mk and pass it to DigitGen. If scaled_w is not an
649 // integer than it will be updated. For instance if scaled_w == 1.23 then
650 // the buffer will be filled with "123" und the decimal_exponent will be
651 // decreased by 2.
652 int kappa;
653 bool result = DigitGen(scaled_boundary_minus, scaled_w, scaled_boundary_plus,
654 buffer, length, &kappa);
655 *decimal_exponent = -mk + kappa;
656 return result;
657}
658
659
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000660// The "counted" version of grisu3 (see above) only generates requested_digits
661// number of digits. This version does not generate the shortest representation,
662// and with enough requested digits 0.1 will at some point print as 0.9999999...
663// Grisu3 is too imprecise for real halfway cases (1.5 will not work) and
664// therefore the rounding strategy for halfway cases is irrelevant.
665static bool Grisu3Counted(double v,
666 int requested_digits,
667 Vector<char> buffer,
668 int* length,
669 int* decimal_exponent) {
670 DiyFp w = Double(v).AsNormalizedDiyFp();
671 DiyFp ten_mk; // Cached power of ten: 10^-k
672 int mk; // -k
ager@chromium.orgb61a0d12010-10-13 08:35:23 +0000673 int ten_mk_minimal_binary_exponent =
674 kMinimalTargetExponent - (w.e() + DiyFp::kSignificandSize);
675 int ten_mk_maximal_binary_exponent =
676 kMaximalTargetExponent - (w.e() + DiyFp::kSignificandSize);
lrn@chromium.org303ada72010-10-27 09:33:13 +0000677 PowersOfTenCache::GetCachedPowerForBinaryExponentRange(
678 ten_mk_minimal_binary_exponent,
679 ten_mk_maximal_binary_exponent,
680 &ten_mk, &mk);
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000681 ASSERT((kMinimalTargetExponent <= w.e() + ten_mk.e() +
682 DiyFp::kSignificandSize) &&
683 (kMaximalTargetExponent >= w.e() + ten_mk.e() +
684 DiyFp::kSignificandSize));
685 // Note that ten_mk is only an approximation of 10^-k. A DiyFp only contains a
686 // 64 bit significand and ten_mk is thus only precise up to 64 bits.
687
688 // The DiyFp::Times procedure rounds its result, and ten_mk is approximated
689 // too. The variable scaled_w (as well as scaled_boundary_minus/plus) are now
690 // off by a small amount.
691 // In fact: scaled_w - w*10^k < 1ulp (unit in the last place) of scaled_w.
692 // In other words: let f = scaled_w.f() and e = scaled_w.e(), then
693 // (f-1) * 2^e < w*10^k < (f+1) * 2^e
694 DiyFp scaled_w = DiyFp::Times(w, ten_mk);
695
696 // We now have (double) (scaled_w * 10^-mk).
697 // DigitGen will generate the first requested_digits digits of scaled_w and
698 // return together with a kappa such that scaled_w ~= buffer * 10^kappa. (It
699 // will not always be exactly the same since DigitGenCounted only produces a
700 // limited number of digits.)
701 int kappa;
702 bool result = DigitGenCounted(scaled_w, requested_digits,
703 buffer, length, &kappa);
704 *decimal_exponent = -mk + kappa;
705 return result;
706}
707
708
kmillikin@chromium.org4111b802010-05-03 10:34:42 +0000709bool FastDtoa(double v,
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000710 FastDtoaMode mode,
711 int requested_digits,
kmillikin@chromium.org4111b802010-05-03 10:34:42 +0000712 Vector<char> buffer,
kmillikin@chromium.org4111b802010-05-03 10:34:42 +0000713 int* length,
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000714 int* decimal_point) {
sgjesse@chromium.org720dc0b2010-05-10 09:25:39 +0000715 ASSERT(v > 0);
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000716 ASSERT(!Double(v).IsSpecial());
717
fschneider@chromium.orgc20610a2010-09-22 09:44:58 +0000718 bool result = false;
719 int decimal_exponent = 0;
720 switch (mode) {
721 case FAST_DTOA_SHORTEST:
722 result = Grisu3(v, buffer, length, &decimal_exponent);
723 break;
724 case FAST_DTOA_PRECISION:
725 result = Grisu3Counted(v, requested_digits,
726 buffer, length, &decimal_exponent);
727 break;
728 default:
729 UNREACHABLE();
730 }
731 if (result) {
732 *decimal_point = *length + decimal_exponent;
733 buffer[*length] = '\0';
734 }
whesse@chromium.orgcec079d2010-03-22 14:44:04 +0000735 return result;
736}
737
738} } // namespace v8::internal