Clarify whether the application should allow users to paste numbers in scientific notation when using Standard mode or not

[rudyhuyn]

Describe the bug

It is not clear if the calculator should allow users to paste expressions with scientific notations (E notation, for example 12e+10) when the calculator is in Standard mode.

Some unit tests and methods show that we should support it: https://github.com/microsoft/calculator/blob/41e2e975918c6838947e29a046778bd4d57feeee/src/CalculatorUnitTests/CopyPasteManagerTest.cpp#L133

https://github.com/microsoft/calculator/blob/41e2e975918c6838947e29a046778bd4d57feeee/src/CalcViewModel/Common/CopyPasteManager.cpp#L197

while other methods like CopyPasteManager::ExpressionRegExMatch don't accept them when the calculator is in Standard mode, making it impossible to paste a number in scientific notation.

Why we should allow it

• the standard mode can display number with this notation, for example if they calculate 999999999999*999999999999, so we should probably allow users to copy the result and paste it later.

Why we should not allow it

• This mode doesn't have a exp button, meaning the only way to enter a number in scientific mode will be via copy/paste (and via the history).

Steps To Reproduce

• launch the Calculator
• paste 12e+10
• the calculator will display 'INVALID INPUT'

Expected behavior

Currently unknown

Device and Application Information**

• OS Build: 10.0.18363.0
• Architecture: X64
• Application Version: 10.1907.24.0
• Region: en-US
• Dev Version Installed: True

Requested Assignment

If possible, I would like to fix this.

Bonus

If we allow users to do it, we should also decide if we want to allow them to copy these type of numbers with unit converters.

[MicrosoftIssueBot]

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

[grochocki]

Despite not having an exp button, I don't think we should be blocking folks unnecessarily from pasting in a valid number, so I think we should support pasting these values in both standard mode and in most converters.

Currency converter is an odd one, though, since that is not a domain where scientific notation is typically used. Are there other converters where scientific notation might not be appropriate?

[rudyhuyn]

I agree, we should not block users. I will fix ExpressionRegExMatch to allow these numbers asap.

For converters, I agree, I think we should allow it. I would probably never use scientific notation with the currency converter, but if someone wants to use this notation (💰), it's probably better to allow it and not treat this converter differently.

[rudyhuyn]

I ran some tests to assess the workload necessary to support:

• scientific notations in Standard mode
• scientific notations in Unit/Currency converters

Standard mode: StandardCalculatorViewModel + CalculatorManager already support this type of numbers, we simply need to modify some regular expressions in CopyPasteManager::ExpressionRegExMatch to support these numbers.

Unit Converter UnitConverterViewModel and UnitConverter don't support scientific notations. If we want to do it we need:

• Add a new command UnitConversionManager::Command::Exp
• modify UnitConverter::SendCommand to support exponent.
• because the "paste" function creates a sequence of commands, we need to modify many UnitConverter's functions to ignore errors at the moment UnitConverterViewModel sends the command Exp (when users paste 12e21 for example, for a few nano seconds (because commands are sent 1 by 1 (probably something we need to change too)) the number will incorrect (12e) and crashing the application. We need to add some logic to ignore this temporary state.
• we need to modify UnitConverter to correctly support backspace with scientific notation.
  • 44e+11 -> 44e+1 -> 44e+0 -> 44, the current implementation is very basic and doesn't support this scenario.

@grochocki if you are ok with that, I would recommend to fix the issue for the standard mode and create another task for converters if we really want to do it.

[grochocki]

Let's fix the issue for standard mode, but leave converters for now. I have not seen any feedback about scientific notation support in converters, so we can revisit later, if necessary.