-
Notifications
You must be signed in to change notification settings - Fork 18
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
Float gets parsed as string #8
Comments
I think this must come from the underlying YAML parsers. Is it just the E notation floats, though? I think the immediate solution is to just switch to the decimal notation unfortunately. |
yeah it's just the E notation. Oh well, okay. |
Oh wait @Gastron it also happens with |
Whoa. I was also able to reproduce with I did some digging and the cause is a little convoluted. This happens because the YAML gets loaded twice: once with ruamel.yaml, then the overloads get added, and then the whole thing gets dumped back as YAML, and loaded again with "bells and whistles" with PyYAML. The floats, when they are dumped out as YAML, probably get their basic Python string representation, which turns to scientific (E) notation at 0.00001. And it is apparently a known issue that PyYAML does not parse the scientific notation right, see this issue: yaml/pyyaml#173 There's probably something we could do to the floats to dump them in the right format, or we could maybe patch the PyYAML float matching, see this nice StackOverflow answer |
This should be possible to fix in hyperpyyaml by adding a custom representer for floats. The default representer already has the needed lines of code
but this part is not executed since It can therefore also be fixed by setting the version of the ruamel_yaml object which dumps after resolving references and changing overrides in resolve_references() by adding |
Thanks @larsrgit, that's an interesting way to fix it! I wonder if this leaves out some cases where overrides get injected; they're not parsed by ruamel, and I am not sure if they get represented by this code or not. I'd imagine that patching the PyYAM-side parsing might be more robust. |
In my understanding of the hyperpyyaml code this should handle all cases where the e notation is introduced by the intermediate dumping. But you are right, patching the pyyaml parsing during loading would be better in the way that it would also work if the user does not know that pyyaml requires the e-notation to be with a dot. |
This stack overflow answer should provide a template for solving this if anyone is interested https://stackoverflow.com/a/30462009 |
Hi, example
prints
can't figure out why this is happening myself..?
The text was updated successfully, but these errors were encountered: