I’ll give you 3.
My app is a unit calculator. Not a unit converter–there are plenty of those around. What I mean by unit calculator is that you can put “5 inch + 6 cm” and get the answer in pica (pica is a typographic font size unit) if you wish. Or add US gallon to UK pint and get a result in litre. Whatever. You don’t convert, the calculator takes care of it. You enter what you have and specify in what unit you want your result, and it handles the rest.
In keeping with the Pareto principle, there are units that someone will be using a lot more often than others (my app has almost 400 units, including 90 currencies – and m and cm are NOT two different units. both cm and m are metre. The “c” is a prefix. There are 24 metric prefix defined; so if one wanted to count cm and mm as separate units, we’d be talking thousands of units), and the ones a user considers popular are likely to change over time (if you are on a trip, you will use currency conversions, but when you start working on the deck in your backyard, you will be more heavily using linear measures).
So, in order to speed up access, the app offers a ‘favorite’ key that keeps tabs on the recently frequently used units. This implies sorting the frequency of use score. And that is where it gets tricky.
The best algorithm for sorting is heapsort. Coding this in Thunkable Classic blocks was shown in my test to take over 3 seconds to sort the unit usage and display the 20 most popular ones in order for the user to pick. Evidently, 3 seconds delay after clicking a button is very long if the intention is providing the means of avoiding going through two scrollable menus (one for the type of unit, one for the unit from the type); that saves little time, if any.
Another case was with the trigonometric functions. Sine of 30 degree is supposed to be 0.5.
I told you about those 90 currencies?