11-18-2002, 08:07 AM
I am doing a math calculation in VB which connects to Access Database. I have two command buttons. One is increase price by 5%, and another is decrease price by 5%. I want it go back to exctly the same number when I click increase and then click decrease. Like increase $18 BY 5% is &18.9, but decrease $18.9 by 5% won't go back to $18. It became$17.955. So anyone know how to solve this problem. Thanks for any help!!
Have a nice day!!
11-18-2002, 08:34 AM
thats called rounding error, and you cant really help it
the only thing you can do is get more accuracy.
try using the Double datatype
Dim x As Double
x = 18
x = x * 1.05
x = x / 1.05
11-18-2002, 08:50 AM
That's not a rounding error.
If you increase a number by some percent and you decrease the result by the same percent you are never going to get the original number (unless that percent is 0%).
You could calculate what percentage to decrease for any certain increase but if this percentage is not constant this means you'll have to keep track of all the values.
For an increase of x percent you need to decrease (-100*x)/(100+x) percent.
Mind you, with calculations like these you are prone to have rounding errors too, so using doubles is still good advice.
11-18-2002, 08:56 AM
decrease (-100*x)/(100+x) percent
I might've been a little unclear here. The result is negative if x is positive, so it should be decrease (100*x)/(100+x).
For example, if you increase 5% then you decrease 4.7619% ( = (500/105).
Notice the precision needed (hence the doubles).
If you are planning on making the percentage constant I suggest you consider forgetting the percentage and making the changes completely constant (ie: 1$ at a time).
11-18-2002, 09:35 AM
my bad.. technically its not a rounding error, its a precision error, and its because a binary format with a fixed amount of bits cant hold the exact value of the number your calculating. (i'm not sure if that was clear) In many cases its impossible to use a binary number to hold your true value. this is why i suggested using more bits (the Double type) which uses 64 bits of floating point precision. In many cases useing enough precision makes the precision error negligable. and if you round useing less precision than your calculation, you wouldnt even know there were precision errors.
11-18-2002, 09:59 AM
It is neither a rounding error or a precision error. As Shmoove said, this is simply maths. Lets take an easier scenario - one that does not use decimal places at all.
Lets start with 100 and add 20%. 100+20% = 120. Now lets deduct 20% from our new figure. 120-20% = 96. We do not get back to our original value of 100 and we have not used decimal places so no rounding errors have occurred.
In certain circumstrances (again as Shmoove said) there will be minor rounding errors but I don't think that was the point of the question as these will be too small to make any difference (especially for prices which are only displayed to 2 decimal places).
11-18-2002, 11:31 AM
oops. talk about overcomplicateing the issue
11-18-2002, 01:46 PM
It is really a little overcomplicate for me, I mean the explanation. Although I don't know what is the problem with the math calculation, both ways work well. I tried divide 1.05 and time 4.7619%, and I got exactly the same number. By the way, I am a little curious about the formula, (-x*100)/(x+100). Where is it from?? Never seen that before.
Thanks a lot!!
11-18-2002, 10:31 PM
Increase by OldPrice by x%:
OldPrice * (1+x/100) = OldPrice * ((100+x)/100) = NewPrice
NewPrice has to be decreased by y% (y is unknown):
NewPrice * ((100 + y)/100) = OldPrice
=> OldPrice * (100/(100+y)) = NewPrice
((100+x)/100) = (100/(100+y))
=> y = (-x*100)/(x+100). (simple algebra, I skipped a few calculations)
Again, not a rounding error or precision error but simple (not overcomplicated either I think) math.
11-19-2002, 07:08 PM
It is clear that you put this way. You are right. Now it is not complicate at all. Thank you!!