QUOTE(soonwai @ Apr 11 2024, 05:50 PM)
Ya wor. I haven't looked at the transactions but now I have and I see what you mean.
Looks like error on GXB part. Somehow they rounded the 3pct ie: 0.40499998461 to 0.41 (not as per their doc)
but 5pct is: 0.67499999082 to 0.67 (as per their doc)
Based on the above: 2pct =Â 5pct - 3pct = 0.67-0.41 = 0.26
weird...
Update:
If 3pct is calculated using (at least) 15 decimal points then it becomes 0.41. And 2pct becomes 0.26. Then it tallies with the GXB credit transactions that we see in the app for RM4941.

No change to 4941.01
and if we were to subject the 5% to same 15 decimals as the 3%, it would then yield 0.68, and 3% would yield 0.41, which in turn means 2% would be 0.27Looks like error on GXB part. Somehow they rounded the 3pct ie: 0.40499998461 to 0.41 (not as per their doc)
but 5pct is: 0.67499999082 to 0.67 (as per their doc)
Based on the above: 2pct =Â 5pct - 3pct = 0.67-0.41 = 0.26
weird...
Update:
If 3pct is calculated using (at least) 15 decimal points then it becomes 0.41. And 2pct becomes 0.26. Then it tallies with the GXB credit transactions that we see in the app for RM4941.

No change to 4941.01
and total get would then be 0.41 + 0.27 = 0.68
so the only explanation i can think of is, looks like somewhere along the line, gx wasnt consistent with their decimals usage?
not that we have any way of knowing/confirming as well. so these are just purely theoretical discussions to get an answer towards the discrepancies gx has shown.
No malice necessary, im down to assume it was an oversight by someone/somewhere.
but what i can definitely say is, there still is an inconsistency in GX's calculations because of it.
anyway, people have raised to CS regarding the 2% yielding 0.26 only instead of 0.27 << if you follow their materials down to a T, it is absolutely 0.27 and no way should get 0.26.
So lets see what the CS answers i guess.
This post has been edited by Optizorb: Apr 11 2024, 06:54 PM
Apr 11 2024, 06:44 PM

Quote




0.0174sec
0.53
6 queries
GZIP Disabled