You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
standard vs. scientific notation acc. shortest, saves space,
ties to non-scientific, human friendly, easier str-to-bin,
'E' and not 'e', as it is common use IMHO,
thanks for any help and hints
The text was updated successfully, but these errors were encountered:
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.
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:
thanks for any help and hints
The text was updated successfully, but these errors were encountered: