fix(wallet): fixed precision loss for balance amount

[IvanBelyakoff]

What does the PR do

Fixes precision loss for big balances.

Related nimqml PR: status-im/nimqml#57 (will be added here once merged)

Affected areas

Wallet->assets balances

Closes #14402

[status-im-auto]

Jenkins Builds

Click to see older builds (4)

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
❌	ddd6b45	#1	2024-04-11 17:35:30	~4 min	macos/aarch64	📄log
✔️	ddd6b45	#1	2024-04-11 17:36:46	~6 min	tests/nim	📄log
❌	ddd6b45	#1	2024-04-11 17:40:34	~9 min	macos/x86_64	📄log
❌	ddd6b45	#1	2024-04-11 17:41:00	~10 min	linux/x86_64	📄log

❔	Commit	#️⃣	Finished (UTC)	Duration	Platform	Result
❌	d4dc062	#2	2024-04-11 17:46:15	~4 min	macos/x86_64	📄log
❌	d4dc062	#2	2024-04-11 17:47:09	~5 min	macos/aarch64	📄log
✔️	d4dc062	#2	2024-04-11 17:47:57	~6 min	tests/nim	📄log
❌	d4dc062	#2	2024-04-11 17:50:24	~8 min	linux/x86_64	📄log
❌	d4dc062	#2	2024-04-11 17:53:02	~11 min	tests/ui	📄log
❌	d4dc062	#2	2024-04-11 18:03:37	~21 min	windows/x86_64	📄log
✔️	1fd0130	#3	2024-04-12 09:57:07	~5 min	macos/aarch64	🍎dmg
✔️	1fd0130	#3	2024-04-12 09:58:47	~6 min	tests/nim	📄log
✔️	1fd0130	#3	2024-04-12 10:00:00	~8 min	macos/x86_64	🍎dmg
✔️	1fd0130	#3	2024-04-12 10:03:41	~11 min	tests/ui	📄log
✔️	1fd0130	#3	2024-04-12 10:07:59	~16 min	linux/x86_64	📦tgz
✔️	1fd0130	#3	2024-04-12 10:22:48	~30 min	windows/x86_64	💿exe

[caybro]

I wonder what's the difference? 🤔

From the docu:

[caybro]

Btw, there are CPUs that do not support float64 so I wonder whether we're not breaking something here. This is also the reason why Qt introduces the qreal (or real in QML) type which is an alias for either double or float based on what the CPU supports.

[IvanBelyakoff]

@caybro I have updated nimqml PR after discussion with @alexjba - we lost precision when converted float64 to cfloat. So initially I fixed only this case - when using float64 as property type - I mapped it to double, now as NIM uses float64 for float, we map all float to double. If you want to use 32 float as property type, you should use float32 Please have a look there status-im/nimqml#57

[micieslak]

Ideally, we should always use big integers for exchanging balances between go/nim/qml. Using floating points, no matter if 32 or 64 bits it always creates a room for distortions. Some time ago I provided some examples here: #11376. The idea is to always pass integers (big integers) and multiplier specific to given token, like 18 for ETH. Then it gives full freedom on UI side to display or use this balance for other operations like comparisons or multiplications (as in airdrop flow), with no risk of introducing distortions.

[IvanBelyakoff]

Ideally, we should always use big integers for exchanging balances between go/nim/qml. Using floating points, no matter if 32 or 64 bits it always creates a room for distortions. Some time ago I provided some examples here: #11376. The idea is to always pass integers (big integers) and multiplier specific to given token, like 18 for ETH. Then it gives full freedom on UI side to display or use this balance for other operations like comparisons or multiplications (as in airdrop flow), with no risk of introducing distortions.

Agree, thank you! Though now it should be twice better since we found what caused big distortions. Since we have a different task for CurrencyAmount as big int, I believe this is out of scope of this fix

[caybro]

I'd say LGTM

and let's handle the issue as a whole in another PR