Implement concept of precision

[triplepoint]

Currently, the transform functions don't have any regard for significant digits and proper error calculation.

This is a complicated issue. Some conversions are defined as having infinite precision; for instance the inch is defined to be precisely 0.3048 meters, and so can be treated as being infinitely precise. In contrast, a furlong is stated on wikipedia as being approximately 201.168 meters, but that is not the exact definition of a furlong, and thus the precision is limited to 6 significant figures.

Figure out the best way to represent the error in these transformations, and make sure that the conversions respect the proper treatment of significant digits and precision.

[triplepoint]

See NIST SP 1038, section 4.4.1 on the topic of precision and rounding:
http://www.nist.gov/pml/wmd/metric/upload/SP1038.pdf

[MarkMaldaba]

I don't know if this is quite the same thing, but there is also the concept of context-specific precision. For example, if you have a person's height in feet and inches, it will generally be measured to the nearest inch (half-inch, perhaps, for children). When converting to cm you probably want a number that is a whole number of cm, not a precise calculation to many decimal places.

If it were possible to specify the precision of a measurement, (e.g. $height = new Length(6, 'feet', 'inch'); to indicate that the measurement was precise to the nearest inch, then any conversions could intelligently pick the appropriate amount of rounding to be performed.

[ste93cry]

Any news on this? I just found out that converting from one unit of measure to anotehr (in my case kg to lbs) and then casting to string the result prints a huge number. It would be really really useful to be able to specify at least the amount of digits to display. The code that I use is below:

$length = new Mass($value, 'kg');
$convertedLength = new Mass($length->toUnit('lbs'), 'lbs');

echo (string) $convertedLength;

[soyuka]

Why don't you use number_format?

[ste93cry]

I thought to use it, but unfortunately I don't see any way to extract the numeric value from the Mass class. I could for sure have missed it, but by inspecting the code the Mass class (and its parent class) does not implement any method to get it and the property is not public. The only way to get it is by casting to a string, which in turns prints not only the value, but also the unit. This is great, but number_format won't work with the unit appended. I could split the string, yes, but it just doesn't feel the right thing to do it.

EDIT
I'm so silly... the toUnit method returns the converted value as a number. An undocumented static method, getName is available to get the name of a given unit symbol. So, by concatenating myself the two things I'm now able to format the number as I want.

[soyuka]

This has nothing to do with the original issue, please open a new one if the problem persists.

I don't really understand why you want a new instance of Mass but toUnit returns a float. The __toString() method could show only a few decimals but it feels like it's not really this library job to format.

Something like this could work:

$a = new Mass(1, 'kg');

//this is a float
var_dump($a->toUnit('lbs'));

echo sprintf('%s %s', number_format($b->toUnit('lbs'), 2), 'lbs');

[triplepoint]

The central issue of this ticket is physical measurement precision and how it relates to the concept of significant figures. For instance, when we say "1 meter", what's the precision of that measurement? is it 1 meter precisely? 1.0 meters? 1.0000000 meters? Currently in this library, there's no way to encode the precision of the measurement when instantiating a physical quantity object.

Also, It's important to understand that because this library can also convert between units of measure, choosing the number of digits to show in a value is more complicated than simply "rounding" to one digit or the next. You might have a situation after a conversion where leaving off a digit is giving up real knowledge of the measured value, but including that digit is rolling in some false knowledge that implies precision that isn't real. In scientific measurement, ultimately, this ends up being a judgement call on the part of the user. This is bound up in the concept of error propagation and false precision.

I recognize that for most folks this is all tedious and irrelevant, but it was an identified goal at the start of the project, and so this ticket remains focused on this issue.

For the more practical discussion earlier in this ticket regarding display formatting of values, I'd invite you to open a new issue. However, my position is likely to be similar to what @soyuka suggested, as I believe that adding string-formatting features may be outside the scope of this library.

[fyrye]

Apologize for necroing but I am also looking into the precision issues, which should have been more scrutinized in the unit tests, for example in LengthTest.

https://github.com/PhpUnitsOfMeasure/php-units-of-measure/blob/v2.2.0/tests/PhysicalQuantity/LengthTest.php

$this->assertEquals(24, round($quantity->toUnit('in')));

I am unsure why in 2.2.0 round() was used in this test-case to achieve the resulting accuracy and bypass the failure, Since the function could theoretically return any decimal value between 24 and 24.5 and it would still pass the test - potentially providing users invalid values due to a typo in a stray commit that went unchecked, eg if the test was updated to use new Length(2.02, 'ft')->toUnit('in') // (24.240000000000002) instead.

Until a direction for defining precision is implemented, I suggest at the very least utilizing assertEquals with the expected floating point values included without relying on round() or assertEqualsWithDelta($n, $v, 10).

$quantity = new Length(2, 'ft');
$this->assertEquals(24.000000000000004, $quantity->toUnit('in));

$this->assertEqualsWithDelta(24, $quantity->toUnit('in'), 10);

The floating-point precision values are expected to be reproducible within the testing environment and the change would ensure the resulting values produced by this library would be sound for enterprise production environments.