It seems someone messed up the test code: the defintion of x for the first test is now in the comment line and its impossible now to solve the problem (except cheating...)
I think there is something wrong with the test.
% x is an Mx2 vector, and y is a row of M-1 numbers.
% Tracers linearly interpolates y(1) points between x(1,:) and x(2,:),
% followed by y(2) points between x(2,:) and x(3,:), and so on...
% The resultant output is a two column vector with consecutive
% duplicate points are removed.
This is showing some strange behavior. If you use the second solution for y, the hard coded answer, it fails the first test case and also shows differing input values for the original x and y. However, if you use the first solution for y (taken from Alfonso's solution), then the correct input values for x and y are shown. I don't understand how the input values for the test suite do not match (you can see the values displayed in the answer.
Just noticed the issues that some people were having with this problem. I added a "%%" at the start of the test suite, which has helped in the past. Rescoring the two solutions that you have commented on fixed your problems. Your hard coded answer now works, and all three of the test cases show up in your test suite.
Hello, James. Any chance you could check the somewhat similar Cody bug I seem to encounter with Problem 753? I am puzzled as to why it only affects some Players. Thanks, DIV.
Thanks for the suggestion, James. I didn't get a response from them, but the fatal bug in the Test Suite of Problem 753 has somehow morphed into a non-fatal bug anyway. —DIV
...Or not. Anyway, I think I've figured out the way Test Suites are parsed in Cody: "%%" defines the start of a new test case, and omission of "%%" for the first lines of code means they become _shared variables_! Sorry for going off-topic (w.r.t. piecewise linear interpolation), but I couldn't see this documented anywhere. It is actually quite handy, as per the Test Suite in Problem 44655. —DIV
Too bad the test cases don't work anymore :(
I get the same input for x and y each time
x = 1 1 3 0 1 1
y = 5 3
This solution shows a little bit different approach to the problem. It leads to nice, short code.
There are some rounding issues with the test suite. assert(isequal(a,b)) where a and b are doubles can be problematic. I would suggest using assert(all(all(abs(a-b)<1e-10))) or something similar instead
I picked out the numbers in the test cases to hopefully avoid doing that. Looks like your solution (which is quite impressive, btw) runs into the issues I was hoping to avoid.
I'll change the assert condition in a bit.
Natural numbers in string form
Make roundn function
I'm going to enjoy watching you calculate, Mr Anderson
Hackathon - String version
How brilliant are you?
Tick. Tock. Tick. Tock. Tick. Tock. Tick. Tock. Tick. Tock.
Find the treasures in MATLAB Central and discover how the community can help you!
Choose a web site to get translated content where available and see local events and offers. Based on your location, we recommend that you select: .
You can also select a web site from the following list:
Select the China site (in Chinese or English) for best site performance. Other MathWorks country sites are not optimized for visits from your location.
Contact your local office