Inconsistent float to string vs. string to float casting

On Wed, Dec 26, 2018 at 4:48 PM Christoph M. Becker cmbecker69@gmx.de
wrote:

Hi!

Regarding the decimal separator (aka. decimal point), the behavior of
casting float to string is inconsistent with casting string to float.
While the former regards the current locale, the latter always expects a
decimal point regardless of the locale. This breaks round-trips for
locales which use something else than a dot as decimal separator (e.g.
German, which uses a comma), for instance:

$float = 1/3;              // float(0,33333333333333)
$string = (string) $float; // string(16) "0,33333333333333"
$float = (float) $string;  // float(0)

As for me, the question is not if, but rather when and how this
inconsistency should be resolved. Regarding the when, it seems to me
we have to wait for the next major version, i.e. PHP 8. Regarding the
how I tend to prefer the non-locale aware behavior, i.e. float to
string conversion should always produce a decimal point. Users still
can explicitly use number_format() or NumberFormatter if they wish.

Thoughts?

Yes, please. Locale-sensitive library functions are bad enough, but core
language behavior should never be locale-sensitive.

I'm definitely in favor of making float to string casts locale-independent
in PHP 8.

Nikita

cmbecker69@gmx.de ("Christoph M. Becker") wrote:

Hi!

Regarding the decimal separator (aka. decimal point), the behavior of
casting float to string is inconsistent with casting string to float.
[...]

I'm shocked... Lot of code here assumes (float) does the exact reverse of
(string); forunately most servers are configures with the default locale
"C", but I'm still concerned for libraries portability.

Did you filed a bug for that?

Anyway, here is some test code I wrote:

<?php // test-float-cast.php

/**

• Performs string to float and float to string tests vs. locale.

• @param string $loc LC_NUMERIC locale to set for the test.
  */
  function test($loc)
  {
  if( setlocale(LC_NUMERIC, $loc) === FALSE )
  throw new RuntimeException("setlocale() failed");

  // Cast float to string test:
  $exp = "0.5";
  $got = (string) 0.5;
  if( $got !== $exp )
  echo "FAILED with LC_NUMERIC=$loc, (string) 0.5: got $got, exp $exp\n";

  // Cast string to float test:
  $exp = 0.5;
  $got = (float) "0.5";
  if( $got !== $exp )
  echo "FAILED with LC_NUMERIC=$loc, (float) "0.5": got $got, exp $exp\n";

  // printf() formatting of float:
  $exp = "0.500000";
  $got = sprintf("%f", 0.5);
  if( $got !== $exp )
  echo "FAILED with LC_NUMERIC=$loc, sprintf("%f", 0.5): got $got, exp $exp\n";
  }

test("C");
test("de");

Output:
FAILED with LC_NUMERIC=de, (string) 0.5: got 0,5, exp 0.5
FAILED with LC_NUMERIC=de, sprintf("%f", 0.5): got 0,500000, exp 0.500000

The second failed test is expected, as printf, scanf and co. are intended
to be locale-aware.

But the first one? Is there any simple, efficient and safe way to convert
back a string into float?

Regards,

/|\ Umberto Salsi
/_/ www.icosaedro.it

Hi!

Regarding the decimal separator (aka. decimal point), the behavior of
casting float to string is inconsistent with casting string to float.
While the former regards the current locale, the latter always expects a
decimal point regardless of the locale. This breaks round-trips for
locales which use something else than a dot as decimal separator (e.g.
German, which uses a comma), for instance:

That may be inconvenient, but changing it now would be way worse IMHO.
Ideally, system conversions would return well-defined result (locale as
a global is a horrible idea which can only be explained by it's
genesis in simpler times where most of the software was written to be
run in one specific environment and user putting a pack of punch cards
into the reader would only need them to be processed in one locale) and
for configurable outcome you'd use functions that receive explicit
parameters.

As for me, the question is not if, but rather when and how this
inconsistency should be resolved. Regarding the when, it seems to me

If you mean that loading "0.3" from string would suddenly stop working
in Germany, then never. If you mean that (string)0.3 would return "0.3"
and not "0,3" in Germany, then again I'd say probably never, though very
slightly less confidently. Those people who didn't want it already have
code to deal with it, and those that wanted it would have their unit
tests crash and burn and their data pipelines blow up.

