Hello, On 2018-01-26 00:54, petern wrote:
I am interested to see your solution where NUMERIC CAST has sensible interpretation between MAX_INT and MAX_REAL.
The patch focuses on problems with TEXT=>NUM conversions. The sole exception is INT=>FLOAT, when a value could lose an information.
IMO, simple INT saturation is not convenient for easy overflow detection in SQL. So there is work to be done where the upcasted number is large but not quite large enough for REAL saturation. Nearby upcasted INTs must sort sensibly.
Indeed -- INT saturation is for more predictability of INTEGER CAST's results, when converted from TEXTs.
Also, what happens to overflowing hex constants and from BLOB casts?
HEX is not touched by CASTs and AFFINITIes (from TEXT).
It is important to curate such patches in case the priority for execution speed/size cannot be reconciled with accuracy and generality. If your improvements make v3.23 slower or larger than v3.22, they may be rejected.
My patch is not to be released as a replacement of SQLite. Speed tests showed that it is faster (even 10-30%) then SQLite, but only due to a fact that SQLite until 3.21 did not use an exponentiation by squares -- this is improved in SQLite 3.22. (I have not made the patch for 3.22 yet.) The patch is to illustrate the problem and as a reference.
Nevertheless, I think users who prioritize dependability, accuracy, and generality over slightly degraded executable speed/size will be very interested to have your long form improvements.
I'm using few compilers and platforms. There are many surprising constructs which can be 30% faster on old VS2005 (the last which produced EXE for Win16 -- aka 98/ME) then on VS2015. Fountain of bugs is a main problem in Watcom. MSVC has a buggy preprocessor (I have not tried VS2017 yet) which is grinding all macro from the beginning to the end, every round until there is nothing to expand. GCC had a minor problem with ASAN (mentioned on this list), and with a comparison of doubles<=>int64s (mentioned/fixed recently by DRH), and so on, and so on. If the patch is to illustrate the problem (if any), I do not want to obfuscate it and I'm trying to use most universal constructs.
Besides that IMHO the problem (with trailing spaces and loss of precision) is too complicated to be effectively (and universally) resolved by someone other (me for sure) then the team.
On the other side, the problem with saturation is completely resolvable by adding 5 characters to ``Atoi64()''.
-- best regards Cezary H. Noweta _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
