Timeline for Class for median filter
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 26, 2014 at 19:50 | comment | added | Flambino | @AleksandrK. Looks OK to me | |
| Oct 26, 2014 at 14:59 | comment | added | Aleksandr K. |
I've thought a lot about your snippet and modify it for my purposes, here what I've done: temp.each_cons(window_size).map do |window| keys.each do |key| window[neighbors][key] = window.map { |x| x[key] }.sort[neighbors] end window[neighbors] end could you please write your opinion?
|
|
| Oct 25, 2014 at 12:30 | vote | accept | Aleksandr K. | ||
| Oct 25, 2014 at 12:28 | comment | added | Flambino | @AleksandrK. Yes, the method should still be in a class somewhere - it should be where you need it. And you got some good advice in your last post; the parsers probably should be separate classes. Their job is to take a file, and return an array of points that follow a standard format. However, the median filtering is something that would happen after you've parsed the files, so that probably shouldn't be in the separate parser classes, but somewhere else. | |
| Oct 25, 2014 at 11:47 | comment | added | Aleksandr K. | In the previous question (link in post) I got answer that parsers should be the classes TrackParser > GPXParser, TESParser, etc. Could you please write your opinion about it? | |
| Oct 25, 2014 at 11:45 | comment | added | Aleksandr K. | Thanks so much for that great and helpful answer. I have question about 'it could be a method' - should I put this method in module or in class that using it? | |
| Oct 25, 2014 at 11:23 | history | answered | Flambino | CC BY-SA 3.0 |