Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
newbie-02 opened this issue Mar 30, 2022 · 1 comment
Open

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

newbie-02 opened this issue Mar 30, 2022 · 1 comment

Comments

@newbie-02
Copy link

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant