fixed() returning wrong value for more than 16 character

Hi, Appian decimal numbers' precision cannot be more than 17 digits. You can play around with below code in an interface:

a!floatingpointfield(
label: fixed(123456789012345.1, 1,true),
value: 123456789012345.12345
)

It seems like "fixed()" function works with precision of 16. After that it approximates the value. What kind of use case do you have with having numbers that large? Do you need to do any calculations on them or only display them? Are you working with only integers or decimal numbers?

We have application where we play around with bigger values. It got accumulated over the years. Now need to push this solution.
I have fixed above one somehow. But now in same category facing new one.
1234567890123456789.123456789- Want to convert this into Text to pass in one rule. But when i try to convert through any of function it doesn't work.

Don't anyone have any idea on this ?

Your problem is Double precision floating point math. You can't possibly have more than 16 digits represented, and you're going to have massive gaps at the 16th decimal place between the numbers that can be literally represented with full precision. After nine and a half quadrillion you can't represent all integers any more, only even integers over 9.5 quadrillion.

All programming languages have this problem with Double. There's simply NO way to get more than 16 digits precision, not in any programming language at all except C # with Decimal type or Java with the BigDecimal type, which amounts to Quadruple precision floating point, or other languages that might have larger than Double type numbers. With javascript it's still impossible unless you somehow code your own better datatype.

You have to represent the number as a Text and leave it as Text. The number is too big for you to convert to any numeric type without losing precision. You have to send the Text to a plugin to do your math and then return the results from the plugin as Text, or wait for hackathon to be done because my hackathon project is actually the solution to this exact problem. I'll let you know how it goes.

How you will handle 100 Trillion number in audit reports with some 4 to 5 decimal points ?
Requirement can be any but these limitation should not stop us for any conversion , some work around should be available. Why fixed() is not working with more numbers it should work.

How is your very large number stored? Does it come from the database?

The whole problem is the use of numeric types at all. They necessarily have a fixed size and can't go above it. Text datatype, on the other hand, has an unbounded dynamic size. That's all I'll say for now.

Text(Appian)-Converting to Number - Saving to DB in Number
Same is in reverse order for download excel sheet

From where does original value come into Appian? Also, can you provide information how the field is configured in the DB.

Is the value saved correctly into the DB when you are converting? I would assume that per David's answer above, any number that has more than 16 digits of precision would be corrupted when text is converted to number.

You can post images of your process model using rich text mode of this editor. That would be very helpful.