I think it's a very bad idea to change such things, which would create
hundreds of year-persons of headache to anybody daring to upgrade. I
understand it's a bad situation, but I think the right exit of it is to
tell people that want predictable roundtrip results to use specific
number conversion functions, and not exchange one mess to another,
BC-breaking and havoc-wreaking, mess. I agree that the right thing to do
would be to have (string)0.3 to always use dot and never use locale (did
I mention I think global locale is a horrible idea?) but that ship has
sailed. I don't see a use case that would be well served by breaking the
BC now.

--
Stas Malyshev
smalyshev@gmail.com

cmbecker69@gmx.de ("Christoph M. Becker") wrote:

[...] I tend to prefer the non-locale aware behavior, i.e. float to
string conversion should always produce a decimal point. Users still
can explicitly use number_format() or NumberFormatter if they wish.

We all agree that the basic features of the language should NOT be
locale-aware to make easier error reporting and logging, data file writing
and parsing, session management, and libraries portability. But I would
to restate this goal more clearly:

FLOAT TO STRING CAST CONVERSION REPLACEMENT

Given a floating-point value, retrieve its canonical PHP source-code
string representation. By "canonical" I mean something that can be
parsed by the PHP interpreter like a floating-point number, not like
an int or anything else. Then, for example, 123.0 must be rendered as
"123.0" not as "123" because it looks like an int; non-finite values
NAN and INF must also be rendered as "NAN" and "INF". The "(string)"
cast and the embedded variable in string "$f" are locale-aware, and so
are all the printf() &Co. functions, including var_dump() (this latter a
big surprise; anyone willing to send a data structure dump to end user?).

The simplest way I found to get such canonical representation is

$s = var_export($f, TRUE);

which returns exactly what I expect, does not depend on the current
locale, does not depend on exotic libraries, and it is very short and
simple. It depends only on the current serialize_precision php.ini
parameter, which should already be set right (or you are going to have
problems elsewhere).

STRING TO FLOAT CAST CONVERSION REPLACEMENT

Given a string carrying the canonical representation of a floating-point
number, retrieve the floating-point number. Syntax errors must be
detectable. The result must be "float", not int or anything else.
Unsure about how much strict the parser should be in these edge cases:

"+1.2" (redundant plus sign)
"123" (looks like int, not a float)
"0123" (looks like int octal base)

Getting all this is bit more tricky. The "(float)" cast does not work
because it does not support non-finite values NAN,INF and does not allow
to detect errors. The simplest way I found is by using the serialize()
function:

/**

• Parses the PHP canonical representation of a floating point number. This
• function parses any valid PHP source code representation of a "float",
• including NAN, INF, -INF and -0 (IEEE 754 zero negative). Not locale aware.
• @param string $s String to parse. No spaces allowed, apply trim() if needed.
• @return float Parsed floating-point number.
• @throws InvalidArgumentException Invalid syntax.
  */
  function parseFloat($s)
  {
  // Security: untrusted strings must be checked against a basic syntax before
  // being blindly submitted to unserialize():
  if( preg_match("/^[-+]?(NAN|INF|[-+.0-9eE]++)$/sD", $s) !== 1 )
  throw new InvalidArgumentException("cannot parse as a floating point number: '$s'");
  // unserialize() raises an E_NOTICE on parse error and then returns FALSE.
  $m = @unserialize("d:$s;");
  if( is_int($m) )
  return (float) $m; // always return what we promised
  if( is_float($m) )
  return $m;
  throw new InvalidArgumentException("cannot parse as a floating point number: '$s'");
  }

Here again, only core libraries involved, no dependencies from the locale,
not so short but the best I found up now. Things like NumberFormatter
require the 'intl' extension be enabled, and often it isn't.

By using these functions all the possible "float" values pass the
round-trip back and forth, including NAN, INF, -INF, -0 (zero negative,
for what it worth) at the highest accuracy possible of the IEEE 754
representation.

Regards,

/|\ Umberto Salsi
/_/ www.icosaedro.it

Regarding the decimal separator (aka. decimal point), the behavior of
casting float to string is inconsistent with casting string to float.
While the former regards the current locale, the latter always expects a
decimal point regardless of the locale. This breaks round-trips for
locales which use something else than a dot as decimal separator (e.g.
German, which uses a comma), for instance:

$float = 1/3;              // float(0,33333333333333)
$string = (string) $float; // string(16) "0,33333333333333"
$float = (float) $string;  // float(0)

Well, there's a special case, though:

$string = (1/3) . 'foo'; // string(19) "0.33333333333333foo"

This is caused by a compile-time optimization, which obviously occurs
before any locale can be set.

--
Christoph M. Becker