Code: Select all
/c game.print(game.table_to_json{v=1/3})
Code: Select all
/c game.print(game.table_to_json{v=1/3})
Code: Select all
/c local v = 0.1 + 2^- 55
game.print(serpent.line(
game.json_to_table(game.table_to_json{v = v}).v == v
))
Code: Select all
trio_snprintf(buffer, sizeof(buffer), "%.*g", DBL_MANT_DIG, value);
Code: Select all
#define DBL_MANT_DIG 53 // # of bits in mantissa
Well, I think, despite what the thread title says, the main problem here is that double -> str -> double didn't end up in the exactly same number (when it had enough digits available to exactly represent the original number). If we can work that out, we could turn mod settings back to json format. The fact that it uses more digits than it needs is secondary imho.boskid wrote: ↑Sat Jan 04, 2020 8:33 pmIt is obvious that for each bit of mantissa, we need at least one character on outputCode: Select all
#define DBL_MANT_DIG 53 // # of bits in mantissa
Code: Select all
typedef double trio_long_double_t;
Code: Select all
string.format("%#11.5g", 10e5)
Indeed. I guess it's time to look into using stb_sprintf for float to str formatting or maybe even all string formatting.Hornwitser wrote: ↑Sun Jan 05, 2020 5:58 amEdit: another interesting note is that in Microsoft Visual C++ the long double data type correspond to double instead of the 80-bit extended precision data type that other compilers use, maybe that's the reason for the long double to double change.
That's the root issue of why it's currently using so many digits: because the conversion just doesn't work correctly when going binary -> string -> binary. I kept upping the number of digits until I gave up on it and just changed the mod-settings.json file to mod-settings.dat at which point the issue(s) stopped happening because we have a competent serialization system for saving data.Hornwitser wrote: ↑Sat Jan 04, 2020 5:40 pmThe second is that there's floating point values for which the encoding to JSON and decoding back to Lua doesn't produce the same value
IEEE 754 guarantees that converting a double precision float into decimal with 17 digits of precision and back into a double precision float will give you the exact same bit representation (with the exception of nan encodings) provided the conversion routine has the necessary precision. The reason you don't see this happen on your system is because you use a library written for Linux like systems that depend on a high precision data type that doesn't exist on MSVC. Adding more digits to the conversion doesn't fix the conversion being broken from lacking the necessary precision to do it correctly.Rseding91 wrote: ↑Mon Jan 13, 2020 9:53 pmThat's the root issue of why it's currently using so many digits: because the conversion just doesn't work correctly when going binary -> string -> binary. I kept upping the number of digits until I gave up on it and just changed the mod-settings.json file to mod-settings.dat at which point the issue(s) stopped happening because we have a competent serialization system for saving data.
Base64 is not a viable option: the encoder in util uses 10ms to encode 1kb of data and from what I've heard of people trying to improve it there isn't much to be done about it, converting data to base64 is unusably slow in Lua.Rseding91 wrote: ↑Mon Jan 13, 2020 9:53 pmUnless someone else wants to look into this I'm moving this to minor issues and I don't consider it worth the time to look into. If anything I suggest mods encode their own data in binary format, convert to base 64, and send that. You won't ever lose any data that way.
Code: Select all
dbl p53 print: 0.33333333333333330372738600999582558870315551757812500
dbl p17 print: 0.33333333333333330
(spare digits): 0.37273860099958256
lft p17 print: 0.33333333333333331
(spare digits): 0.4829616256247390993
exact input: 0.333333333333333314829616256247390992939472198486328125