#536 closed defect (fixed)
sorting range with NaNs does not behave as desired
| Reported by: | Peter | Owned by: | Jari Häkkinen |
|---|---|---|---|
| Priority: | major | Milestone: | yat 0.6 |
| Component: | utility | Version: | trunk |
| Keywords: | Cc: |
Description
spin-off from ticket:535
This ticket is for the 0.6 implementation of the bug reported in ticket:535.
As mentioned there, the solution is a functor that works like less but treats NaN as infinity. What to call the functor? Something with less?
Change History (9)
comment:1 Changed 14 years ago by
comment:4 Changed 14 years ago by
This problem also occurs in statistics::mad(3). Should we change DataWeight::operator< to use behave as less_nan<DataWeight>? If yes, we can remove less_nan<DataWeight> as it'd be redundant with less<DataWeight>.
comment:5 Changed 14 years ago by
(In [2003]) refs #536. changed DataWeight? comparison operators to be based on less_nan. Corrected template arguments in binary_function for less_nan
comment:8 Changed 14 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
(In [2006]) fixes #536. This is the last fix for #536. I don't see how to avoid the copying involved in the 0.5-stable branch fix (ticket:535), but I change so we copy to a vector<double> rather than vector<DataWeight?>. This is because sort_index is faster for std::vector<double>::iterator and StrideIterator?<double*> (the latter for Vector and Matrix iterators). These are actually the special cases that are implemented and in the generic case the range is copied to a vector<double>. So by using a vector<double> directly, we can avoid a copying.
Let's wait with this until 0.5.3 is merged into trunk.