Treatment of Decimals / Precision of Numbers

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)

:white_check_mark: A trigger in the app can save the value in a table field as-is (not rounded or trimmed)

:x: Viewing the record in an Interactive Table in an app the value shows rounded to 3 decimals

:white_check_mark: 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)

:x:Viewing the value in the table via admin interface shows it as rounded to 3 decimals

:white_check_mark: Viewing the value in the table via the Edit Record popup in the admin interface shows the value as-is (not rounded or trimmed)

:x: The value appears in the Completion Record as rounded to 3 decimals

:x: The value appears in the Record History Widget as rounded to 3 decimals

:x: 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

:white_check_mark: Retrieving the value via GET RECORDS API returns the value as-is (not rounded or trimmed)

1 Like

Hi Darren,

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 :slight_smile:

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 :crossed_fingers:), 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.

1 Like

Hi @pete, is there any chance the Interactive Table showing full numbers could be squeezed in sooner than the overall project? Thank you

@doneil Good news hopefully: we are looking at this now and we have already added this for table analytics. This is not available just yet, but I would expect you to see it in about a month. After that we will be looking at the embedded table widget.

Update: here is the knowledge base article that describes the new number formatting on analytics.

1 Like

This great @pete, thank you for continuing to work through this!