-
2 Comments
@Brandon I can't reply to your comment on my previous solution (since it times out on the changed test suite now it's not only wrong but entirely invalid), so I'll do it here. I hope you'll allow this solution to stand now. :)
Rounding adds about 0.1 seconds here; perhaps you could avoid that by being more clever about the order of floating-point operations (FP arithmetic is non-associative), but I doubt this is much of a concern.
I'm curious, BTW, when you're working with actual data, how many such sensor readings do you have to process per second?
Also, if it's such a large amount that speeding up num2str() and friends becomes a concern, you might be better served with a language like e.g. Julia instead (but don't let Mathworks hear I said that).
Ah, now this is starting to look like the code I implemented (i.e. FAST).
As for the data I'm actually running, speed isn't an issue on a single run; the problem is that I have to GET the data before I can do anything. So every time I need to debug, I have to wait for str2num and whatever else is running on top of that. The most straightforward way to process the data takes SECONDS (Your original answer takes two seconds on my dataset, and my original solution took four, which was almost identical but replace() used cellfun), so the only options were to either keep a pre-processed copy of the data for debugging, or write something faster. Of course, having a variety of data is preferable for debugging, so I chose the faster code option.
And, of course, as soon as I wrote it, data of a different format became a possibility. I resorted to the slower code as a fallback for other data types (the decimal is shifted and larger values are possible). Again, data processing was taking too long. I thought about Matlab answers, but realized this would make for an interesting Cody problem, especially since I loathe the simple regexp solutions (or double(figure) :P), and things like "str2double(replace(x, ' ', ''));" look nice but are super slow.
I've since updated my fallback code to code that is 0.5s. With just a bit of data processing, I've gotten a str2num solution to work much faster than originally, although it no longer passes the final test case like it would have before.
But nice work. I do love some janky-looking fast code!
Suggested Problems
-
343 Solvers
-
518 Solvers
-
106 Solvers
-
351 Solvers
-
Matlab Basics - y as a function of x
507 Solvers
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!