search

ulfjack / ryu

Converts floating point numbers to decimal strings
Apache License 2.0
1.19k stars 99 forks source link

question: is there a standard for 'shortest'? #208

Open newbie-02 opened 2 years ago

newbie-02 commented 2 years ago

not a 'pro' ... sorry,

there are probably different goals, styles and understandings about 'shortest'. E.g. performance and the preference of scientific notation to save the comparison against non-scientific, preference of 'standard' notation also with zeros at the end to be faster in a reconversion ( plain read, no 'E' calculations ), or lowercase 'e' instead of uppercase 'E' notation as STL represents it in comment on issue #199 .

For compatibility between different implementations, and e.g. to be able to compare the results in tests letter by letter instead of after a - possibly error-prone - reconversion into a binary figure, it would be nice to have a standard that everyone follows, or at least that they offer as an option.

After other experiences in IT I have to assume that there already are about a dozen standards and they argue about 'e' vs. 'E' or 'implementors choice' or 0.01 vs. 1E-2 or 'implementors choice' and the like, but I couldn't find one.

Is such already around, or is anyone in a position to initiate a standardization?
My suggestions would be:

  1. standard vs. scientific notation acc. shortest, saves space,
  2. ties to non-scientific, human friendly, easier str-to-bin,
  3. 'E' and not 'e', as it is common use IMHO,

thanks for any help and hints

newbie-02 commented 2 years ago

Spreadsheets need 'decimal' format for certain areas and 'scientific' for others, depending on user's request or default. I think it is better if ryu can provide this directly than if the programs have to do downstream string manipulation.
I tried and managed to adapt ryu's output to other formats by patching d2s.c and generic128.c ( I didn't need fs2 yet, but it should be possible as well ). If someone needs this, he can find the code at https://gitlab.gnome.org/GNOME/goffice/-/issues/57, there comment from 2022-05-11.
And if someone has time:
A.) to check that I didn't add any bugs,
B.) if you can optimize it further,
C.) if it's license-legally correct ( enough readmes included, all foreign rights respected, effective disclaimer ),
then he could do me and possibly others a big favor.