Inconsistent precision handling

[bobvandevijver]

Consider the following example

$a = new Decimal\Decimal('15.97', 10);
$b = new Decimal\Decimal('0.05', 3);
var_dump($a->abs());

This results in

class Decimal\Decimal#3 (2) {
  public $value =>
  string(4) "16.0"
  public $precision =>
  int(10)
}

which has 16.0, instead of the expected 15.97. Somehow, the last set precision on another, at that moment unrelated, instance influences the absolute calculation of the first subject.

This also results in some interesting behavior when continuing. Consider the following:

php > var_dump($a->abs()->rem($b));
class Decimal\Decimal#4 (2) {
  public $value =>
  string(4) "0.00"
  public $precision =>
  int(10)
}

Okay, this result is to be expected when you know the result of the first abs() call returned 16.0. But, but when re-executing the exact same line:

php > var_dump($a->abs()->rem($b));
class Decimal\Decimal#3 (2) {
  public $value =>
  string(4) "0.02"
  public $precision =>
  int(10)
}

It does come with the expected value!

TL;DR; The abs() should use the precision from the supplied object, and not of the latest precision set.

I do not know if there are any other methods that use the same assumption.

[bobvandevijver]

Looking at the source, I think there are 2 solutions:

static void php_decimal_abs(php_decimal_t *res, mpd_t *op1)
{
    uint32_t status = 0;
    PHP_DECIMAL_WITH_PRECISION(php_decimal_get_precision(res), {
       mpd_qabs(PHP_DECIMAL_MPD(res), op1, php_decimal_context(), &status);
    });
}

or, use mpd_qcopy_abs instead of mpd_abs, as it doesn't take the context.

Edit: mpd_qcopy_abs is probably the way to go here, as it will then behave the same as negate, which is the only other method using the qcopy variant.

[rtheunissen]

Released as 1.3.1, also released 2.0.0-alpha