# Numeric Text Field Float vs Double **URL:** \ **Category:** Ignition\ **Tags:** ignition81, vision\ **Created:** [September 29, 2023, 3:22pm UTC](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double/79841 "2023-09-29T15:22:57Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [September 29, 2023, 3:22pm UTC](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double/79841/1 "2023-09-29T15:22:57Z")
Using a numeric text field component, it requires the tag to be bound to the correct prop based on the tag datatype. For float vs double, does it really matter which is used? Has anybody mixed them and run into issues? The manual says `Make sure you use the value property that corresponds to your Number Type setting.` but does not give any insight as to why or what will happen if you mix them. Along the same lines... I've always added REAL tags (Allen Bradley processor) as type Double. However, it seems when I add REAL tags from the device browser into a UDT definition it brings them in as Floats by default. I've not had any issues using the Double type everywhere. Makes me think if I always used the Double type for a numeric text input that it would be just fine and would convert as needed - no? ---
**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:** [September 29, 2023, 4:16pm UTC](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double/79841/2 "2023-09-29T16:16:06Z")
Well, a double is strictly superior (in terms of resolution) than a float, because a float is 32 bits of information and a double is 64. So it's (basically) always safe to treat a float as a double, but not the inverse, because you _potentially_ lose precision moving from double to float, either at low resolutions or with particularly large values, since float's max value is way, way less than double's max value (3.40\*1038 vs 1.79\*10308). On all (basically) hardware you'll be running _Ignition_ on, there's no speed/memory/storage advantage to using float over double, so there's not really any advantage there. It is good to keep the same binary representation if you're expecting to manipulate values in Ignition and then send them back to a PLC that's limited to float, though, to avoid confusing rounding/loss of precision errors. ---
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [September 29, 2023, 4:21pm UTC](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double/79841/3 "2023-09-29T16:21:37Z")
Like I said, I've been using almost exclusively doubles for my tag types as REALs from PLCs. This includes values that I'm reading and writing. I've not run in to any issues with it. Seems like you're saying I'd only run into issues at low resolution, or with those extremely large numbers? (what do you mean by low resolution?) ---
**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:** [September 29, 2023, 4:29pm UTC](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double/79841/4 "2023-09-29T16:29:00Z")
For instance, `0.1` cannot be exactly represented by either float or double. So if you have a double that's as close to 0.1 as possible: > **[Float Exposed](https://float.exposed/0x3fb999999999999a)** > > Floating point format explorer – binary representations of common floating point formats. And then you convert it to a float: > **[Float Exposed](https://float.exposed/0x3dcccccd)** > > Floating point format explorer – binary representations of common floating point formats. And then take that back to double: > **[Float Exposed](https://float.exposed/0x3fb99999a0000000)** > > Floating point format explorer – binary representations of common floating point formats. You've lost information. It's way down in the decimals, but it's still lost specificity. The whole point if IEEE-754 is a pragmatic tradeoff that's _mostly_ suitable for "human-scale" values, so as long as you don't particularly care about that precision, and you're not dealing with values way out at the boundaries, it's probably fine. Just something to be aware of. ---
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [September 29, 2023, 4:40pm UTC](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double/79841/5 "2023-09-29T16:40:58Z")
Thanks for the info. Since everything in the PLC is a float anyway, I'll probably start using that from now on, but it's definitely not worth it to make all those changes retroactively. Like you said before > [@paul-griffith](#): > > A double is strictly superior (in terms of resolution) than a float, because a float is 32 bits of information and a double is 64. That's why I had been basically exclusively using Double in the past. All that said, back to the original question. In most human-scale cases, binding a float to the double value of the numeric text input will not matter, and going forward I'll just use float so that point is moot. However, the question remains for binding integer values to the float value prop. Obviously, you'll lose everything beyond the decimal to truncation, but since we have the number format string prop, I can usually strictly show only whole values for integer tags anyway, and truncating the decimal if a user tries to enter it is probably the behavior I want as well. So, as always using the float value would be ok? ---
**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:** [September 29, 2023, 5:41pm UTC](https://forum.inductiveautomation.com/t/numeric-text-field-float-vs-double/79841/6 "2023-09-29T17:41:19Z")
> [@amarks](#): > > So, as always using the float value would be ok? For human scale, yes, almost certainly. Things get extra confusing in Perspective in particular, because Javascript _doesn't have an integer type_ (pedants: don't bring up BigInt) - _every_ number in JS is a double-precision floating point: [Number - JavaScript | MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number) So an "integer" on the Java side/in the tag system/on the gateway will always end up "rounding" when it's displayed in Perspective, and rounding back when it makes it into the backend. In practice this isn't really a problem, because, again, human-scale numbers, but it's also something to be aware of as a potential source of problems.