Hi JUCE team, in the past, juce::String(0.5) was turned into the string 0.50000000000000000000. You’ve then changed it to say 0.5 instead.
It took us 3 or 4 hours to adjust automatic tests and some UI code, but that’s fine.
Then with another update you changed it back to 0.50000000000000000000, which added work just again.
Now you’ve changed it to 5e-1 with JUCE 5.4.3. Uh, work again to keep up with changing implementations.
Without questioning your reasons, could you at least add such changes to the “BREAKING-CHANGES.txt” doc?
Also - resolution has suffered. Before, we got 0.10000000149011611938 when we converted a value tree float value to XML, and that has now turned into a less precise 1.000000014901161e-1.
String (0.5) produces “0.5”. The only way of getting “5e-1” is to opt into scientific format with the new arguments to the constructor.
The latest change uses scientific format when creating XML and JSON files. This allows us to avoid long strings like “0.50000000000000000000” bloating file sizes, whilst retaining full precision. “0.10000000149011611938” may look more precise than “1.000000014901161e-1”, but the last few significant digits there are useless. Converting between doubles and strings is surprisingly complicated, but as an approximate rule you can hold 7 significant digits in a 32 bit float and 16 significant digits in a 64 bit double. Anything beyond that is just noise and is ignored.
So yes, the string representation of XML and JSON is now different, but the information contained is unchanged - it will parse exactly the same way.
Thanks a ton for clarification! Also thanks for your explanation regarding precision - that makes perfect sense.
Great to hear that just XML and JSON are affected with the latest change… it only took 30min this time to adjust our tests. But indeed we appreciate your reasonable change.
Just adding it to your “BREAKING-CHANGES.txt” file would be appreciated. Thanks!
Although I was the one who complained about the wasted space with the older code, I now see lots of numbers like 5e-1 in .jucer file (xml) commits. IMHO the xml fixes took the whole scientific notation thing a bit too far. I especially find it weird to see font sizes like 1.3e1. In my opinion the scientific notation should only be used for quite small and very large values, otherwise things get hard to read and stuff like 1.3e1 is also a waste of space when it could just be 13.
I have to agree with this a bit. One of the reasons we make our edit files raw XML is so we (and users) can open them up and read them. It’s a big cognitive load to convert from scientific notation.
Is it possible to have XML as trailing-zero-trimmed standard notation? Or is that something just not allowed by the current string conversion functions?
If so, perhaps a separate step to trim trailing zeros could be used (even if we do this manually)?
At the moment, XML is turning 44100.0 into 4.41e4, which is tedious. So I think we should choose a cutoff that allows common values to be seen in their most natural readable format - 44100.0.
We’ve noticed that this recent change is perhaps too enthusiastic about stripping decimal places when converting to JSON. Any double value that is a whole number is written to JSON as an integer. In other words, if we had a value of, say 20.0, we used to get:
“foo” : 20.0
and now we get:
“foo” : 20
Then when we read the JSON data back in, it’s read as an integer and not as a double, which causes issues with our schema validator.
Would you be open to changing it so that there’s always at least one decimal place written for double values?
I’d like that as well as I’m using the number format to determine types when creating ValueTrees from xml to avoid repeated conversions later. Now for whole numbers the xml looks the same for integers and doubles.
