Fix wrong infinite precision for number types with prefixed units

[kbirken]

This PR extends some tests for physunits to reproduce the problem of infinite precision for types of prefixed units. It provides the fix, and updates the CHANGELOG accordingly.

This solves #1593.

[wsafonov]

In general looks good, only couple of minor points:

• naming: not sure if constant is the best way to describe the range with min == max bounds. When I see isConstant(), I think about a range that cannot be modified. Something like isSingular() or isSinglePoint() would be better imho.
• in isContant(), checking both bounds are not equal NegInf / PosInf is covered by the last condition, since NegInf != PosInf. For safety, I would rather check min.isNotEmpty && max.isNotEmpty - even if this normally wouldn't happen, that definitely should not count as a single point range.

Not related to this bug, but I just observed that 2 kbyte + 300 bit gets accepted as number, since both of them are digital information units. But from the precision perspective that doesn't make sense. Not sure what would be the right approach here - compute everything as bits or even not allowing mix of byte/bits.

[kbirken]

In general looks good, only couple of minor points:

• naming: not sure if constant is the best way to describe the range with min == max bounds. When I see isConstant(), I think about a range that cannot be modified. Something like isSingular() or isSinglePoint() would be better imho.
• in isContant(), checking both bounds are not equal NegInf / PosInf is covered by the last condition, since NegInf != PosInf. For safety, I would rather check min.isNotEmpty && max.isNotEmpty - even if this normally wouldn't happen, that definitely should not count as a single point range.

Thanks, I just pushed a commit addressing these findings.

Not related to this bug, but I just observed that 2 kbyte + 300 bit gets accepted as number, since both of them are digital information units. But from the precision perspective that doesn't make sense. Not sure what would be the right approach here - compute everything as bits or even not allowing mix of byte/bits.

Which units did you use here? There are three ones in the standard library.

Guessing from the "k" prefix that you used metric scaling, there are implicit conversion rules which just multiply the number of bytes times 8 to retrieve bits and vice versa. But it seems this doesn't work, currently a result of 2300 byte is being computed (for binary scaling, the result is 2348).

Assuming the conversion rule is valid, IMO it should give the following results

• metric scaling: 2037,5 byte or 16300 bit
• binary scaling: 2085,5 byte or 16684 bit

So the addition of mixed units of the same quantity seems to be wrong for physunits, this is likely a topic for additional tickets....

[wsafonov]

Which units did you use here? There are three ones in the standard library.

Hmm, in my case there was only one bit unit available, namely the metric one, which is the correct one since we are expecting a metric-scaled value.

Does it behave differently on your side at the same location?

[wsafonov]

Important points are all addressed, looks good now.

[kbirken]

Does it behave differently on your side at the same location?

Yes, at this location the chunk only imports UnitsOfInformationMetric, so the binary scaled units are not available. But the computation with kbyte+bit is wrong anyway.

[kbirken]

Important points are all addressed, looks good now.

Will squash and then merge.