String representation guarantees

[akrzemi1]

It is not clear from the docs, if the types guarantee some normalized representation of decimal numbers. The same value can be created in a number of ways:

boost::decimal::decimal64 x { 110, -1};
boost::decimal::decimal64 y { 11000, -3};

It is not clear from the docs, if they are guaranteed to have the same internal representation.
Similarly, it is unclear if the library guarantees an identical string representation of x and y (for instance, to_chars) when I choose the scientific notation.

[mborland]

It is not clear from the docs, if the types guarantee some normalized representation of decimal numbers. The same value can be created in a number of ways:

boost::decimal::decimal64 x { 110, -1};
boost::decimal::decimal64 y { 11000, -3};
It is not clear from the docs, if they are guaranteed to have the same internal representation.

The IEEE compliant types are not guaranteed to have the same internal representation since these are examples of cohorts: https://cppalliance.org/decimal/decimal.html#overview_motivation.

The fast types ignore cohorts so everything will be the same: https://cppalliance.org/decimal/decimal.html#benchmarks_basic_operations.

Similarly, it is unclear if the library guarantees an identical string representation of x and y (for instance, to_chars) when I choose the scientific notation.

These would be identical in scientific notation because the result outputs normalized values to look generally like X.YYYYY...e+ZZ

[akrzemi1]

These would be identical in scientific notation because the result outputs normalized values to look generally like X.YYYYY...e+ZZ

Thanks!
Could this last piece be put in the docs?