Why is the result of division stored as an integer?

Aaron_Blau
Participant III

2X_5_58df90095f5ce30f9b6b0ddaf8dd127aaf52ea46.png

Can anyone provide a workaround to this issue?
The expected result is 1 but the server is converting .33333 to 0 so the result is 0

1 12 1,252
12 REPLIES 12

Harry2
Participant V

Hi Aaron, what is the column type that you are using? If youโ€™re using a Number column, you can try changing it to a Decimal column.

Hi Harry, that doesnโ€™t change anything, the server doesnโ€™t seem to care about data type it always calculates integer for date from what I can tell from my testing.

After doing some research you confirmed this issue was being worked on over a year ago:

Please see if we can move this up on the todo list.

I recently ran into this same issue. It seems that the calculation does work correctly, It just doesnโ€™t show correctly in the test expression result. See my screenshot. The columns to the right show the actual result that gets logged in my data, and the correct decimal precision. It made me crazy troubleshooting, until I found out it was actually working in the data.

Try (Month(TODAY())/4.0)

Steve
Participant V

All of the explicit values in your expression are Numbers, so AppSheet is converting all intermediate values to Number as well. The result of (MONTH([Created Date)/3) is converted to Number, so CEILING() only ever sees 0 to begin with.

The fix, as @Steven_Aung suggested, is to introduce a Decimal into the expression to force the type conversion.

Thanks for the reply, this does fix the issue, however I donโ€™t feel this kind of knowledge should be necessary for a product sold as โ€œlow/no code.โ€ Further, how would I specify the data type if there is only variables in the formula both of which are stored as integers? Do I have to store one as a decimal just to get the division to return the correct result?

Is there an example of a situation where one would want the result of division to be an integer value?

The DECIMAL(), NUMBER(), and TEXT() functions can be used to force a type. Or, as per @Steven_Aungโ€™s suggestion, introduce an explicit value of the desired type: [number] * 1.0.

How many (whole) weeks in some number of days? [days] / 7

Really, how many whole anything in a collection of smaller components.

Thanks Steve. I really appreciate the help and now I know, but focusing on the concept of the product being a no/low-code environment, I still am left feeling the counter-intuitive coding should be required for the edge cases not the other way around. Needing to specify datatype to get the same result I would from using a standard calculator operation should not be required.

We agree that users shouldnโ€™t need to think about the data types of things like numerical literals in expressions. The intermediate calculation steps should retain full precision, and rounding or truncating to account for DecimalDigits or Number types should only apply to the end result. There is currently inconsistency between how these kinds of calculations are handled within the app vs on the server, and itโ€™s something we are discussing internally how to correct.

Hi Adam. Is there any update on getting this fixed? I just went through a frustrating hour of troubleshooting a formula until I found this thread. I had the same issue as Aaron. I strongly agree we should not have to force a decimal into the equation to end up with a decimal after a division calculation of two integers.

Hi Adam,
do you have any update on this. I am currently debugging this issue and totally agree that we shouldnt have to force truncation until only during displaying on the screen. I have a rounding error which gets multiplied and resulted in big error for final number.

Highly appreciate any input on this matter.

Top Labels in this Space