google / double-conversion Goto Github PK
View Code? Open in Web Editor NEWEfficient binary-decimal and decimal-binary conversion routines for IEEE doubles.
License: BSD 3-Clause "New" or "Revised" License
Efficient binary-decimal and decimal-binary conversion routines for IEEE doubles.
License: BSD 3-Clause "New" or "Revised" License
I am trying to implement suggestion by @Neumann-A about properly using double-conversion in ITK. My attempt is here.
I cloned double-conversion
into C:\Misc\double-conversion\
and built it using VS2017 in C:\Misc\double-conversion\vs2017\
. If I point double-conversion_DIR
during ITK configuration to C:\Misc\double-conversion\vs2017\generated
I get CMake configure error:
CMake Error at C:/Misc/double-conversion/vs2017/generated/double-conversionConfig.cmake:27 (include):
include could not find load file:
C:/Misc/double-conversion/vs2017/generated/double-conversionTargets.cmake
Call Stack (most recent call first):
Modules/ThirdParty/DoubleConversion/CMakeLists.txt:10 (find_package)
Rightfully so, because that folder only contains double-conversionConfig.cmake
and double-conversionConfigVersion.cmake
.
I then installed double-conversion
into C:\Misc\double-conversion\install
, and pointed ITK's double-conversion_DIR
to C:\Misc\double-conversion\install\lib\cmake\double-conversion
. This helped somewhat, but now the link library is not defined:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
ITKDoubleConversion_LIBRARIES
linked by target "ITKCommon" in directory C:/Dev/ITK-git/Modules/Core/Common/src
linked by target "ITKIOMeshVTK" in directory C:/Dev/ITK-git/Modules/IO/MeshVTK/src
linked by target "ITKIOTransformInsightLegacy" in directory C:/Dev/ITK-git/Modules/IO/TransformInsightLegacy/src
linked by target "ITKLabelVotingTestDriver" in directory C:/Dev/ITK-git/Modules/Segmentation/LabelVoting/test
linked by target "ImageRegionIterator" in directory C:/Dev/ITK-git/Examples/Iterators
linked by target "NeighborhoodIterators4" in directory C:/Dev/ITK-git/Examples/Iterators
...
Using a script to print all properties of a target, I get:
double-conversion::double-conversion ARCHIVE_OUTPUT_DIRECTORY = C:/Dev/ITK-2k17/lib
double-conversion::double-conversion AUTOGEN_ORIGIN_DEPENDS = ON
double-conversion::double-conversion AUTOMOC_COMPILER_PREDEFINES = ON
double-conversion::double-conversion AUTOMOC_MACRO_NAMES = Q_OBJECT;Q_GADGET;Q_NAMESPACE
double-conversion::double-conversion BINARY_DIR = C:/Dev/ITK-2k17/Modules/ThirdParty/DoubleConversion
double-conversion::double-conversion BUILD_WITH_INSTALL_RPATH = OFF
double-conversion::double-conversion CXX_EXTENSIONS = OFF
double-conversion::double-conversion CXX_STANDARD = 11
double-conversion::double-conversion CXX_STANDARD_REQUIRED = ON
double-conversion::double-conversion DEBUG_POSTFIX =
double-conversion::double-conversion IMPORTED = TRUE
double-conversion::double-conversion IMPORTED_CONFIGURATIONS = DEBUG;RELWITHDEBINFO
double-conversion::double-conversion IMPORTED_GLOBAL = FALSE
double-conversion::double-conversion INSTALL_RPATH =
double-conversion::double-conversion INSTALL_RPATH_USE_LINK_PATH = OFF
double-conversion::double-conversion INTERFACE_INCLUDE_DIRECTORIES = C:/Misc/double-conversion/install/include
double-conversion::double-conversion LIBRARY_OUTPUT_DIRECTORY = C:/Dev/ITK-2k17/lib
double-conversion::double-conversion NAME = double-conversion::double-conversion
double-conversion::double-conversion POSITION_INDEPENDENT_CODE = ON
double-conversion::double-conversion RUNTIME_OUTPUT_DIRECTORY = C:/Dev/ITK-2k17/bin
double-conversion::double-conversion SKIP_BUILD_RPATH = OFF
double-conversion::double-conversion SOURCE_DIR = C:/Dev/ITK-git/Modules/ThirdParty/DoubleConversion
double-conversion::double-conversion TYPE = STATIC_LIBRARY
INTERFACE_INCLUDE_DIRECTORIES
is correct, but there is no property which points to the library to be linked.
Do you have a suggestion about how to solve this problem?
Side question: why don't you support building against build tree? In install tree either debug or release version of the library can be used, which means the other configuration fails to link in Visual Studio, due to:
double-conversion.lib(double-conversion.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in tester.obj
double-conversion.lib(double-conversion.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in tester.obj
I tested the routines on Win10 VS2017 against my strtod test battery and all conversion tests passed. This is a very good sign!
Nevertheless some formatting tests failed due to the fact multiple styles for inf
& nan
literals aren't supported, e.g. excepting both 'inf'
& 'infinity'
just as Python does.
It would be nice to be able to construct StringToDoubleConverter
which is able to interpret multiple style as described in C99 standard section 7.19.6.1.8.
Maybe one way to do this is to be able to use regex for StringToDoubleConverter
infinity_symbol
& nan_symbol
.
The architecture detection in utils.h
(starting on line 56) isn't comprehensive. The case that matters to me is that it looks for __ppc__
and __powerpc__
, which are #define
d by GCC, but not _ARCH_PPC
or _ARCH_PPC64
, which are #define
d by IBM's XL C/C++ compilers (e.g., http://sourceforge.net/p/predef/wiki/Architectures/ ).
Checks when running "test-conversions", "test-ieee" and "test-strtod" fail, which is pretty much expected, since the fast floating-point behavior is deliberately imprecise.
See documentation here: https://msdn.microsoft.com/en-us/library/e7s85ffb.aspx
Should the library force "/fp:precise" behavior using the following pragma? Or shall it be up to the user to choose the correct floating-point behavior? In that case it would be good to add this to the documentation.
#pragma float_control(precise, on, push)
...
#pragma float_control(pop)
Hi everyone!
I am packaging double-conversion using conda-build (conda-forge/staged-recipes#5770)
I need to add a very small test file to check if double-conversion is installed properly.
Could you point me a very simple test file and an example about how could I use it?
My best regards,
all double-conversion headers should be correctly included with ""
instead of <>
example:
#include <double-conversion\utils.h>
should be changed to
#include "utils.h"
you are generating build failures due to that using cmake....
also system includes are not meant to be used for internal headers... also your are vulnerable to including the wrong utils.h using system headers.
Example:
Two folders:
double-conversion
double-conversion_v2
double-conversion_v2 will include the headers from double-conversion instead of double-conversion_v2
This indicates a binary-incompatible change, but there doesn't seem to be the need for one. It seems to me that commit e13e72e incorrectly changed the way the soname is created (which wasn't being done properly in 2.0 either, but that's another story).
Hello,
Do you know about Conan?
Conan is modern dependency manager for C++. And will be great if your library will be available via package manager for other developers.
Now we have famous C++ projects, including Google Flatbuffers. We could support you writing a recipe and publishing your packages on Bintray.
If you have any questions, just ask :-)
From http://code.google.com/p/double-conversion/issues/detail?id=30 :
-- sean.parent
Code inspection at: double-conversion.cc:44
Function level statics are not initialized in a thread safe manner with Visual Studio 2012 or prior. With gcc and clang thread safe initialization is optional (though required by C++11).
Could be fixed with any number of once init mechanisms, or aggregate initialization.
-- floitsch
I don't see any easy way of solving this without pulling in thread-specific headers.
I would rather just require -std=c++0x which, afaik, guarantees correct initialization.
I will discuss this with my colleagues next week and see if somebody comes up with a better solution.
-- stephen.mercer
If you simply move the function static out of the function and make it static to the file then it will be thread safe initialized. Reference this answer:
http://stackoverflow.com/questions/1962880/is-c-static-member-variable-initialization-thread-safe
So to make it thread safe, simply replace this code (and similar if you have other function-level statics):
const DoubleToStringConverter& DoubleToStringConverter::EcmaScriptConverter() {
int flags = UNIQUE_ZERO | EMIT_POSITIVE_EXPONENT_SIGN;
static DoubleToStringConverter converter(flags,
"Infinity",
"NaN",
'e',
-6, 21,
6, 0);
return converter;
}
with this code:
static DoubleToStringConverter kConverter(UNIQUE_ZERO | EMIT_POSITIVE_EXPONENT_SIGN,
"Infinity",
"NaN",
'e',
-6, 21,
6, 0);
const DoubleToStringConverter& DoubleToStringConverter::EcmaScriptConverter() {
return kConverter;
}
-- rafaelefernandez
You definitely do not want to move it out of the function because then you will run into the static initialization order problem.
The following test cases all result in a negative shift count (-1) in FillFractionals here
FastFixedDtoa( 2.10861548515811875e+15, 17, buffer, &length, &point );
FastFixedDtoa( 2.64452047982146350e+15, 17, buffer, &length, &point );
FastFixedDtoa( 3.82353004488187350e+15, 17, buffer, &length, &point );
FastFixedDtoa( 2.33131995055488594e+14, 17, buffer, &length, &point );
FastFixedDtoa( 1.91674615419831375e+15, 17, buffer, &length, &point );
FastFixedDtoa( 4.29987917825301050e+15, 17, buffer, &length, &point );
FastFixedDtoa( 8.57854524678346875e+14, 17, buffer, &length, &point );
FastFixedDtoa( 3.88706467562864350e+15, 17, buffer, &length, &point );
FastFixedDtoa( 1.54620738641213675e+15, 17, buffer, &length, &point );
FastFixedDtoa( 1.90564594624582575e+15, 17, buffer, &length, &point );
FastFixedDtoa( 1.47829189951993075e+15, 17, buffer, &length, &point );
FastFixedDtoa( 3.40787290971543450e+15, 17, buffer, &length, &point );
(When the test is performed, in all of these cases fractionals = 0
and point = 0
.)
Buildroot is building Qt5 for a large number of architectures, and the build now fails on Microblaze and OpenRISC architecture because the copy of the double-conversion library in Qt5 doesn't have support for those architecture.
I am willing to test on those architectures what needs to be tested, but unfortunately the comment at https://github.com/google/double-conversion/blob/master/double-conversion/utils.h#L60 is not clear enough (to me) to know what to test.
Also, wouldn't it make sense for the code in utils.h to assume that DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS is false for unsupported/unknown architectures ?
Erlang-jiffy keeps a local copy of this double-conversion library and its build is failing in Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764500
Erlang-jiffy's author would not like to implement the support in erlang-jiffy only diverging from this codebase:
davisp/jiffy#74
I was wondering whether you'd accept a PR that adds a new function corresponding to exactly what we've been using for quite a while now from our slightly hacked copy of the double-conversion library, namely a Strtod()
that starts with double guess
, i.e. skips all the trimming and stuff (that we don't need because the PEGTL grammar in our JSON library implicitly ensures that no leading zeros etc. are passed to our Strtod()
).
In other words this would split Strtod()
into two functions, keeping the current name with the current functionality. Of course then the big question would be how to name the "back-end" function that starts with double guess
, would StrtodMain()
or StrtodImpl()
be acceptable?
The last tagged release is dated from 2014 and quite a few fixes have landed in the code base since then. Would you guys consider tagging a new release with the appropriate version bump?
Cheers,
Hi everyone,
I packaged double-conversion using conda-build but it seems I am missing something.
conda package is a pre-built package, so when I install the conda package in my machine, it just save binary files and some extra files to my conda environment.
After installed double-conversion (with conda) I am trying to build facebook/folly and it raises this error:
checking for ceil in -ldouble-conversion... no
configure: error: Please install double-conversion library
on folly I found this references on build step:
maybe my conda-build log could help:
source tree in: /opt/miniconda/conda-bld/folly_1526340035536/work
INFO: activate-binutils_linux-64.sh made the following environmental changes:
+ADDR2LINE=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-addr2line
+AR=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ar
+AS=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-as
+CXXFILT=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-c++filt
+ELFEDIT=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-elfedit
+GPROF=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gprof
+HOST=x86_64-conda_cos6-linux-gnu
+LD=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld
+LD_GOLD=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld.gold
+NM=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-nm
+OBJCOPY=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-objcopy
+OBJDUMP=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-objdump
+RANLIB=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ranlib
+READELF=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-readelf
+SIZE=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-size
+STRINGS=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-strings
+STRIP=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-strip
INFO: activate-gcc_linux-64.sh made the following environmental changes:
+CC=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-cc
+CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+CPP=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-cpp
+CPPFLAGS=-DNDEBUG -D_FORTIFY_SOURCE=2 -O2
+DEBUG_CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -pipe -I/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+DEBUG_CPPFLAGS=-D_DEBUG -D_FORTIFY_SOURCE=2 -Og
+GCC=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc
+GCC_AR=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc-ar
+GCC_NM=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc-nm
+GCC_RANLIB=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc-ranlib
+LDFLAGS=-Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/lib -L/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/lib
+_CONDA_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_x86_64_conda_cos6_linux_gnu
INFO: activate-gxx_linux-64.sh made the following environmental changes:
+CXX=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-c++
+DEBUG_CXXFLAGS=-fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -pipe -I/opt/miniconda/conda-bld/folly_1526340035536/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_pla/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+GXX=/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-g++
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: creating directory build-aux
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running: /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/autoconf --force
autoreconf: running: /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:32: installing 'build-aux/compile'
configure.ac:32: installing 'build-aux/config.guess'
configure.ac:32: installing 'build-aux/config.sub'
configure.ac:27: installing 'build-aux/install-sh'
configure.ac:27: installing 'build-aux/missing'
Makefile.am: installing 'build-aux/depcomp'
parallel-tests: installing 'build-aux/test-driver'
autoreconf: Leaving directory `.'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for style of include used by make... GNU
checking for gcc... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc accepts -g... yes
checking for /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc option to accept ISO C89... none needed
checking whether /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc understands -c and -o together... yes
checking dependency style of /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld
checking if the linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-nm
checking the name lister (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld option to reload object files... -r
checking for objdump... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... @
checking for strip... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-strip
checking for ranlib... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ranlib
checking command to parse /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-nm output from /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking how to run the C preprocessor... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-cpp
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no
checking for /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc option to produce PIC... -fPIC -DPIC
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc PIC flag -fPIC -DPIC works... yes
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc static flag -static works... yes
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc supports -c -o file.o... yes
checking if /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc supports -c -o file.o... (cached) yes
checking whether the /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64
checking if the linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for gcc... (cached) /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc accepts -g... (cached) yes
checking for /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc option to accept ISO C89... (cached) none needed
checking whether /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc understands -c and -o together... (cached) yes
checking dependency style of /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/x86_64-conda_cos6-linux-gnu-gcc... (cached) gcc3
checking if g++ supports C++1y features without additional flags... yes
checking if g++ supports C++1y features with -std=c++1y... yes
checking if g++ supports C++1y features with -std=gnu++1y... yes
checking whether -Wshadow-local and -Wshadow-compatible-local are supported... yes
checking for main in -lgflags... yes
checking for gflags viability... yes
checking for pkg-config... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gflags... yes
checking for main in -lglog... yes
checking for glog viability... yes
checking for libglog... yes
configure: WARNING: "Using existing OpenSSL flags from environment."
checking for openssl... yes
checking for boostlib >= 1.51.0... yes
checking whether the Boost::Context library is available... yes
checking for exit in -lboost_context-mt... yes
checking whether the Boost::Program_Options library is available... yes
checking for exit in -lboost_program_options-mt... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Regex library is available... yes
checking for exit in -lboost_regex-mt... yes
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Filesystem library is available... yes
checking for exit in -lboost_filesystem... yes
checking whether the Boost::Chrono library is available... yes
checking for exit in -lboost_chrono-mt... yes
checking for python... /opt/miniconda/conda-bld/folly_1526340035536/_build_env/bin/python
checking for python version... 3.6
checking for python platform... linux
checking for python script directory... ${prefix}/lib/python3.6/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python3.6/site-packages
checking for ANSI C header files... (cached) yes
checking features.h usability... yes
checking features.h presence... yes
checking for features.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking bits/functexcept.h usability... yes
checking bits/functexcept.h presence... yes
checking for bits/functexcept.h... yes
checking bits/c++config.h usability... yes
checking bits/c++config.h presence... yes
checking for bits/c++config.h... yes
checking double-conversion/double-conversion.h usability... yes
checking double-conversion/double-conversion.h presence... yes
checking for double-conversion/double-conversion.h... yes
checking for ceil in -ldouble-conversion... no
configure: error: Please install double-conversion library
this is my build script: https://github.com/conda-forge/double-conversion-feedstock/blob/master/recipe/build.sh
this is my build requirements: https://github.com/conda-forge/double-conversion-feedstock/blob/master/recipe/meta.yaml#L20
Any help will be very appreciated. Thanks.
From http://code.google.com/p/double-conversion/issues/detail?id=36 :
When the FPU control word or _MM_SET_FLUSH_ZERO_MODE is toggled the algorithm doesn't work.
-- stephen.mercer
Can you go into more detail about the severity of this? If we were to use your code in our application, when would this occur? What could we do to prevent it? And when the algorithm doesn't work, does that mean your strings are junk or are they just not the shortest strings?
-- floitsch
_MM_SET_FLUSH_ZERO_MODE is used to flush denormals to 0 (see http://en.wikipedia.org/wiki/Denormal_number).
Quoting Arash Partow (author of http://www.codeproject.com/Articles/23198/C-String-Toolkit-StrTk-Tokenizer):
"But in short both the atod and dtoa functionalities of [the double-conversion] library have issues with double and float types when values approach denormalized but are not denormalized, there is inconsistent behavior from what is expected when the FPU control word or _MM_SET_FLUSH_ZERO_MODE is toggled - both from a performance and precision standpoint."
If you don't modify the __MM_SET_FLUSH_ZERO_MODE flag, or if you don't care about numbers with an absolute value <= 2.2250738585072009 × 10^−308 (or close to it), you should be fine.
https://github.com/ulfjack/ryu
https://www.reddit.com/r/programming/comments/92dncd/ry%C5%AB_fast_floattostring_conversion/
On my laptop I quickly measured Ryū to almost be 4X faster than double-conversion.
The implementation in the GitHub repository above lacks the output format flexibility offered by double-conversion, so that would need to be addressed.
$ cmake -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DLIB_SUFFIX=64 ..
[...]
CMake Warning:
Manually-specified variables were not used by the project:
LIB_INSTALL_DIR
LIB_SUFFIX
$ make
[...]
$ make -s install
[100%] Built target double-conversion
Install the project...
-- Install configuration: ""
CMake Error at cmake_install.cmake:41 (file):
file cannot create directory: /usr/local/lib. Maybe need administrative
privileges.
The lib dir /usr/local/lib
is wrong. It should be lib64
.
scons adds -fPIC but cmake does not.
Adding this to double-conversion/src/CMakeLists.txt solved my problem:
if (CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
set_target_properties(double-conversion PROPERTIES COMPILE_FLAGS "-fPIC")
endif()
clang give 2 warnings:
utils.h:166:10: warning: unused function template 'Max' [-Wunused-template]
static T Max(T a, T b) {
^
utils.h:173:10: warning: unused function template 'Min' [-Wunused-template]
static T Min(T a, T b) {
^
I suspect it has to do with the 'static' declaration...
Update README file to also include info on how to build with using Bazel @mzhaom? Thanks!
Right now I'm developing a C library for a system called CloudABI (more details: https://github.com/NuxiNL/cloudlibc). As this double-conversion code is supposed to be faster than David M. Gay's gdtoa implementation (and also a lot more readable), my intent is to use this code to implement strto{f,d,ld}() and printf()'s %f. So far things are going all right. strtof() and strtod() already work as expected. My next task is getting printf() to work.
It looks like double-conversion only supports float and double. This is a bit problematic, as strtold() and printf()'s %Lf are supposed to parse and print floating point numbers with larger precision. Are there any plans to add 80/128-bit long double support to double-conversion?
Thanks!
The routine from bignum-dtoa.cc:
static void FixupMultiply10(int estimated_power, bool is_even,
int* decimal_point,
Bignum* numerator, Bignum* denominator,
Bignum* delta_minus, Bignum* delta_plus) {
bool in_range;
if (is_even) {
// For IEEE doubles half-way cases (in decimal system numbers ending with 5)
// are rounded to the closest floating-point number with even significand.
in_range = Bignum::PlusCompare(*numerator, *delta_plus, *denominator) >= 0;
} else {
in_range = Bignum::PlusCompare(*numerator, *delta_plus, *denominator) > 0;
}
if (in_range) {
// Since numerator + delta_plus >= denominator we already have
// 1 <= numerator/denominator < 10. Simply update the estimated_power.
*decimal_point = estimated_power + 1;
} else {
*decimal_point = estimated_power;
numerator->Times10();
if (Bignum::Equal(*delta_minus, *delta_plus)) {
delta_minus->Times10();
delta_plus->AssignBignum(*delta_minus);
} else {
delta_minus->Times10();
delta_plus->Times10();
}
}
}
Why do you add delta_plus to numerator and then compare the sum to denominator ? Do we really need delta_plus here ? Can we just write (and forget is_even as well):
in_range = Bignum::Compare(*numerator, *denominator) >= 0;
It works fine for BignumDtoaGayShortest test, too.
According to my understanding the numerator must greater than or equal to denominator here, so that no leading 0 digit will be produced by GenerateShortestDigits.
In utils.h, DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS is set to 1 only for architectures known to work correctly (and it's unset for architectures known not to support). For unknown architectures, a compile time error is emitted with #error pragma.
PNaCl (portable native client) is taken to '#error' branch. This was discovered when compiling ICU 61 for Chromium (ICU 61 does have a version of double-conversion library).
#elif defined(__pnacl__) || defined(__native_client__)
#undef DOUBLE_CONVERSION_CORRECT_DOUBLE_OPERATIONS
#else // final #else
#error "Target ... not detected s supported by Double-Conversion
#endif
Perhaps adding one more #elif branch for PNaCl (and NaCl) as above would work.
When using double_conversion::DoubleToStringConverter::DoubleToAscii()
with mode=PRECISION
and requested_digits=6
, I find that the input 5735285 generates digits 573529.
I believe it should be 573528 (with the last digit rounded even), as produced by David M. Gay's dtoa
with mode 2.
What do you think about case insensibility for special values infinity
and NaN
?
Performance penalty not particularly noticeable in my tests.
The problem lies in DigitGenCounted (in fast-dtoa.cc):
If the fraction is 0 after the first iteration generating the integrals, then the second iteration will be skipped, and less than the requested number of digits (will typically) have been generated, resulting in the method return false, which then leads to a fallback to bignum based conversion.
It's trivial to add a check for the fraction being exactly zero after the first iteration, and then padding with 0 up to the requested number of digits.
What I however can't (yet) answer with 100% certainty is whether this could generate wrong results for some input? (I don't really think so).
The performance issue is seen e.g. for any number in form N*10^M
line 456: ~((static_cast<uint64_t>(1) << (64 - bit_size)) - 1);
Is undefined behavior, since 64-bit_size could be negative.
From http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/n4594.pdf:
The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned
type, the value of the result is E1 × 2
E2, reduced modulo one more than the maximum value representable in
the result type. Otherwise, if E1 has a signed type and non-negative value, and E1 × 2
E2 is representable
in the corresponding unsigned type of the result type, then that value, converted to the result type, is the
resulting value; otherwise, the behavior is undefined.
3 The value of E1 >> E2 is E1 right-shifted E2 bit positive
The template type Iterator
is used throughout double-conversion.cpp. It appears that Iterator
can be one of two types:
const uc16*
const char*
There is a function Advance
whose signature is:
template<class Iterator>
static bool Advance (Iterator* it, char separator, int base, Iterator& end)
The call sites look like this:
// current is of type Iterator
Advance(¤t, separator_, 10, end)
The problem is that separator_
is being downcast to a char
even when using the uc16*
template type for the string. The implication is that there is a possible loss of information; for example, the separator might be a Unicode code point that doesn't fit in a char. A great real-life example could be 'NARROW NO-BREAK SPACE' (U+202F), which is now used in CLDR as the default grouping separator in France.
The code should be checked to ensure that separator_
is not downcast to a char
unless the iterator is a char
iterator.
C:\src\vcpkg\installed\x64-windows\include\double-conversion\double-conversion.h(31): fatal error C1083: Cannot open include file: 'double-conversion/utils.h': No such file or directory
is the error encountered. More information can be found in vcpkg's issue.
I'm neeewb how the shit does this work
I've noticed a fairly large class of numbers for which double-conversion is slow to produce the shortest decimal representation. Here's a test case:
#include "double-conversion.h"
using namespace double_conversion;
int main()
{
size_t i = 0;
for (int j = 0; j < 5e6; j++)
{
#ifdef FAST
double d = (rand() % 1000000) / 100000.0; // 10^5
#else
double d = (rand() % 1000000) / 131072.0; // 2^17
#endif
char buf[20];
bool s;
int length, decpt;
DoubleToStringConverter::DoubleToAscii(d, DoubleToStringConverter::SHORTEST, 0, buf, sizeof buf, &s, &length, &decpt);
i += strlen(buf);
}
return i % 1000;
}
On my machine (Ubuntu 15.10, Haswell CPU) I get:
$ g++ -O3 *.cc -o foo -DFAST && time ./foo
real 0m0.446s
user 0m0.444s
sys 0m0.000s
$ g++ -O3 *.cc -o foo && time ./foo
real 0m2.402s
user 0m2.400s
sys 0m0.000s
So for random integers divided by 2^17 it's running 6x slower than for some other random inputs. Profiling shows that this is because FastDtoa() is usually (always?) failing, so it has to fall back to BignumDtoa(). Is this expected? Is there a way to make FastDtoa() cope with more cases?
Incidentally, I noticed this when benchmarking our software (which now uses double-conversion) against a previous version that used David Gay's dtoa(), using his mode 4 to get the shortest representation but limited to 10 digits. double-conversion doesn't seem to have an equivalent of mode 4, so we're forced to use SHORTEST mode, which makes double-conversion appear slower than dtoa() on random integers / 2^17.
This is a little test I appended to TEST(DoubleToShortest)
for (int i = 0; i <= 100; ++i) {
char buffer[10];
builder.Reset();
CHECK(dc.ToShortest(i*0.1, &builder));
if (i % 10 == 0) {
sprintf(buffer, "%d", i/10);
CHECK_EQ(buffer, builder.Finalize());
} else {
sprintf(buffer, "%d.%d", (i/10), (i%10));
CHECK_EQ(buffer, builder.Finalize());
}
}
And the first failure is:
CHECK_EQ(buffer, builder.Finalize()) failed
# Expected: 0.3
# Found: 0.30000000000000004
I realize that 3*0.1 != 0.3
due to floating point limitations, but for my purposes its close enough that I wish I had some way to tell ToShortest to truncate it.
Another issue not strictly related to JavaScript, would be nice to see support for a configurable separator character. It's ok if it's a single character, this way numbers like 1_000_000 and 1'000'000 could be parsed without having to pre-process them.
When I tried to compile Chrome with ICU 61 (that includes this library) on Windows with clang in MSVC compatibility mode(?), I got a warning from clang about unused typedef. Because Chrome is built with 'treat error as warning' (-Werror), it leads to a compile failure. I can turn off the warning(-Wno-unused-local-typedef ) for ICU when building Chrome.
However, it'd be nice to support this toolchain.
// Compile time assertion: sizeof(Dest) == sizeof(Source)
// A compile error here means your Dest and Source have different sizes.
DOUBLE_CONVERSION_UNUSED
typedef char VerifySizesAreEqual[sizeof(Dest) == sizeof(Source) ? 1 : -1];
Earlier in utils.h, DOUBLE_CONVERSION_UNUSED is defined as following:
#if defined(__GNUC__)
#define DOUBLE_CONVERSION_UNUSED __attribute__((unused))
#else
#define DOUBLE_CONVERSION_UNUSED
#endif
I guess clang on Windows (along with MSVC) would not have GNUC defined and DOUBLE_CONVERSION_UNSED
becomes empty. OTOH, clang on Linux/Mac has GNUC defined.
Before submitting another insane PR I'd like to explain where I'm coming from, and where I'm headed for.
Back in November 2015, when we added this library to our JSON library for double-to-string and string-to-double conversions (because it was the only one that always got string-to-double right), we had to make one big change:
The creation of a header-only version of Strtod()
(or rather, what is now StrtodTrimmed()
) by basically copying Strtod()
into an empty header file and adding everything it depends on (marking functions as inline
as required) until it worked...
(The code is very "clean" in that it compiles with -std=c++17 -Wall -Werror -pedantic
even on more modern compilers, kudos!)
Now, in order to allow for easier future updates of the double-conversion part in our JSON library, I wanted to see to which degree it was possible to close the gap between the current form, and the partial header-only form that we would require.
(Where "possible" is to be understood both in terms of technically possible, and in line with your development style and plans for the future.)
So what I'd like to do, if possible, is eliminate all *.cc
files except for string-to-double.cc
and double-to-string.cc
by moving everything into the respective *.h
files, making sure everything is marked as inline
. Then some *.h
files could be split up, e.g. by moving StringBuilder
into a dedicated file etc. Finally the namespace could become a macro to make changing it easier.
Then we could simply copy strtod.h
, and all other headers it depends on, and take it from there. Now we realise that's probably a rather non-standard use-case, which is why I wanted to check in first and see whether this would be ok with you...
Final note, in case you are wondering what the commits I have submitted so far have to do with creating a partial header-only version of this library, the answer is that I simply wanted to (re)acquaint myself a bit more with the code, and understanding enough to make some contributions (in the direction of more idiomatic "modern" C++, or some small simplifications) is one way I use to get to know a piece code.
Thank you for listening, hope I'm not taking too much of your time ;-)
This assertion in bignum.cc in DivideModuloIntBignum
fails for the two bignums A = 0x11100000
and B = 100000
. But A/B = 0x111
and as I understand it the function should be able two handle these inputs.
Now, I don't understand the intent of this assertion. It seems to check that the leading bigit of other
is >= 2^(28-4)
which indicates that other
should be some kind of normalized...? Just commenting it out, the function produces the correct results... so, is the assertion correct here?
FWIW, there are other numbers for which the assertion fails, which came up while trying to speed up GenerateCountedDigits in bignum-dtoa.cc: https://github.com/effzeh/double-conversion/commit/57a09e673e57abe2fc78a8892da9cc8019d7c92a
When I use reactnative Integration in an with Existing Apps. I get an error .
nstalling DoubleConversion (1.1.5)
[!] /bin/bash -c
set -e
mv src double-conversion
mv: rename src to double-conversion: No such file or directory
On Fedora, 64-libraries need to get installed into /usr/lib64.
Doing a checkout at 0e47d5a in January works, however top of tree reports the following, and it is not possible to build with the current cmake scripts.
CMake Error at CMakeLists.txt:44 (install):
install TARGETS given no ARCHIVE DESTINATION for static library target
"double-conversion".
CMake Warning (dev) in CMakeLists.txt:
No cmake_minimum_required command is present. A line of code such as
cmake_minimum_required(VERSION 3.4)
should be added at the top of the file. The version specified may be lower
if you wish to support older CMake versions for this project. For more
information run "cmake --help-policy CMP0000".
This warning is for project developers. Use -Wno-dev to suppress it.
-- Configuring incomplete, errors occurred!
The produced output 1.8011300000000001 is at least not what I would expect from ToShortest.
This code path doesn't generate a fallback to bignum calculations. I can't fully deduce from the comments whether this is intentionally.
But the net outcome is that this makes ToShortest a no go for our usage.
We have implemented an overlay of ToShortest that takes an additional max_digits input that we can use to solve the problem, but I'm wondering whether there is a better / more general solution.
TEST(FooBar)
{
double f = 1.7976931348623157e308;
const int kBufferSize = 128;
char buffer[kBufferSize];
StringBuilder builder(buffer, kBufferSize);
DoubleToStringConverter dc(0, NULL, NULL, 'e', -4, 17, 0, 0);
dc.ToExponential(f, 14, &builder);
const char* str = builder.Finalize();
StringToDoubleConverter sc(0, 0.0, 1.0, "inf", "nan");
int count;
double f2 = sc.StringToDouble(str, strlen(str), &count);
CHECK(fabs(f - f2) < 1000.0);
}
This may be extreme. When requested_digits
is 14, the max value of double 1.7976931348623157e308
is rounded-up to "1.79769313486232e308"
; If you read this string back to double, you will get an inf
value.
You can use define _M_ARM
for that
Hi everyone!
we are trying to update the double-conversion conda package to v3.1.2* but it is raising an error in the tests.
[100%] Linking CXX executable cctest
[100%] Built target cctest
$SRC_DIR/test/cctest/test-conversions.cc:3611:
CHECK_EQ(3.0, StrToD16("[email protected]", flags, 0.0, &processed, &all_used, char_separator, separator)) failed
# Expected: 3.000000000000000000000000000000e+00
# Found: 3.500000000000000000000000000000e+01
xargs: test/cctest/cctest: terminated by signal 6
any idea about what could be the problem? thanks!
I know this library originated from V8 so JavaScript is the primary client, but it would be nice to support parsing of hex-float literals as allowed in modern C++ as well (http://en.cppreference.com/w/cpp/language/floating_literal).
This is a faster and complete way to do double conversation.
http://cseweb.ucsd.edu/~lerner/papers/fp-printing-popl16.pdf
Thank you for making double-conversion!
Though it has a very unintuitive interface, the "standard" strtod/strtof can detect the following errors:
fprintf(stderr, "%s: not a decimal number\n", buff);
fprintf(stderr, "%s: extra characters at end of input: %s\n", buff, end);
fprintf(stderr, "%s out of range of type double/float\n", buff);
How can I accomplish the same thing with StringToDoubleConverter ?
How can I detect all of those error cases (ideally separately, but how can I even detect that one of them has happened regardless of which one) while also using the "nan"/"inf" parsing feature?
It seems I can detect "extra characters" with
processed_characters_count < length
But what about overflow and other malformed string errors?
If I set junk_string_value/empty_string_value to NaN then I lose the useful feature of the routine by which it detects the "nan" string (I cannot tell if the string is a well-formed "nan" or whether the string contains malformed content that got mapped to junk_string_value/empty_string_value==NaN).
Is there a way to do this currently? If so, please add it to the dox in double-conversion.h. If not, can we add it?
Thanks
@abrodkin filed this against ICU's import of double-conversion:
and an associated PR:
From http://code.google.com/p/double-conversion/issues/detail?id=51 :
When I tried to use double-conversion with hhvm building process, I was required to manually copy *.h files to respected folders. Otherwise hhvm build was unable to locate them.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.