Re: REQUEST - bash floating point math support

[Koichi Murase]

2024年6月15日(土) 17:24 Léa Gris <lea.gris@noiraude.net>:
> Indeed printf only knows the string value. But Bash know the variable
> has a numeric flag when doing the value expansion, so it expands it
> using the current LC_NUMERIC locale in this specific case.

Ah, OK. I misunderstood your suggestion somehow differently (such that
the expansion result would still use the period as a radix character,
but the `print' builtin would automatically convert the format to the
one with the locale-dependent radix character before it starts to
interpret the arguments).

> # Numeric format use comma as radix separator
> LC_NUMERIC=fr_FR.UTF8
>
> # Numeric variable uses the C locale format internally
> declare -i floatVar=3.1415
>
> # Printf does not have to know about the variable type
> # as it is expanded in the current LC_NUMERIC format
> printf '%.2f\n' "$floatVar"
> # Prints 3,14

In this case, what is actually stored in the variable floatVar? `3.14'
or `3,14' (probably the former if I do not misunderstand)? In other
words, at which point does the conversion happens, in the assignment
phase or the parameter expansion phase? If the conversion happens in
the assignment phase, `floatVar' would not be able to use in
arithmetic expressions, which seems unreasonable. If the conversion
happens in the parameter expansion phase, it is different from the
traditional behavior of parameter expansions.

> # Same when it is expanded to assign another variable
> # stringVar=3,1415
> # Since the string expansion of numeric variable uses the
> # LC_NUMERIC format
> stringVar=$floatVar
>
> # Same rule applies when expanding a numerical context to a string:
> echo "$((2 * 3.14))"
> # Prints the string 6,28 because LC_NUMERIC=fr_FR.UTF8
>
> # Do not use string expansion to assign numeric value or it will fail
> # with different locale. Use a numeric context to assign.
> # Do:
> (( arc = 2 * floatVar ))
> # Don't:
> # arc=$((2 * floatVar ))

So this means that the arithmetic expansions $(()) would produce a
format incompatible with the arithmetic expression. This seems
inconsistent to me, but it might be a valid option if there is no
other option.

----

I still feel it would be best if POSIX could be updated to allow the
implementations to extend the interpretation when the conversion by
strtod(3) fails. The current restriction is not an explicit one but
something deduced from the four statements of the POSIX:

1) the floating-point conversion (%f, etc) of the printf utility is
performed by strtod(3),
2) strtod(3) uses LC_NUMERIC to determine the radix character,
3) strtod(3) "fails" by setting endptr = nptr when the string does not
have an expected form,
4) the printf utility needs to print a diagnostic message and fail
when the argument is not converted to a value appropriate to the
conversion specification (%f, etc.).

I doubt that the current restriction on the printf utility not
allowing C floating-point literals is intentional. Is there a reason
that we should not interpret C floating-point literals (except the
passive reason that a non-trivial combination of POSIX statements does
not allow it)? I feel it is better to allow the printf implementations
to extend the conversion rather than trying to invent strange and
inconsistent behaviors among the arithmetic expressions, the
arithmetic expansions, and the parameter expansions just to work
around the problem.

--
Koichi