Based on previous discussions with support and this old topic I understand there are many projects in motion regarding the treatment of decimals throughout the data pipeline.
Is it possible to get updates on these projects?
I’m running into issues related to the precision of numbers being displayed for my Quality team to verify compliance of completed parts before they are released for shipment. Operators are keying in numbers down to 4 decimals and in most cases Tulip is displaying the value rounded to 3 decimals. In some cases, the number I’m entering could be less than 0.0005 and thus rounds to 0. I could change the units from inches to mils to reduce the impact of this rounding however the customer drawings and specs that we work off of are in inches so we look to match it.
In this topic it was suggested to us TOTEXT() to force the correct number of decimals however that work around would lead to additional work to convert back to numbers before and math or validations can occur.
I did a simple test and observed the following:
Number type variable input widget within an app can go many decimals deep (I tested to 9 decimals)
A trigger in the app can save the value in a table field as-is (not rounded or trimmed)
Viewing the record in an Interactive Table in an app the value shows rounded to 3 decimals
When the table record is loaded in a placeholder within the app the value (as shown in a VARIABLE widget) is displayed as-is (not rounded or trimmed)
Viewing the value in the table via admin interface shows it as rounded to 3 decimals
Viewing the value in the table via the Edit Record popup in the admin interface shows the value as-is (not rounded or trimmed)
The value appears in the Completion Record as rounded to 3 decimals
The value appears in the Record History Widget as rounded to 3 decimals
The value appears in an Analysis (of the completion record) as rounded to 2 decimals …. not a typo it appears to be rounded to 2 decimals
Retrieving the value via GET RECORDS API returns the value as-is (not rounded or trimmed)
Thank you for following up on this and for your detailed observations here. The product team will respond with more details shortly, I just wanted to let you know we didn’t forget about this suggestion and your ask for updates
It wouldn’t fix all of the situations above, but if ROUND() could be enhanced to add zeros instead of just rounding down that would fix things at the app level.
Hi @doneil , thanks for the detailed write up, it helps a lot when discussing these topics. I don’t have a specific update on the status of the work, but I can say that we have a high priority on addressing any questions/issues related to data precision. In your example, can you expand on how the Quality team is reviewing this data? I.e. what combination of apps and/or analytics and/or tables are they using?
Hi @pete, I have different apps built for each operation a part is processed through while at our facility.
Any info that requires Quality verification prior to shipping is stored in tables to be retrieved later:
Demensional measurements
Initial and final unbalance
Photos of part marking
Spin speed & dwell time
Uploaded PDF test records/results
As Tulip cannot complete all verifications automatically (yet ), there is a Quality Check app which has a step defined for each item that requires Quality verification:
In the below example I’m using a Variable widget to show the Pre-Spin OD which based on my configuration shows the correct precision of 4 decimals. This is how all of my processes had been setup before now and thus I didn’t notice the rounding.
Currently I have a PARTS table that has all of the details on the specifical serial numbered parts in the building. In the beginning I just kept adding columns to this table for all of the Metrics and Pictures that had to be recorded.
As I can see this getting out of hand when I keep deploying additional (and different) processes I’m switching to a method where I have a METRICS table to store any type of metric or picture along with Min/Max/Units/Precision.
In this example I’m filtering an interactive table to show the metrics that must be validated and compared to the PDFs. This is where I noticed the rounding as the full numbers are not being shown to Quality thus making it impossible to compare to the PDF.
For me the immediate need I have is the ability to show the full number (regardless of decimals) in an interactive table. I wouldn’t want all fields to default to x quantity of decimals…I would just want the stored number to show as is.
Let me know if I can provide any additional details
Hi @doneil - This is a really great summary, thanks for taking the time to write it up! Given all that, we can investigate options for improving the interactive table widget display. While data precision is a big topic, we can probably tackle this separately. I will create a ticket internally so we can investigate further and see if it’s something we can do sooner than later.
A trigger in the app can save the value in a table field as-is (not rounded or trimmed)
Viewing the record in an Interactive Table in an app the value shows rounded to 3 decimals
), there is a Quality Check app which has a step defined for each item that requires Quality verification:
