3 ms·

I'd love to hear you highlight a few of the unexpected challenges.

smikhanov 13y ago
For example: 1. When someone enters "1 / 3" how many decimal places you display in the result? My approach: use MAX(4, MAX(decimal_places(entered_values))). His approach: use 3 everywhere. - Bonus 1: how many decimal places you display when someone enters "sin(3.14)"? What about "sin(1 / 3)"? My approach: use as much space you have on the screen. - Bonus 2: how do decimal places propagate when you're using refs? 2. What to do when someone taps "=" on the expression where we already have a result? Chinese $2 hardware calculator approach: redo the last operation. My approach: do nothing. Tydlig's approach: insert last result as a ref. 3. What to do when someone enters huge numbers? My approach: trim them to the width of the screen, clearly displaying that, but keep the full figure when doing copy/paste or export to text. His approach: start using E-notation somewhere around 16th figure. 4. In an app like this there's a temptation to stop using cursor because calculators don't have it and you want to be backwards compatible with them. When you create a ref, how to make sure the destination of the ref is at the right position in the expression without introducing a cursor? I.e. how to make sure you're not getting "2 + 3 [ref] + 12" (you need an operator before "[ref]")? My approach: use a semi-rigid table, where operators are separated from operands. Tydlig's approach: use a little cursor, a part of the app I don't like, because your finger normally would block the cursor. I can go on and on. Math-related stuff is hard.
- rooster8 13y ago
  Cool problems I never would have anticipated! Thanks for sharing!
- ygra 13y ago
  More to the point, I guess: UX is hard ;-) The switching to scientific notation around x · 10¹⁶ hints at using IEEE 754 doubles underneath. I wonder what they are using underneath for the math functions (they make it sound like it's custom-built). I spent a while in uni porting math function implementations from C to Java for a simulations framework and noticed that they usually all have the same pattern of selecting many different ways of calculating the result based on the intervals of the operands (to more or less guarantee 15 digits of precision instead of 0–15 as would otherwise be the case).

For example: 1. When someone enters "1 / 3" how many decimal places you display in the result? My approach: use MAX(4, MAX(decimal_places(entered_values))). His approach: use 3 everywhere. - Bonus 1: how many decimal places you display when someone enters "sin(3.14)"? What about "sin(1 / 3)"? My approach: use as much space you have on the screen. - Bonus 2: how do decimal places propagate when you're using refs? 2. What to do when someone taps "=" on the expression where we already have a result? Chinese $2 hardware calculator approach: redo the last operation. My approach: do nothing. Tydlig's approach: insert last result as a ref. 3. What to do when someone enters huge numbers? My approach: trim them to the width of the screen, clearly displaying that, but keep the full figure when doing copy/paste or export to text. His approach: start using E-notation somewhere around 16th figure. 4. In an app like this there's a temptation to stop using cursor because calculators don't have it and you want to be backwards compatible with them. When you create a ref, how to make sure the destination of the ref is at the right position in the expression without introducing a cursor? I.e. how to make sure you're not getting "2 + 3 [ref] + 12" (you need an operator before "[ref]")? My approach: use a semi-rigid table, where operators are separated from operands. Tydlig's approach: use a little cursor, a part of the app I don't like, because your finger normally would block the cursor. I can go on and on. Math-related stuff is hard.

rooster8 13y ago
Cool problems I never would have anticipated! Thanks for sharing!
ygra 13y ago
More to the point, I guess: UX is hard ;-) The switching to scientific notation around x · 10¹⁶ hints at using IEEE 754 doubles underneath. I wonder what they are using underneath for the math functions (they make it sound like it's custom-built). I spent a while in uni porting math function implementations from C to Java for a simulations framework and noticed that they usually all have the same pattern of selecting many different ways of calculating the result based on the intervals of the operands (to more or less guarantee 15 digits of precision instead of 0–15 as would otherwise be the case).