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

DYN-6908 string from object float precision #15226

Conversation

RobertGlobant20
Copy link
Contributor

Purpose

Calculating the double precision dynamically based in the number of decimals provided in the double value.
When using a double value with more than 15 decimals and passing the value to the StringFromObject node was truncating the output to use only 6 decimals so I did a fix in a way that the precision will be calculated dynamically.

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.
  • This PR modifies some build requirements and the readme is updated
  • This PR contains no files larger than 50 MB

Release Notes

Calculating the double precision dynamically based in the number of decimals provided in the double value.

Reviewers

@QilongTang

FYIs

@mjkkirschner @jnealb

When using the StringFromObject with an entry of a double value with more than 6 decimals places after point  was truncating to 6 to I've made a change to use 17 (double types precision is between 15 and 17).
Calculating the precision dynamically based in the number of decimals provided in the double value.
Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the ticket for this pull request: https://jira.autodesk.com/browse/DYN-6908

@RobertGlobant20
Copy link
Contributor Author

This is a GIF showing the expected behavior.
yYjUNpRHU3

@mjkkirschner
Copy link
Member

I think that modifying the standard output this node has produced for the last 10 years needs to be considered as a potential API behavior break.

I think a more backwards compatible solution like:
https://jira.autodesk.com/browse/DYN-6225 would be a better approach.

@QilongTang
Copy link
Contributor

Hi @mjkkirschner The proposal does make sense, thinking about it, I wonder if this is the case that bug becomes feature.. So I am not sure one way or the other, since this was originally panned for 3.2.0 release, if we took the other approach, how complex it would be? FYI: @Amoursol

@Amoursol
Copy link
Contributor

Hi @mjkkirschner The proposal does make sense, thinking about it, I wonder if this is the case that bug becomes feature.. So I am not sure one way or the other, since this was originally panned for 3.2.0 release, if we took the other approach, how complex it would be? FYI: @Amoursol

Agree with @mjkkirschner that this behavior change will impact legacy graphs that have been built specifically with this kind of output in mind. In other scenarios we have the Dynamo UI showcase numbers graphically that differ from what is actually happening under the hood, so we don't have consistency.

The more holistic fix is as Mike mentioned, adding a new overloaded node that enables the user to specify the precision. Given the code in this PR, it feels like a pretty simple addition? Can re-use icons, only need to recreate Extended Help and Sample that should be quick enough.

Thoughts?

Copy link

UI Smoke Tests

Test: success. 2 passed, 0 failed.
TestComplete Test Result
Workflow Run: UI Smoke Tests
Check: UI Smoke Tests - net8.0

@RobertGlobant20
Copy link
Contributor Author

There is already a proposal for fixing this bug in a different way.

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

Successfully merging this pull request may close these issues.

None yet

4 participants