5  *  a Dragon4 variant, with fast paths for small integers.  Big integer
6  *  arithmetic is needed for guaranteeing that the conversion is correct
23  *  duk__str2num_digits_for_radix indicates, for each radix, how many input
24  *  digits should be considered significant for string-to-number conversion.
28  *  duk__str2num_exp_limits indicates, for each radix, the radix-specific
29  *  minimum/maximum exponent values (for a Dragon4 integer mantissa)
63  *  with the caller responsible for ensuring this is never exceeded.  No memory
64  *  allocation (except stack) is needed for bigint computation.  Operations
65  *  have been tailored for number conversion needs.
100 	for (i = x->n - 1; i >= 0; i--) {  in duk__bi_print()
119 	for (i = x->n - 1; i >= 0; i--) {  in duk__bi_normalize()
171 	for (i = nx - 1; i >= 0; i--) {  in duk__bi_compare()
209 	for (i = 0; i < ny; i++) {  in duk__bi_add()
244 	for (i = 0; i < ny; i++) {  in duk__bi_add()
316 	for (i = 0; i < ny; i++) {  in duk__bi_sub()
345 	for (i = 0; i < ny; i++) {  in duk__bi_sub()
419 	for (i = 0; i < y->n; i++) {  in duk__bi_mul()
422 		for (j = 0; j < nz; j++) {  in duk__bi_mul()
435 		 *  Multiply + add + carry for 32-bit components using only 16x16->32  in duk__bi_mul()
454 		for (j = 0; j < nz; j++) {  in duk__bi_mul()
543 	return (x->n == 0);  /* this is the case for normalized numbers */  in duk__bi_is_zero()
589 	for (;;) {  in duk__bi_exp_small()
622  *  The same algorithm is used for number parsing (with b=10 and B=2)
625  *  See doc/number-conversion.rst for limitations.
639 	/* Currently about 7*152 = 1064 bytes.  The space for these
640 	 * duk__bigints is used also as a temporary buffer for generating
650 	duk_small_int_t e;             /* exponent for 'f' */
658 	/* Buffer used for generated digits, values are in the range [0,B-1]. */
665  * is more convenient for the caller.
687 	for (;;) {  in duk__dragon4_format_uint32()
726 	 * results.  For instance, 1e23 serializes to "a000...", i.e. the first digit  in duk__dragon4_prepare()
735 	/* For string-to-number, pretend we never have the lowest mantissa as there  in duk__dragon4_prepare()
736 	 * is no natural "precision" for inputs.  Having lowest_mantissa == 0, we'll  in duk__dragon4_prepare()
737 	 * fall into the base cases for both e >= 0 and e < 0.  in duk__dragon4_prepare()
765 			                     "lowest mantissa value for this exponent -> "  in duk__dragon4_prepare()
789 			                     "not lowest mantissa for this exponent -> "  in duk__dragon4_prepare()
803 		    lowest_mantissa /* lowest mantissa for this exponent*/) {  in duk__dragon4_prepare()
815 			                     "lowest mantissa for this exponent -> "  in duk__dragon4_prepare()
836 			                     "lowest mantissa for this exponent -> "  in duk__dragon4_prepare()
861 	 * The case where m+ == m- (almost always) is optimized for, because  in duk__dragon4_scale()
867 	 * a logarithm based estimator for 'k' and performing B^n multiplication  in duk__dragon4_scale()
870 	 * impact for very large and very small numbers.  in duk__dragon4_scale()
880 	for (;;) {  in duk__dragon4_scale()
909 	for (;;) {  in duk__dragon4_scale()
976 	for (;;) {  in duk__dragon4_generate()
988 		for (;;) {  in duk__dragon4_generate()
1005 		/* Terminating conditions.  For fixed width output, we just ignore the  in duk__dragon4_generate()
1007 		 * the current shortcut for fixed-format output is to generate a few  in duk__dragon4_generate()
1071 				/* fall through and continue for-loop */  in duk__dragon4_generate()
1094 	}  /* for */  in duk__dragon4_generate()
1105 		for (i = 0; i < nc_ctx->count; i++) {  in duk__dragon4_generate()
1135 	 *  round_idx points to the digit which is considered for rounding; the  in duk__dragon4_fixed_format_round()
1154 	 *  For even values, divides evenly, e.g. 10 -> roundup_limit=5.  in duk__dragon4_fixed_format_round()
1156 	 *  For odd values, rounds up, e.g. 3 -> roundup_limit=2.  in duk__dragon4_fixed_format_round()
1165 		for (;;) {  in duk__dragon4_fixed_format_round()
1223 	 *  Note that the identifier names used for format selection are different  in duk__dragon4_convert_and_push()
1226 	 *  documentation for discussion.  in duk__dragon4_convert_and_push()
1228 	 *  Ecmascript doesn't specify any specific behavior for format selection  in duk__dragon4_convert_and_push()
1229 	 *  (e.g. when to use exponent notation) for non-base-10 numbers.  in duk__dragon4_convert_and_push()
1231 	 *  The bigint space in the context is reused for string output, as there  in duk__dragon4_convert_and_push()
1232 	 *  is more than enough space for that (>1kB at the moment), and we avoid  in duk__dragon4_convert_and_push()
1312 		 *  Exponent notation for non-base-10 numbers isn't specified in Ecmascript  in duk__dragon4_convert_and_push()
1314 		 *  only be formatted with Number.prototype.toString([radix]) and for that,  in duk__dragon4_convert_and_push()
1320 		 *  in the target radix B.  However, for radix values 15 and above, the  in duk__dragon4_convert_and_push()
1321 		 *  exponent separator 'e' is no longer easily parseable.  Consider, for  in duk__dragon4_convert_and_push()
1422 	 *  For normal numbers the leading '1' is hidden and ignored,  in duk__dragon4_ctx_to_double()
1423 	 *  and the last bit is used for rounding:  in duk__dragon4_ctx_to_double()
1429 	 *  For denormals, the leading '1' is included in the number,  in duk__dragon4_ctx_to_double()
1445 	 *  exponent.  For instance, k==0 indicates that the leading '1'  in duk__dragon4_ctx_to_double()
1457 		bitstart = -255;  /* needed for inf: causes mantissa to become zero,  in duk__dragon4_ctx_to_double()
1495 	for (i = 0; i < 52; i++) {  in duk__dragon4_ctx_to_double()
1588 	 *  specially, as they're very likely for embedded programs.  This  in duk_numconv_stringify()
1589 	 *  is now done for all radix values.  We must be careful not to use  in duk_numconv_stringify()
1594 	 *  sprintf "%lu" for the fast path and for exponent formatting.  in duk_numconv_stringify()
1606 			/* no negative sign for zero */  in duk_numconv_stringify()
1617 	 *  Convert double from IEEE representation for conversion;  in duk_numconv_stringify()
1629 	DUK_MEMZERO((void *) nc_ctx, sizeof(*nc_ctx));  /* slow init, do only for slow path cases */  in duk_numconv_stringify()
1640 			 * but add an extra digit for rounding.  in duk_numconv_stringify()
1660 				count = digits + 2;  /* lead zero + 'digits' fractions + 1 for rounding */  in duk_numconv_stringify()
1662 				count = digits + 1;  /* + 1 for rounding */  in duk_numconv_stringify()
1715 			roundpos = -digits;  /* absolute position for digit considered for rounding */  in duk_numconv_stringify()
1796 	 *  There is no special parsing for 'NaN' in the specification although  in duk_numconv_parse()
1836 		/* Don't check for Infinity unless the context allows it.  in duk_numconv_parse()
1882 	 *  Scan number and setup for Dragon4.  in duk_numconv_parse()
1887 	 *  be worth it: the multiplications for building 'f' are not  in duk_numconv_parse()
1892 	 *  For decimal numbers, this means generating a 20-digit significand,  in duk_numconv_parse()
1896 	 *  to round the 20th digit upwards).  For non-decimal numbers, the  in duk_numconv_parse()
1897 	 *  appropriate number of digits has been precomputed for comparable  in duk_numconv_parse()
1913 	 *    dig_lzero is only computed for whole number part  in duk_numconv_parse()
1936 	for (;;) {  in duk_numconv_parse()
1952 			 * is checked for after the loop.  in duk_numconv_parse()
1983 			/* Note: we don't parse back exponent notation for anything else  in duk_numconv_parse()
2085 	/* Validity checks for various fraction formats ("0.1", ".1", "1.", "."). */  in duk_numconv_parse()
2145 		/* Fast path is triggered for no exponent and also for balanced exponent  in duk_numconv_parse()
2146 		 * and fraction parts, e.g. for "1.23e2" == "123".  Remember to respect  in duk_numconv_parse()
2188 	 * would be incorrect for zero (e.g. "0e1000" is zero, not Infinity)  in duk_numconv_parse()
2216 	 *  An extra digit is generated for rounding.  in duk_numconv_parse()