0

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

null
    • yinapps.com
    • drew
    • 4 yrs ago
    • Reported - view

    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?

    • Sean
    • 4 yrs ago
    • Reported - view

    This has been brought up...

     

    https://ninoxdb.de/en/forum/technical-help-5ab8fe445fe2b42b7dd39ee7/bug-in-math-logic-5c2c3938a92e630e863e2d58?post=5c2c7a22a92e630e863e2d5c&page=1

     

    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.

    • yinapps.com
    • drew
    • 4 yrs ago
    • Reported - view

    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. 

    • Birger_H
    • 4 yrs ago
    • Reported - view

    How so you get this displaed wrong? I tried an failed.

    Birger

    • Sean
    • 4 yrs ago
    • Reported - view

    Hi Birger, I have seen this also. I thought it would be interesting to come up with a solution for this thread...

     

    https://ninoxdb.de/en/forum/technical-help-5ab8fe445fe2b42b7dd39ee7/scientific-notation-5d9d118357058e5c8628372a?post=5d9d118357058e5c8628372b&page=0

     

    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.

    • yinapps.com
    • drew
    • 4 yrs ago
    • Reported - view

    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.

    • yinapps.com
    • drew
    • 4 yrs ago
    • Reported - view

    And here is a better view:

    • yinapps.com
    • drew
    • 4 yrs ago
    • Reported - view

    And to isolate when i first experienced this, i entered 238333.3303936 which turned into 238333.330393599987.

    • Sean
    • 4 yrs ago
    • Reported - view

    238333.3303936 does the same thing for me. I'm using the Mac app.

    • yinapps.com
    • drew
    • 4 yrs ago
    • Reported - view

    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.

    • Nick
    • 4 yrs ago
    • Reported - view

    Same here, number field.

    I enter 22940,62 and get this

    Screenshot 2019-11-06 at 20.18.19

    • Sean
    • 4 yrs ago
    • Reported - view
    • yinapps.com
    • drew
    • 4 yrs ago
    • Reported - view

    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

  • 4 yrs agoLast active
  • 13Replies
  • 3021Views