Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Possible disconnect between UI and standard math practices?
OpenR2
OS Professional Posts: 188 ✭✭✭
I stumbled across a post where an OnShape user found an issue with how numbers were presented in a dialog box.
https://forum.onshape.com/discussion/5373/inconsistency-between-volume-density-and-mass#latest
The user tried to check the mass calculation but was getting an answer that was 33% off from the answer displayed in the panel using the numbers in the panel.
The issue was dismissed to the user as a standard issue with rounding numbers. (the raw number of 0.00147.... was given in the response.)
The explanation for the fix involved changing to centimeters to get a higher resolution.
The user was told that the 3 significant figures show in volume are usually plenty to do this type of calculation.
So where to begin? Um....
First:
Volume is not shown to 3 significant figures is it? Its shown to one?
All the other numbers (the ones shown in scientific notation) are actually displayed to 4 significant figures?
Is the UI programmer confused between decimal places and significant figures?
---
Second:
I am not sure what the test condition is to not show the scientific notation but isn't the issue here that they stop using significant figures when they switch to the no exponent type display?
If I used the volume shown of 0.001 m^3 and calculate by hand I get a mass of 1.733Kg which off by 33%.
If I replace 0.001 m^3 with 1.738e+3 m^3 and do the calculation again I get the correct answer.
The surface area and he Y and Z in center of mass look suspicious as well.
Does the UI programmer have bad logic for when you could switch out of exponential notation?
---
Third:
Isn't the suggestion to switch units a little sketchy? Doesn't this explanation sound like the old argument about how switching to metric on a CNC machine makes it more accurate because of the old 3 decimal place 8 segment display?
Doesn't correctly using significant digits give the user numbers in a format that they get the correct answer without a "workaround?:
---
When I first saw this it was late and I thought the problem was with the method of rounding....but that's not what was wrong...I wanted to make sure that looking at this again after a nights sleep I am on the right track with why there are issues with this dialog panel?
https://forum.onshape.com/discussion/5373/inconsistency-between-volume-density-and-mass#latest
The user tried to check the mass calculation but was getting an answer that was 33% off from the answer displayed in the panel using the numbers in the panel.The issue was dismissed to the user as a standard issue with rounding numbers. (the raw number of 0.00147.... was given in the response.)
The explanation for the fix involved changing to centimeters to get a higher resolution.
The user was told that the 3 significant figures show in volume are usually plenty to do this type of calculation.
So where to begin? Um....
First:
Volume is not shown to 3 significant figures is it? Its shown to one?
All the other numbers (the ones shown in scientific notation) are actually displayed to 4 significant figures?
Is the UI programmer confused between decimal places and significant figures?
---
Second:
I am not sure what the test condition is to not show the scientific notation but isn't the issue here that they stop using significant figures when they switch to the no exponent type display?
If I used the volume shown of 0.001 m^3 and calculate by hand I get a mass of 1.733Kg which off by 33%.
If I replace 0.001 m^3 with 1.738e+3 m^3 and do the calculation again I get the correct answer.
The surface area and he Y and Z in center of mass look suspicious as well.
Does the UI programmer have bad logic for when you could switch out of exponential notation?
---
Third:
Isn't the suggestion to switch units a little sketchy? Doesn't this explanation sound like the old argument about how switching to metric on a CNC machine makes it more accurate because of the old 3 decimal place 8 segment display?
Doesn't correctly using significant digits give the user numbers in a format that they get the correct answer without a "workaround?:
---
When I first saw this it was late and I thought the problem was with the method of rounding....but that's not what was wrong...I wanted to make sure that looking at this again after a nights sleep I am on the right track with why there are issues with this dialog panel?
-3
Best Answer
-
Dave_Corcoran
Member Posts: 6 ✭✭
We will be changing to scientific notation in this dialog in a future release. Jason was just trying to give the user a way to see more significant digits in the interim.5
Answers
From Jason's post it was not immediately clear that the problem was being acknowledged as issue with not using scientific notation.
Also with the statement about round off and with getting the number of significant digits wrong, it was hard to tell if there was confusion about the difference between significant digits and number of decimal places.
It was also hard to tell if that was the recommended fix moving forward or just a temp workaround.
Sometime an explicit....yes it's a bug, fixed next release, here's a temp workaround...is helpful.
Another thought...
Is there not a standard class in your toolkit that makes the decision to print one way or the other for all floating point numbers? And has it not been thorougly tested to get the correct amswer?
You guys aren't letting each programmer write floating points to a dialogue by thier own devices in each field or each dialogue?
I think thats what the intent of the dialog was. The problem is in the current logic of when it's ok to flip over was probably not ideal in the context of the inertial dialog.
Great that the internal panel is being fixed. Thanks.