ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

I'm slightly confused, because what you show are exactly 'rounded values'. What you mean I believe is why there are so many decimals, and why those numbers are not 'nice' numbers (ie: 0.4999987003.. instead of 0.5).

Is this due to rounding errors between integers and floats?

Unless I'm misunderstanding you, integers have nothing to do with this. But float and double do indeed have a maximum number of significant digits they can encode. For float (or a single precision floating point number) this is about 7, for double, this is about 15 to 16 (that is total number of significant digits, not just 'after the comma').

If you want to know more about this, some references:

I'm slightly confused, because what you show are exactly 'rounded values'. What you mean I believe is why there are so many decimals, and why those numbers are not 'nice' numbers (ie: 0.4999987003.. instead of 0.5).

Is this due to rounding errors between integers and floats?

Unless I'm misunderstanding you, integers have nothing to do with this. But float and double do indeed have a maximum number of significant digits they can encode. For float (or a single precision floating point number) this is about 7, for double, this is about 15 to 16 (that is total number of significant digits, not just 'after the comma').

So for a float32 you can only realistically use the first 7 decimals.

A sensor_msgs/LaserScan uses float32 for all fields. You could ask whether it wouldn't have been better to use float64, but for all intents and purposes 5.59999990463 is equal to 5.600000.., unless you start multiplying it with large values.

If you want to know more about this, some references:

I'm slightly confused, because what you show are exactly 'rounded values'. What you mean I believe is why there are so many decimals, and why those numbers are not 'nice' numbers (ie: 0.4999987003.. instead of 0.5).

Is this due to rounding errors between integers and floats?

Unless I'm misunderstanding you, integers have nothing to do with this. But float and double do indeed have a maximum number of significant digits they can encode. For float (or a single precision floating point number) this is about 7, for double, this is about 15 to 16 (that is total number of significant digits, not just 'after the comma').

So for a float32 you can only realistically use the first 7 decimals.

A sensor_msgs/LaserScan uses float32 for all fields. You could ask whether it wouldn't have been better to use float64, but for all intents and purposes 5.59999990463 is equal to 5.600000.., unless (unless you start multiplying it with large values.values). Chances are that in most cases, the uncertainty (or noise) contributed by other (sub)systems will be worse than those 7 significant digits can encode, and this loss of precision won't matter much. That is not always the case though, and for those, the extra 7 digits that float64 provides may be important.

If you want to know more about this, some references:

I'm slightly confused, because what you show are exactly 'rounded values'. What you mean I believe is why there are so many decimals, and why those numbers are not 'nice' numbers (ie: 0.4999987003.. instead of 0.5).

Is this due to rounding errors between integers and floats?

Unless I'm misunderstanding you, integers have nothing to do with this. But float and double do indeed have a maximum number of significant digits they can encode. For float (or a single precision floating point number) this is about 7, for double, this is about 15 to 16 (that is total number of significant digits, not just 'after the comma').

So for a float32 you can only realistically use the first 7 decimals.

A sensor_msgs/LaserScan uses float32 for all fields. You could ask whether it wouldn't have been better to use float64, but for all intents and purposes 5.59999990463 is equal to 5.600000.. (unless you start multiplying it with large values). Chances are that in most cases, the uncertainty (or noise) contributed by other (sub)systems will be worse than those 7 significant digits can encode, and this loss of precision won't matter much. That is not always the case though, and for those, the extra 7 digits that float64 provides may be important.

If you want to know more about this, some references:

The first link is a simpler explanation of the original article.