geo icon indicating copy to clipboard operation
geo copied to clipboard

Support Ord Trait for Primities when is avaliable

Open latot opened this issue 1 year ago • 3 comments

Hi all! I think wold be very useful to have the Ord trait implemented when T of Point<T> have it, f64 do not have Ord but other types have it.

My personal use case is some data must be sorted to perform for example integration while we have a vector of Points, instead of use f64 I has been using noisy_floats lib which allow use to have f64 without Inf/-Inf/NaN, so Ord can be achieved.

Thx!

latot avatar Dec 15 '24 18:12 latot

Can you share code that you're trying to get to compile, that is not possible?

frewsxcv avatar Apr 25 '25 19:04 frewsxcv

Hi! I think I pick the wrong focus on this, I have data, in different dimensions, here the issue, for one dimension, have ordered data helps a lot to look on the data in a efficient way, so Ord helps there.

This changes in 2 dims, the main question would be like, "Which trait is able to sort points of n dimensions to be able to organize thew data", an example for 2D would be keep organized the data in a mesh.

So, I think Ord just matches a particular case, but it should not be implemented for this, is not designed for geometry.

latot avatar May 13 '25 23:05 latot

I think we could do this fairly easily - it would be a lexical comparison of the points, probably in (x,y) ordering.

- #[derive(Eq, PartialEq, Clone, Copy, Hash, Default)]
+ #[derive(Eq, PartialEq, Ord, PartialOrd, Clone, Copy, Hash, Default)] 
#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
pub struct Coord<T: CoordNum = f64> {
    pub x: T,
    pub y: T,
}

(note the Ord would only apply to integer geometries).

For some people a lexicaly x,y sort would be useful, but to others, they might need (y,x), or some other metric.

Is it worthwhile to have a potentially arbitrary sort, so long as it's stable?

michaelkirk avatar May 13 '25 23:05 michaelkirk