spamsink | Я спросил у ясеня... (Reply)

Я спросил у ЧатаГПТ (или у ЧатГПТа?), почему в разделе конфигурации локали LC_NUMERIC можно задавать символы, которыми отделяется целая от дробной части чисел, а также символы, которыми разделяются группы разрядов, и длины этих групп, но нет возможности задать символ или строку для обозначения порядка в экспоненциальной записи (scientific notation) - он всегда латинская буква E.

Ответ получился удивительно разумный.

The inability to customize the exponent character in locale specifications, such as in the LC_NUMERIC category, seems indeed like an omission, but there are historical and practical reasons why this might be the case.

1. Historical conventions in scientific notation:

The usage of the Latin letter "E" to represent the exponent in scientific notation (such as in "1.23E3" for
1.23×10³) has become a well-established convention, particularly in programming languages and computational environments. This standard arose largely from early computing practices, where English and Latin characters were dominant in system design and language development. Consequently, this "E" notation became deeply embedded in the ecosystem of tools that process floating-point numbers.

2. Minimalist and general approach to locale specifications:

The LC_NUMERIC locale specification was likely designed with a focus on controlling numeric formatting for common, practical aspects like decimal points, grouping, and separators, which directly affect human-readable formatting in localized contexts. The exponent symbol, being a more technical and less commonly encountered feature in everyday usage (compared to, say, decimal points or thousands separators), may not have been considered a critical component for customization at the time these locale systems were first introduced.

3. Compatibility and standardization concerns:

Locale systems are designed to support a broad range of applications, but the use of scientific notation and the exponent character is often seen as something domain-specific (such as in scientific or engineering applications). Changing the exponent character across locales could introduce incompatibility issues with existing standards for data interchange, storage, and computation, where "E" notation is widely expected and relied upon by many systems. A change in this aspect of the format might break interoperability with systems that are built assuming "E" as the universal exponent marker.

4. Software conventions and expectations:

Many programming languages and libraries (e.g., C, Python, Java) and their respective parsing and formatting functions (like printf, sprintf, etc.) expect the "E" symbol for exponents in scientific notation. Extending locales to allow arbitrary exponent characters could create complications in maintaining consistency across software systems. In other words, the scope of customizing the exponent symbol may have been deemed unnecessary or low-priority compared to more impactful locale-related features, like currency symbols or date/time formatting.

5. Lack of strong demand or standardization:

Although it is possible that languages using non-Latin scripts might prefer alternative symbols (like the Cyrillic "Е" or a more culturally relevant marker), the demand for localizing exponent characters has likely been low, or at least not sufficiently significant to warrant changes to the POSIX or other widely used standards. Moreover, such customization would need to be standardized and implemented across many layers of software, which would introduce complexities that may not be justified by the relatively niche use case of scientific notation.

6. Future possibilities:

As of now, there doesn't seem to be any major push to augment LC_NUMERIC or other locale specifications to allow customization of the exponent character. However, as software continues to evolve to better support internationalization and customization, this could be an area for future enhancement. A compelling case would need to be made to standardization bodies (like POSIX or the IEEE floating-point standard committee) to consider exponent symbols a localizable part of the numeric format.

Summary:

The omission of the exponent character from locale specifications likely stems from historical conventions, the technical challenges of changing such a fundamental part of number formatting, and the relatively low demand for such a feature. While it's theoretically possible to allow customization of the exponent symbol, it would require widespread changes in both software systems and standards, which may be why this hasn't been addressed so far.