whoa..rounding error uncovered
Also, "round(X,N)" gives an error - almost like it couldn't have a 2nd parameter
Great problem, not too hard but required a bit of thinking
It took me a long time (before reading the comments !!!) to figure out that for instance the result for rem(135.01,100) is not 35.01 but is 35.009999999999991.
Can anyone help me with why the issue is there and how to solve it (not by adding 1e-3)!?
good job! i enjoyed solving this code
I cannot understand this problem. what means?
Why function roundn is undefined?
function b = makingChange(a)
cu=[10000,5000,2000,1000,500,200,100,50,25,10,5,1];
b=[];
m=a*100;
for i=1:11
b(i)=floor(m/cu(i));
m=m-b(i)*cu(i);
end
b(12)=m;
end
hmmm, for the problem to pass, you need to ad 0.001 to a
Because of the floating point arithmetic, the last elsement of vector b may be different from the right answer(usually 1 smaller than it). So I add 1e-4 at last to mend it.
I get the right answer for this using this code....
---
function b = makingChange(a)
change = [100 50 20 10 5 2 1 0.5 0.25 0.1 0.05 0.01];
for i = 1:(length(change)-1)
b(i) = floor(a/change(i));
a = a - b(i)*change(i);
end
b(12) = a/change(12);
end
---
But it tells me I'm getting them all wrong. Not sure why.
Joe, I think you have a floating point rounding error. I had this same issue and its frustrating. If you look at the value for b(12) and what it outputs, it outputs 0.99999. While we know that's correct the computer doesn't. If you just add something at the end of the loop or on the line of b(12)=round(a/change(12), 2) this will round it to the nearest whole number and should get you the answer you're looking for.
The real challenge here is an issue with numerical precesion when eg using round or floor. I do not think that this was intented. The "fix" here was taken from other comments to this solution (ie add 1e-6 to input a)
I had to add the 'round' function in because for some reason both my Matlab and this are getting 135.01-100=35.0099999999. Not sure why.
1e-3 is required since there is a MATLAB bug which makes the last "a" slightly (1e-15) less than 0.01
Not a MATLAB bug, an inherent problem with representing decimals on a binary system.
I struggled with floating point issues, so this was the best solution I could come up with.
Hi everyone
I could use a bit of help on this solution, as i am just a freshman. By reading it now line 4 mind sound strange, but without it, it didn't work. I always had one penny less than expected. I thought, that this could be a numerical problem using mod() and fix() in the way, that the mod function decreases the value a litte bit and than fix doesn't work right. I am not quiet sure and could need some help by an experienced matlab user. Thanks in advance and a nice day :)
Lukas
In test case 2, 135.01 is represented internally as 135.009999999999991, so the fractional part is slightly less than 0.01, which leads to the problem. You could try rounding the input (and the change vector) to an integer number of pennies so all the calculations would use integers.
for doesn't have to be as dull as i=1:N
smart!
Having numerical precision problems...hence the sqrt(eps).
For me, it is difficult to make good code with the rouding error at the end.
Good problem.
I got rid of the rounding error by adding the 1e-6 ...
You can also multiply the original amount and the denominations by 100. Cheers.
667 Solvers
767 Solvers
Number of digits in an integer
340 Solvers
313 Solvers
Is this is a Tic Tac Toe X Win?
444 Solvers
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!