1. Robust Input Separator Parsing
Fixed a bug in expression parsing where decimal numbers beginning with zero (such as 0,132 or 0.132 depending on configuration) were incorrectly classified as thousands-grouped integers and stripped of their separators (parsing as 132 and leading to incorrect results like 0.025 instead of 25). The parser now correctly processes decimal separators for numbers with zero-valued integer parts. (#273)
2. Standardized Decimal Separator Parsing
Aligned expression parsing to always recognize the configured locale's decimal separator, regardless of whether inputLocale (Thousands separators for input) is enabled. Writing numbers with the forbidden thousands separator when inputLocale is disabled will now correctly trigger standard syntax errors.
3. Improved Output Decimal Separators
To prevent runtime environments (such as specific Electron packages or operating systems) from falling back to default locales due to missing ICU locale packages:
- We now explicitly define separators for
en-USandtr-TRlocales. - Added a fallback safety check during answer formatting: if standard formatter output does not match the expected decimal separator (e.g., falls back to a dot decimal when the user configured commas), it automatically falls back to manual string formatting using the correct separators.
4. Precision Settings Honor Standard Float Results
Coerced the application's precision setting to a numeric value and extended rounding to standard float numbers (previously only applied to BigNumber results). This resolves precision display issues where floating point limits caused calculations (such as 3,3 / 0,132) to format as 24,999999999999996 instead of 25 under a precision setting of 4.