Hi,
I would like to suggest adding the following constants
REGISTER_MAIN_LONG_CONSTANT("PHP_DBL_DIG", DBL_DIG, CONST_PERSISTENT |
CONST_CS);
REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_MAX", DBL_MAX, CONST_PERSISTENT |
CONST_CS);
REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_MIN", DBL_MIN, CONST_PERSISTENT |
CONST_CS);
REGISTER_MAIN_DOUBLE_CONSTANT("PHP_DBL_EPSILON", DBL_EPSILON,
CONST_PERSISTENT | CONST_CS);
The goal of this is to improve the handling of double in the user land. Here
are a couple of usages to illustrate the idea.
The comparison of double values.
$d0 = sin(M_PI/6.0);
$d1 = .5;
var_dump(
$d0, $d1,
abs($d0 - $d1),
$d0 == $d1,
abs($d0 - $d1) < PHP_DBL_EPSILON
);
float(0.5)
float(0.5)
float(5.5511151231258E-17)
bool(false)
bool(true)
The rounding behavior, max possible value representable by the string
conversion.
$d = .2345234523453245324323465;
echo $d, " ", round($d, 20), " ", round($d, PHP_DBL_DIG);
0.23452345234532 0.23452345234532 0.23452345234533
Producing INF. There's currently no explicit way to produce INF and NAN,
whereby NAN is gettable with sqrt(-1).
echo PHP_DBL_MAX*PHP_DBL_MAX, " ", -PHP_DBL_MAX*PHP_DBL_MAX;
INF -INF
In general, it is more about the possibility to handle the edge cases
properly. While such cases would cause unnecessary overhead and likely a BC
breach with a direct core implementation, they'd be fine to handle in the
scripts where it comes to it. I think, at least DBL_DIG and DBL_EPSILON
should be mapped to the constants, to provide a base for more flexibility.
The change itself is pretty outspoken, so I'm not sure it requires an RFC. I
would target at least master with this. Or 7.1, if RMs are ok.
Regards
Anatol
