# \[bug-12209\]Double value is messed up **URL:** \ **Category:** Ignition\ **Created:** [March 25, 2019, 10:02pm UTC](https://forum.inductiveautomation.com/t/bug-12209-double-value-is-messed-up/23587 "2019-03-25T22:02:12Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![danieltalbot](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/danieltalbot/32/11201_2.png) [@danieltalbot](https://forum.inductiveautomation.com/u/danieltalbot)\ **Post date:** [March 25, 2019, 10:02pm UTC](https://forum.inductiveautomation.com/t/bug-12209-double-value-is-messed-up/23587/1 "2019-03-25T22:02:12Z")
I put 3.14 in a Numeric Text Field using the Number Type: Double, and the Value (Double) returns 3.140000105. Why isn’t it returning exactly 3.14? I’ve even tried binding that property to round(3.14,2) and it returns the same value. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 26, 2019, 1:09am UTC](https://forum.inductiveautomation.com/t/bug-12209-double-value-is-messed-up/23587/2 "2019-03-26T01:09:26Z")
3.14 doesn’t have an exact floating point representation. As far as the appearance in the numeric text field, you’re probably looking for the ~~number~~ decimal format property. ---
**Author:** ![witman](https://avatars.discourse-cdn.com/v4/letter/w/d2c977/32.png) [@witman](https://forum.inductiveautomation.com/u/witman)\ **Post date:** [March 26, 2019, 1:12am UTC](https://forum.inductiveautomation.com/t/bug-12209-double-value-is-messed-up/23587/3 "2019-03-26T01:12:20Z")
See [https://docs.python.org/3/tutorial/floatingpoint.html](https://docs.python.org/3/tutorial/floatingpoint.html). The type Double is a double precision (64-bit) floating point number (not to be confused with a “DINT” or 32-bit integer in something like an Allen-Bradley PLC). Here’s an interesting [calculator](https://www.h-schmidt.net/FloatConverter/) showing how floats are stored. ---
**Author:** ![Sanderd17](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/sanderd17/32/8735_2.png) [@Sanderd17](https://forum.inductiveautomation.com/u/Sanderd17)\ **Post date:** [March 26, 2019, 6:59am UTC](https://forum.inductiveautomation.com/t/bug-12209-double-value-is-messed-up/23587/4 "2019-03-26T06:59:24Z")
It does seem that the value reported is a 32-bit float, instead of a 64-bit float (or double precision). ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [March 26, 2019, 2:41pm UTC](https://forum.inductiveautomation.com/t/bug-12209-double-value-is-messed-up/23587/5 "2019-03-26T14:41:56Z")
Unfortunately, there is a bug here - we started using a different number formatting library that handles localization better, and in the process inadvertently ended up with some precision problems. I’ll add this forum post to that internal ticket, although it’s at a fairly low priority at the moment. ---
**Author:** ![danieltalbot](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/danieltalbot/32/11201_2.png) [@danieltalbot](https://forum.inductiveautomation.com/u/danieltalbot)\ **Post date:** [March 26, 2019, 3:13pm UTC](https://forum.inductiveautomation.com/t/bug-12209-double-value-is-messed-up/23587/6 "2019-03-26T15:13:45Z")
Thank you, and no worries. I found a workaround for now. ---
**Author:** ![uTewell](https://avatars.discourse-cdn.com/v4/letter/u/e274bd/32.png) [@uTewell](https://forum.inductiveautomation.com/u/uTewell)\ **Post date:** [April 16, 2020, 5:12pm UTC](https://forum.inductiveautomation.com/t/bug-12209-double-value-is-messed-up/23587/7 "2020-04-16T17:12:46Z")
I am having a similar / same issue. Do you mind explaining what the workaround you found is? ---
**Author:** ![Chris\_Nathan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/chris_nathan/32/45712_2.png) [@Chris\_Nathan](https://forum.inductiveautomation.com/u/Chris_Nathan)\ **Post date:** [October 26, 2023, 2:07pm UTC](https://forum.inductiveautomation.com/t/bug-12209-double-value-is-messed-up/23587/8 "2023-10-26T14:07:33Z")
I assume this is no longer a pressing issue, but I chased this one down. The issue appears to have arisen in version 7.9.5 and persisted in all subsequent versions of 7.9 (.21 was the latest tested). In 8.0 this appears to have been fixed. To clarify, a numeric input can be set to be Floating Point or Double. A floating point variable has 32-bits and a double has 64-bits. Therefore a value such as 333,333.36 _will_ convert to 333,333.375 if the numeric input is set to Float. This is expected. If the numeric input is set to Double, this conversion should not occur. In 7.9.5, numeric inputs set as Double would convert 333,333.36 --\> 333,333.375 which is incorrect. IGN-2520 is the internal ticket number for this issue. It has now been closed.