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.
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.
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.
- 3 yrs agoLast active