Eric-coder
diff --git a/‎include/simdjson/common_defs.h
Lines changed: 6 additions & 44 deletions b/‎include/simdjson/common_defs.h
Lines changed: 6 additions & 44 deletions
diff --git a/‎include/simdjson/generic/numberparsing.h
Lines changed: 172 additions & 140 deletions b/‎include/simdjson/generic/numberparsing.h
Lines changed: 172 additions & 140 deletions
diff --git a/‎include/simdjson/internal/jsoncharutils_tables.h
Lines changed: 0 additions & 9 deletions b/‎include/simdjson/internal/jsoncharutils_tables.h
Lines changed: 0 additions & 9 deletions
diff --git a/‎include/simdjson/internal/numberparsing_tables.h
Lines changed: 43 additions & 11 deletions b/‎include/simdjson/internal/numberparsing_tables.h
Lines changed: 43 additions & 11 deletions
@@ -13,6 +13,12 @@ namespace internal {
  * Defined in src/to_chars
  */
 char *to_chars(char *first, const char *last, double value);
+/**
+ * @private
+ * A number parsing routine.
+ * Defined in src/from_chars
+ */
+double from_chars(const char *first) noexcept;
 }
 
 #ifndef SIMDJSON_EXCEPTIONS
@@ -209,48 +215,4 @@ namespace std {
 #define SIMDJSON_TRY(EXPR) { auto _err = (EXPR); if (_err) { return _err; } }
 
 
-/**
- * We may fall back on the system's number parsing, and we want
- * to be able to call a locale-insensitive number parser. It unfortunately
- * means that we need to load up locale headers.
- * The locale.h header is generally available:
- */
-#include <locale.h>
-/**
- * Determining whether we should import xlocale.h or not is 
- * a bit of a nightmare. Visual Studio and recent recent GLIBC (GCC) do not need it. 
- * However, FreeBSD and Apple platforms will need it.
- * And we would want to cover as many platforms as possible.
- */
-#ifdef __has_include
-// This is the easy case: we have __has_include and can check whether
-// xlocale is available. If so, we load it up.
-#if __has_include(<xlocale.h>)
-#include <xlocale.h>
-#endif // __has_include
-#else // We do not have __has_include
-// Here we do not have __has_include
-// We first check for __GLIBC__
-#ifdef __GLIBC__ // If we have __GLIBC__ then we should have features.h which should help.
-// Note that having __GLIBC__ does not imply that we are compiling against glibc. But
-// we hope that any platform that defines __GLIBC__ will mimick glibc.
-#include <features.h>
-// Check whether we have an old GLIBC.
-#if !((__GLIBC__ > 2) || ((__GLIBC__ == 2) && (__GLIBC_MINOR__ > 25)))
-#include <xlocale.h> // Old glibc needs xlocale, otherwise xlocale is unavailable.
-#endif // !((__GLIBC__ > 2) || ((__GLIBC__ == 2) && (__GLIBC_MINOR__ > 25)))
-#else // __GLIBC__
-// Ok. So we do not have __GLIBC__
-// We assume that everything that is not GLIBC and not on old freebsd or windows
-// needs xlocale.
-// It is likely that recent FreeBSD and Apple platforms load xlocale.h next:
-#if !(defined(_WIN32) || (__FreeBSD_version < 1000010))
-#include <xlocale.h> // Will always happen under apple.
-#endif // 
-#endif //  __GLIBC__
-#endif // __has_include
-/**
- * End of the crazy locale headers.
- */
-
 #endif // SIMDJSON_COMMON_DEFS_H
@@ -11,15 +11,6 @@ void found_bad_string(const uint8_t *buf);
 
 namespace simdjson {
 namespace internal {
-
-constexpr int FASTFLOAT_SMALLEST_POWER = -325;
-constexpr int FASTFLOAT_LARGEST_POWER = 308;
-
-struct value128 {
-  uint64_t low;
-  uint64_t high;
-};
-
 // structural chars here are
 // they are { 0x7b } 0x7d : 0x3a [ 0x5b ] 0x5d , 0x2c (and NULL)
 // we are also interested in the four whitespace characters
 
@@ -5,22 +5,54 @@
 
 namespace simdjson {
 namespace internal {
+/**
+ * The smallest non-zero float (binary64) is 2^−1074.
+ * We take as input numbers of the form w x 10^q where w < 2^64.
+ * We have that w * 10^-343  <  2^(64-344) 5^-343 < 2^-1076.
+ * However, we have that 
+ * (2^64-1) * 10^-342 =  (2^64-1) * 2^-342 * 5^-342 > 2^−1074.
+ * Thus it is possible for a number of the form w * 10^-342 where 
+ * w is a 64-bit value to be a non-zero floating-point number.
+ *********
+ * Any number of form w * 10^309 where w>= 1 is going to be 
+ * infinite in binary64 so we never need to worry about powers
+ * of 5 greater than 308.
+ */
+constexpr int smallest_power = -342;
+constexpr int largest_power = 308;
+
+/**
+ * Represents a 128-bit value.
+ * low: least significant 64 bits.
+ * high: most significant 64 bits.
+ */
+struct value128 {
+  uint64_t low;
+  uint64_t high;
+};
+
 
 // Precomputed powers of ten from 10^0 to 10^22. These
 // can be represented exactly using the double type.
 extern SIMDJSON_DLLIMPORTEXPORT const double power_of_ten[];
-// The mantissas of powers of ten from -308 to 308, extended out to sixty four
-// bits. The array contains the powers of ten approximated
-// as a 64-bit mantissa. It goes from 10^FASTFLOAT_SMALLEST_POWER to 
-// 10^FASTFLOAT_LARGEST_POWER (inclusively). 
-// The mantissa is truncated, and
-// never rounded up. Uses about 5KB.
-extern SIMDJSON_DLLIMPORTEXPORT const uint64_t mantissa_64[];
-// A complement to mantissa_64
-// complete to a 128-bit mantissa.
-// Uses about 5KB but is rarely accessed.
-extern SIMDJSON_DLLIMPORTEXPORT const uint64_t mantissa_128[];
 
+
+/**
+ * When mapping numbers from decimal to binary,
+ * we go from w * 10^q to m * 2^p but we have
+ * 10^q = 5^q * 2^q, so effectively
+ * we are trying to match
+ * w * 2^q * 5^q to m * 2^p. Thus the powers of two
+ * are not a concern since they can be represented
+ * exactly using the binary notation, only the powers of five
+ * affect the binary significand.
+ */ 
+
+
+// The truncated powers of five from 5^-342 all the way to 5^308
+// The mantissa is truncated to 128 bits, and
+// never rounded up. Uses about 5KB.
+extern SIMDJSON_DLLIMPORTEXPORT const uint64_t power_of_five_128[];
 } // namespace internal
 } // namespace simdjson