closes odoo/odoo#67949

X-original-commit: 42d409f180381316c97abd0c0ef5a062656e6122
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

The following rounding is incorrect:
```
>>> float_round(6.6 * 0.175, precision_digits=2)
1.15
```

Indeed, 6.6 * 0.175 = 1.155 ≈ 1.16.

In this specific case, the `epsilon` computed is not sufficient. A
precision of 53 gives:
normalized_value = 115.49999999999997
epsilon = 1.2823075934420547e-14
=> new normalized_value = 115.49999999999999

Bad luck, this is just not enough to tip the value in the right
direction.

However, a precision of 52 is sufficient:
normalized_value = 115.49999999999997
epsilon = 2.5646151868841094e-14
=> new normalized_value = 115.5

The value of 53 was chosen from the `binary64` number format precision.
In case of Python, the corresponding machine epsilon is 2^-52 [1].
Therefore, using 52 instead of 53 does make sense.

It is worth noting that the value of the machine epsilon
2^-52 = 2.2204460492503131e-16, which is still 2 orders of magnitude
below our dynamic estimation.

[1] https://en.wikipedia.org/wiki/Machine_epsilon
[2] `numpy.finfo(float).eps = 2.2204460492503131e-16`

opw-2047368

closes odoo/odoo#35521

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Currently, only 6 digits after decimal point is stored in database and for some currencies
it may require to have more digits after decimal precision to correctly convert rates,
like MXN -> USD currency. So, we allow maximum digits to be stored in database.

On the view side, wherever rate is editable(form or tree view), we show 12 digits
after decimal point and on list view, we truncate limit it to 6 digits.

Also, a bug is fixed for web where 'digits' attribute for float field on list view isn't considered.

Also, we have to remove a test case statement which only checks for 6 digits for a float number.

task: 2024668
closes: #34279

Signed-off-by: Josse Colpaert <jco@openerp.com>

Adding a new rule to verify that precision_rounding is positive.

Before this commit:
when a precision_round was 0 or smaller than 0 the float_utils
functions gave as results:
* float_is_zero(0.0, precision_rounding=0.0) -> False
* float_round(1.25, precision_rounding=0.0) -> 0.0
* float_compare(1.0, 1.0, precision_rounding=0.0) -> 1

These results where at least not correct at worst not logic.

Now, the function raises an error when the precision_rounding
is not positive

This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.

This includes:
    * calls to imap/izip/ifilter replaced by map/zip/filter
    * uses of text_type replaced by str
    * uses of unichr replaced by chr
    * calls to implements_to_string, implements_iterator removed
    * string_types and integer_types replaced by str, int respectively
    * calls to to_native replaced by calls to to_text

This is done in preparation to the removal of these deprecated helpers
in the following commit.

In 79038055 amount_to_text was refactored and improved, but there is a
drawback.

ie. if we have .29 cents with two decimals, `Twenty-Eight` was displayed
because `int(0.29 * 100) == 28` due to floating-point representation.

This commit keeps the improvements and fix this issue by using string
formatting of float as was done before.

opw-1829924
closes #24161