Local math/calculations - best practice?

mirko.heimburger · 2020-09-25T13:40:49.165Z

Hi there,

I am currently trying to create a form. A user should be able to enter different numbers in different input fields. Several formulas should then be used to calculate results. These results are generated without the use of a database (to get faster results).
At the moment I’m trying to do this with InstaCal instances. But the result is not optimal:

Simple mathematical formals such as “(Input_A + Input_B) / 20” does not seem to be possible because the order is not taken into account. Therefore I currently divide this formula into 2 InstaCal instances, using the result of the first instance as input in the 2nd InstaCal.
Decimal numbers (e.g. 2.4) are sometimes recognized correctly, but sometimes not at all. InstaCal often seems to ignore decimal numbers even though the input field is set to “decimal”.
If decimal numbers DO work as an input, it often happens that changes to the input are only recognized after a few seconds or not at all.

Is there a “best practice” on how to have such formulas calculated easily and reliably in Bubble?

robert · 2020-09-25T17:59:39.596Z

I use a lot of formulas in my app, and have used different approaches with differing results.

Your example in #1 would actually work in Bubble without order of operations.

For those that won’t, I usually break up the formula and have a hidden input that holds the first part of the calculation needed for the full calculation.

In general, I would advise not to use workflows to perform calculations in the backend, as there can be delays in updating the value, which creates a poor user experience, and in some cases, the workflow can fail, and the number is not calculated correctly. I have tried this approach, and was generally frustrated with the complexity, performance and reliability.

If you need a value saved to the database, it is best to use a save button if you can. With this type of workflow you can have it save the calculated value in the input field, and then pause a second, and double check that the value is saved correctly in the database, and if not save it again. Sort of a belt and suspenders approach.

robert · 2020-09-25T18:02:28.682Z

Regarding #2 & #3, I haven’t experienced this problem.

Also, I use Math.js local for more complex calculations. It works well.

mirko.heimburger · 2020-09-27T11:05:07.012Z

Thank you for this information Robert!
You’re absolutely right - my formula example in # 1 wasn’t very good as it would calculate correctly (from left to right).

It’s super strange. I copied the form into a new bubble app. It works in this new app. However, here are ‘,’ and ‘.’ reversed. In Germany we use ‘.’ as a thousand separator and ‘,’ for decimal places. However, I have no idea why it looks correct in one app and not in the other app.

This is how it looks in the app with the problem (but optically correct):

formula_calc_problem_001800×732 47.4 KB

And this is the copied version in which the calculation works, but looks wrong:

formula_calc_problem_002800×201 13.2 KB

Perhaps the localization of the number formats messed up something so that it no longer works properly.

robert · 2020-09-28T14:54:16.945Z

A couple of thoughts on this…

First, I use the period-as-decimal/ commas-as-thousands convention, so I’ve not had to deal with this. I’m sure you know you can fix this as a text element using “:formatted as…” , so that could solve your display for monthly rate.

For the input value Annual Rate, I’m not sure there is a clean fix. I couldn’t find a simple solution on the forum. There was a discussion here Question: US vs. European number formatting (please HELP) of allowing a selection of conventions that would standardize it app-wide, but I’m not sure anything ever came of it.

One workaround would be to have the annual rate as a dropdown in 0.5 or 0.25 increments displayed the way you want using a datatype with a number field and a text field. It displays the text field to the user (i.e. 1,5%) but uses the number field for the calculation (i.e. 0.015)