601
Progress Journals & Experimental Routines / Re: ADARQ's journal
« on: April 07, 2016, 02:36:42 pm »
I have a challenge (probably impossible) for Adarqui (I would also like vag to chime in or anybody else for that matter):
Here's the deal: Someone at work asked me if something is mathematically possible:
One company records its invoices totals with numbers with 4 decimals.
Say you buy 3 items that each costs 1.0250 $. The total would be 3.0750 $ (with 4 decimal numbers).
However, this company calculates the item prices with only 2 decimals.
So they would calculate 1.02+1.02+1.02 and expect to find 3.0750 at the end. Our company has two choices (according to this retarded company) - either truncate (and end up in the 1.02x3 situation) or round (and end up in the 1.03x3 situation).
Both, as you can see, are "wrong". One gives a total of 3.06 (instead of 3.0750) and the other gives a total of 3.09 (instead of 3.0750).
This, for many products, leads to a significant different between the calculation and the actual total.
I told them it's impossible mathematically, since if we "cut" the last 2 decimals we're basically giving up that information for good, and creating an approximation. And I guess that's that and end of story.
I tried coming up with something... weird... probably idiotic, although I tried it a bit and it was more precise in some situations.
Here's the algorithm that I thought about:
I basically established a "weight" for each item - say you have 10 items. 4 of them are of type "last 2 decimals under 50", 6 are "last 2 decimals over 50".
Like this:
10.1241
10.4126
10.8744
10.5616
Again, the last 4 decimals all "under 50".
Then the other 6 (chose 6 randomly) would be this:
10.5589
10.2377
10.3497
10.1166
10.4351
10.7888
Then I calculated the sum in 4 decimals (the total, that they want in 4 decimals).
SUM4 = 104.4595
Now the sum if we're to truncate the last two decimals
SUMTRUNC = 104.40
Now the sum if we're to round the last two decimals (if under 50, keep the 2 decimal of the number unchanged, else increase by one):
SUMROUND = 104.46
Now I thought, what if I pretend all the last digits are UNDER 50 for one calculation, and all the last digits are over 50 for another, and then assign weights to them?
So that would be SUMWEIGHT = 104.40*0.4 (because only 4 elements actually have last 2 decimals under 50) + 104.50 * 0.6 (we're assuming that we round up all the numbers, but only 6 elements have last 2 decimals over 50) = 41.76 + 62.70 = 104.46 -> which ends up exactly as the rounded sum.
I did several calculations and it was different in different scenarios. There's also the possibility that my calculation was wrong, or that I'm doing something completely redundant or idiotic to begin with.
I mean, the more I look at it the more it seems like I'm doing a more complicated rounding, basically (which is probably exactly what I'm doing) - do you have any other ideas or this is simply an impossible task?
Here's the deal: Someone at work asked me if something is mathematically possible:
One company records its invoices totals with numbers with 4 decimals.
Say you buy 3 items that each costs 1.0250 $. The total would be 3.0750 $ (with 4 decimal numbers).
However, this company calculates the item prices with only 2 decimals.
So they would calculate 1.02+1.02+1.02 and expect to find 3.0750 at the end. Our company has two choices (according to this retarded company) - either truncate (and end up in the 1.02x3 situation) or round (and end up in the 1.03x3 situation).
Both, as you can see, are "wrong". One gives a total of 3.06 (instead of 3.0750) and the other gives a total of 3.09 (instead of 3.0750).
This, for many products, leads to a significant different between the calculation and the actual total.
I told them it's impossible mathematically, since if we "cut" the last 2 decimals we're basically giving up that information for good, and creating an approximation. And I guess that's that and end of story.
I tried coming up with something... weird... probably idiotic, although I tried it a bit and it was more precise in some situations.
Here's the algorithm that I thought about:
I basically established a "weight" for each item - say you have 10 items. 4 of them are of type "last 2 decimals under 50", 6 are "last 2 decimals over 50".
Like this:
10.1241
10.4126
10.8744
10.5616
Again, the last 4 decimals all "under 50".
Then the other 6 (chose 6 randomly) would be this:
10.5589
10.2377
10.3497
10.1166
10.4351
10.7888
Then I calculated the sum in 4 decimals (the total, that they want in 4 decimals).
SUM4 = 104.4595
Now the sum if we're to truncate the last two decimals
SUMTRUNC = 104.40
Now the sum if we're to round the last two decimals (if under 50, keep the 2 decimal of the number unchanged, else increase by one):
SUMROUND = 104.46
Now I thought, what if I pretend all the last digits are UNDER 50 for one calculation, and all the last digits are over 50 for another, and then assign weights to them?
So that would be SUMWEIGHT = 104.40*0.4 (because only 4 elements actually have last 2 decimals under 50) + 104.50 * 0.6 (we're assuming that we round up all the numbers, but only 6 elements have last 2 decimals over 50) = 41.76 + 62.70 = 104.46 -> which ends up exactly as the rounded sum.
I did several calculations and it was different in different scenarios. There's also the possibility that my calculation was wrong, or that I'm doing something completely redundant or idiotic to begin with.
I mean, the more I look at it the more it seems like I'm doing a more complicated rounding, basically (which is probably exactly what I'm doing) - do you have any other ideas or this is simply an impossible task?