- Mailing Lists
- Contributors
- Re: Big number changed automatically on float fields
Archives
- By thread 1419
-
By date
- August 2019 59
- September 2019 118
- October 2019 165
- November 2019 97
- December 2019 35
- January 2020 58
- February 2020 204
- March 2020 121
- April 2020 172
- May 2020 50
- June 2020 158
- July 2020 85
- August 2020 94
- September 2020 193
- October 2020 277
- November 2020 100
- December 2020 159
- January 2021 38
- February 2021 87
- March 2021 146
- April 2021 73
- May 2021 90
- June 2021 86
- July 2021 123
- August 2021 50
- September 2021 68
- October 2021 66
- November 2021 74
- December 2021 75
- January 2022 98
- February 2022 77
- March 2022 68
- April 2022 31
- May 2022 59
- June 2022 87
- July 2022 141
- August 2022 38
- September 2022 73
- October 2022 152
- November 2022 39
- December 2022 50
- January 2023 93
- February 2023 49
- March 2023 106
- April 2023 47
- May 2023 69
- June 2023 92
- July 2023 64
- August 2023 103
- September 2023 91
- October 2023 101
- November 2023 94
- December 2023 46
- January 2024 75
- February 2024 79
- March 2024 104
- April 2024 63
- May 2024 40
- June 2024 160
- July 2024 80
- August 2024 70
- September 2024 62
- October 2024 121
- November 2024 117
- December 2024 89
- January 2025 59
- February 2025 104
- March 2025 96
- April 2025 107
- May 2025 52
- June 2025 72
- July 2025 60
- August 2025 81
- September 2025 124
- October 2025 63
- November 2025 22
Contributors
Re: Big number changed automatically on float fields
Re: Big number changed automatically on float fields
Re: Big number changed automatically on float fields
That is the right question - what problem are you trying to solve that requires 19 digit numbers.
On the actual problem, this is how floating point numbers are designed to work at a low level, on Python and computers in general.
Floating point numbers don't store all the number's digits.
For efficiency they only store a limited number of "precision" digits (the ones you can see on the scientific representation) and then the power of 10 scale - where the ("floating") decimal point is.
So for very large number, you lose precision on the rightmost digits of your number.
/Daniel
Hi Rolando
I'm interested in the business context of this problem. What kind of accounting are you doing where numbers have 19 digits?
Your questions reminds me of the first Odoo Partner Days. Somebody asked something similar in the context of fuel prices. Fabien opened an interactive python shell and did something like:
>>> import math
>>> math.pow(2, 64)
1.8446744073709552e+19
The question was dismissed and we went on to the next question.
> A value with the last Nth digits changed.
What exactly changes? Can you compare the number entered and retrieved?
Cheers, Janik
On 10/23/24 15:32, Rolando Pérez Rebollo wrote:
Hello, when trying to input very large numbers (with no decimals, 19 digits in my specific case) in credit or debit fields from journal items these numbers are changed on saving automatically with no explanation. The issue is easily reproducible in runbot Odoo 16 CE. I think a similar issue has been reported on github (https://github.com/odoo/odoo/issues/82597).
Steps to reproduce (from a user with full accounting features enabled), demo db from runbot.com 16.0 CE:
- Go to Invoicing/Accounting/Journal Entries
- Create a new one
- In Journal Items add a new line like this:
- When saved we get:
A value with the last Nth digits changed.
I was able to debug in a local environment and my observations are:
- Is not a problem from UI: emulating the creation of journal items from code gets the same results.
- Is not a problem of visualization: wrong values are persisted into database.
- At ORM level the large numbers are represented in python scientific notation, in this case 1.51337248356932e+18
- From there python float "features" begin to work and the float part of the scientific notation gets transformed due to the way python stores float numbers.
- If my tests are not wrong every single float field in Odoo is hit by this.
I think is rare nobody has notice this before. Maybe I'm ignoring some very basic fact about currency settings in Odoo that's why I'm reaching U for help or any creative idea.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- We are hiring: https://www.mint-system.ch/jobs Send application to: jobs@mint-system.ch CTO Mint System GmbH Tel: +41 44 244 7222_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
MANAGING PARTNER
>> Schedule time on my calendar.
M:
+351 919 991 307
E:
dreis@OpenSourceIntegrators.com
A:
Avenida da República 3000, Estoril Office Center, 2649-517
Cascais
by Daniel Reis - 04:26 - 23 Oct 2024
Reference
-
Big number changed automatically on float fields
Hello, when trying to input very large numbers (with no decimals, 19 digits in my specific case) in credit or debit fields from journal items these numbers are changed on saving automatically with no explanation. The issue is easily reproducible in runbot Odoo 16 CE. I think a similar issue has been reported on github (https://github.com/odoo/odoo/issues/82597).
Steps to reproduce (from a user with full accounting features enabled), demo db from runbot.com 16.0 CE:
- Go to Invoicing/Accounting/Journal Entries
- Create a new one
- In Journal Items add a new line like this:
- When saved we get:
A value with the last Nth digits changed.
I was able to debug in a local environment and my observations are:
- Is not a problem from UI: emulating the creation of journal items from code gets the same results.
- Is not a problem of visualization: wrong values are persisted into database.
- At ORM level the large numbers are represented in python scientific notation, in this case 1.51337248356932e+18
- From there python float "features" begin to work and the float part of the scientific notation gets transformed due to the way python stores float numbers.
- If
my tests are not wrong every single float field in Odoo is hit
by this.
I think is rare nobody has notice this before. Maybe I'm ignoring some very basic fact about currency settings in Odoo that's why I'm reaching U for help or any creative idea.
by Ing. Rolando Pérez Rebollo - 03:30 - 23 Oct 2024-
Re: Big number changed automatically on float fields
I reviewed this before. I think is the "why is happening?" I also make a research of github issues and even stackoverflow but it's not the same context. Almost every issue related comes from the misleading float_round in float_utils helpers but I'm not even working with a float directly I just have inserted a large number and it's just python dealing with it like a float **18, not Odoo ORM. I'll read again the documentation in search of some hint. Thanks.
On 10/23/24 10:37, Holger Brunn wrote:
https://docs.python.org/3/tutorial/floatingpoint.html -- Your partner for the hard Odoo problems https://hunki-enterprises.com
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Ing. Rolando Pérez Rebollo - 05:02 - 23 Oct 2024 -
RE: Big number changed automatically on float fields
Dear,
In Python, you have a Decimal class. Here your numbers are stored in full. So maybe this is a solution.
With kind regards,
Van Hirtum Johan
Van: Rolando Pérez Rebollo [mailto:notifications@odoo-community.org]
Verzonden: woensdag 23 oktober 2024 16:43
Aan: Contributors
Onderwerp: Re: Big number changed automatically on float fields> I'm interested in the business context of this problem. What kind of accounting are you doing where numbers have 19 digits?
It's a country with a very high inflation but the company operations really runs in USD so when converting from USD to local currency there are these kind of large numbers.
> A value with the last Nth digits changed.
For 1513372483569320000 is always the last five digits, the number stays the same till 15133724835693. My guess is due to the use of float for scientific notation the rest of the number gets messed up for some sort of global digit precision setting.
The columns in postgres that stores the values for credit and debit fields are of type numeric but without precision and scale settings. For me the responsible for the issue is python.
On 10/23/24 10:12, Janik von Rotz wrote:
Hi Rolando
I'm interested in the business context of this problem. What kind of accounting are you doing where numbers have 19 digits?
Your questions reminds me of the first Odoo Partner Days. Somebody asked something similar in the context of fuel prices. Fabien opened an interactive python shell and did something like:
>>> import math
>>> math.pow(2, 64)
1.8446744073709552e+19The question was dismissed and we went on to the next question.
> A value with the last Nth digits changed.
What exactly changes? Can you compare the number entered and retrieved?
Cheers, Janik
On 10/23/24 15:32, Rolando Pérez Rebollo wrote:
Hello, when trying to input very large numbers (with no decimals, 19 digits in my specific case) in credit or debit fields from journal items these numbers are changed on saving automatically with no explanation. The issue is easily reproducible in runbot Odoo 16 CE. I think a similar issue has been reported on github (https://github.com/odoo/odoo/issues/82597).
Steps to reproduce (from a user with full accounting features enabled), demo db from runbot.com 16.0 CE:
- Go to Invoicing/Accounting/Journal Entries
- Create a new one
- In Journal Items add a new line like this:
- When saved we get:
A value with the last Nth digits changed.
I was able to debug in a local environment and my observations are:
- Is not a problem from UI: emulating the creation of journal items from code gets the same results.
- Is not a problem of visualization: wrong values are persisted into database.
- At ORM level the large numbers are represented in python scientific notation, in this case 1.51337248356932e+18
- From there python float "features" begin to work and the float part of the scientific notation gets transformed due to the way python stores float numbers.
- If my tests are not wrong every single float field in Odoo is hit by this.
I think is rare nobody has notice this before. Maybe I'm ignoring some very basic fact about currency settings in Odoo that's why I'm reaching U for help or any creative idea.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe--
We are hiring: https://www.mint-system.ch/jobs
Send application to: jobs@mint-system.ch
CTO Mint System GmbH
Tel: +41 44 244 7222
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by johan - 04:51 - 23 Oct 2024 -
Re: Big number changed automatically on float fields
> I'm interested in the business context of this problem. What kind of accounting are you doing where numbers have 19 digits?
It's a country with a very high inflation but the company operations really runs in USD so when converting from USD to local currency there are these kind of large numbers.
> A value with the last Nth digits changed.
For 1513372483569320000 is always the last five digits, the number stays the same till 15133724835693. My guess is due to the use of float for scientific notation the rest of the number gets messed up for some sort of global digit precision setting.
The columns in postgres that stores the values for credit and debit fields are of type numeric but without precision and scale settings. For me the responsible for the issue is python.
On 10/23/24 10:12, Janik von Rotz wrote:
Hi Rolando
I'm interested in the business context of this problem. What kind of accounting are you doing where numbers have 19 digits?
Your questions reminds me of the first Odoo Partner Days. Somebody asked something similar in the context of fuel prices. Fabien opened an interactive python shell and did something like:
>>> import math
>>> math.pow(2, 64)
1.8446744073709552e+19
The question was dismissed and we went on to the next question.
> A value with the last Nth digits changed.
What exactly changes? Can you compare the number entered and retrieved?
Cheers, Janik
On 10/23/24 15:32, Rolando Pérez Rebollo wrote:
Hello, when trying to input very large numbers (with no decimals, 19 digits in my specific case) in credit or debit fields from journal items these numbers are changed on saving automatically with no explanation. The issue is easily reproducible in runbot Odoo 16 CE. I think a similar issue has been reported on github (https://github.com/odoo/odoo/issues/82597).
Steps to reproduce (from a user with full accounting features enabled), demo db from runbot.com 16.0 CE:
- Go to Invoicing/Accounting/Journal Entries
- Create a new one
- In Journal Items add a new line like this:
- When saved we get:
A value with the last Nth digits changed.
I was able to debug in a local environment and my observations are:
- Is not a problem from UI: emulating the creation of journal items from code gets the same results.
- Is not a problem of visualization: wrong values are persisted into database.
- At ORM level the large numbers are represented in python scientific notation, in this case 1.51337248356932e+18
- From there python float "features" begin to work and the float part of the scientific notation gets transformed due to the way python stores float numbers.
- If
my tests are not wrong every single float field in
Odoo is hit by this.
I think is rare nobody has notice this before. Maybe I'm ignoring some very basic fact about currency settings in Odoo that's why I'm reaching U for help or any creative idea.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- We are hiring: https://www.mint-system.ch/jobs Send application to: jobs@mint-system.ch CTO Mint System GmbH Tel: +41 44 244 7222
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Ing. Rolando Pérez Rebollo - 04:41 - 23 Oct 2024 -
Re: Big number changed automatically on float fields
https://docs.python.org/3/tutorial/floatingpoint.html -- Your partner for the hard Odoo problems https://hunki-enterprises.com
by Holger Brunn - 04:35 - 23 Oct 2024 -
Re: Big number changed automatically on float fields
That is the right question - what problem are you trying to solve that requires 19 digit numbers.
On the actual problem, this is how floating point numbers are designed to work at a low level, on Python and computers in general.
Floating point numbers don't store all the number's digits.
For efficiency they only store a limited number of "precision" digits (the ones you can see on the scientific representation) and then the power of 10 scale - where the ("floating") decimal point is.
So for very large number, you lose precision on the rightmost digits of your number.
/Daniel
On 23/10/2024 15:12, Janik von Rotz wrote:
Hi Rolando
I'm interested in the business context of this problem. What kind of accounting are you doing where numbers have 19 digits?
Your questions reminds me of the first Odoo Partner Days. Somebody asked something similar in the context of fuel prices. Fabien opened an interactive python shell and did something like:
>>> import math
>>> math.pow(2, 64)
1.8446744073709552e+19
The question was dismissed and we went on to the next question.
> A value with the last Nth digits changed.
What exactly changes? Can you compare the number entered and retrieved?
Cheers, Janik
On 10/23/24 15:32, Rolando Pérez Rebollo wrote:
Hello, when trying to input very large numbers (with no decimals, 19 digits in my specific case) in credit or debit fields from journal items these numbers are changed on saving automatically with no explanation. The issue is easily reproducible in runbot Odoo 16 CE. I think a similar issue has been reported on github (https://github.com/odoo/odoo/issues/82597).
Steps to reproduce (from a user with full accounting features enabled), demo db from runbot.com 16.0 CE:
- Go to Invoicing/Accounting/Journal Entries
- Create a new one
- In Journal Items add a new line like this:
- When saved we get:
A value with the last Nth digits changed.
I was able to debug in a local environment and my observations are:
- Is not a problem from UI: emulating the creation of journal items from code gets the same results.
- Is not a problem of visualization: wrong values are persisted into database.
- At ORM level the large numbers are represented in python scientific notation, in this case 1.51337248356932e+18
- From there python float "features" begin to work and the float part of the scientific notation gets transformed due to the way python stores float numbers.
- If
my tests are not wrong every single float field in
Odoo is hit by this.
I think is rare nobody has notice this before. Maybe I'm ignoring some very basic fact about currency settings in Odoo that's why I'm reaching U for help or any creative idea.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
-- We are hiring: https://www.mint-system.ch/jobs Send application to: jobs@mint-system.ch CTO Mint System GmbH Tel: +41 44 244 7222
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
by Daniel Reis - 04:26 - 23 Oct 2024