Managing precision in number field, seeing non-exact values.
Hopefully this is easy solved, but i am evolving a crypto management system that has large sets of decimal-place variance so i cannot simply limit a number field to, say 7 digits, where some go to 10, others only need 4.
The issue: entering 238333.3303936 results in a display of 238333.330393599987, which is very much not wanted.
Thoughts? There is no number format set and no calculation done to the number.
13 replies
-
In fiddling about, i have noted almost random behaviour, although i am sure it is a bit-wise issue, but the lowest value i found with such rounding issue is 8999.19. ... can the underlying format of number storage be upgraded or an true floating point number option be offered?
-
This has been brought up...
I haven't tested storing numbers in a text field and then using the number() function to see if it affects the precision, but I think that's the only option at this point.
-
Similar and perhaps related to the same issue, but in my case, i am simply trying to STORE a number, not do any math to it. This points to a most fundamental storage issue, and one i could not explain to a potential or existing client should i take on designing systems with Ninox, which i would very much like to do.
-
How so you get this displaed wrong? I tried an failed.
Birger
-
Hi Birger, I have seen this also. I thought it would be interesting to come up with a solution for this thread...
and found that the Number field would randomly change the precision of some of the numbers I entered. I gave up on using the Number field and used a text field. That's what got me started down the merry path of Regex
. Btw, I didn't save the number that I saw this happen with. -
Hi again, to be very clear, i am doing nothing extraordinary at all. Using the mac app, have a regular table, and simply store many values with long ranges of decimals at times (think bitcoin satoshis..) I have created a small database to chase the issue, and see the image below. Simple routine: just a start and end loop value, a decimal amount added to each number and an increment +/-'d around the number to see where the erratic behaviour begins.
-
And here is a better view:
-
And to isolate when i first experienced this, i entered 238333.3303936 which turned into 238333.330393599987.
-
238333.3303936 does the same thing for me. I'm using the Mac app.
-
I have coded in many frameworks over the years and have never encountered such a thing from raw storage of a number. I have seen numerous rounding issues, but flipping to floating point, and managing the final displayed value tends to resolve the user-facing issues. But at the back end, to watch a number change simply by exiting a textbox is, in my recollection, unheard of.
-
Same here, number field.
I enter 22940,62 and get this
-
I had been working on this for another project, but it could apply here...
-
Sean, interesting approach, thank you. I have done similar in the past in very unique circumstances. In my case, i am essentially creating the equivalent to a general ledger-based crypto exchange (for all intents and purposes), so you can imagine how many number fields are involved. This approach would be entirely impractical.
I am trusting that a simple backend storage choice will be updated that will render this situation solved, with a subsequent update letting me (and us) move on.
Content aside
- 5 yrs agoLast active
- 13Replies
- 3034Views