Panic due to integer overflow in Line::delta logic, and thus Line::slope about geo HOT 6 OPEN

We can introduce checked_delta and checked_slope methods that mirror the checked_* methods on integers in the standard library. Would that help @jayvdb?

from geo.

tbh, what I need is a way to get an accurate slope, in order to determine if three coords are a triangle. Needed for cksac/fake-rs#130 i.e. use f64 even in the T is an unsigned int.

Could I contribute a Line::abs_slope ? e.g. something like

fn abs_slope<T>(a: geo_types::Coord<T>, b: geo_types::Coord<T>) -> f64
where
    T: CoordNum,
{
    let (min_x, max_x) = if a.x > b.x { (b.x, a.x) } else { (a.x, b.x) };
    let (min_y, max_y) = if a.y > b.y { (b.y, a.y) } else { (a.y, b.y) };
    let delta_x: f64 = cast(max_x - min_x).unwrap();
    let delta_y: f64 = cast(max_y - min_y).unwrap();
    delta_y / delta_x
}

from geo.

determine if three coords are a triangle

Any three points that aren't collinear form a triangle, right? You could use https://docs.rs/robust/0.2.3/robust/fn.orient2d.html and check for a non-zero value.

Or if you prefer, you can access robust's orient2d function via geo: https://docs.rs/geo/latest/geo/algorithm/kernels/trait.Kernel.html#method.orient2d

from geo.

Seems odd the geo-types package doesnt have a way to determine of a geo_types::Triangle is a triangle. I'd rather not have another dependency just for that.

It looks like orient2d is going to be a perf hit - its algorithm does lots of additional work when the points are approaching collinear. In my case that isnt desirable as in my use-case it is desirable to discard the points when they are cheaply determined to be approximately collinear, as it is less work to pick a different random point to construct the triangle.

from geo.

Seems odd the geo-types package doesnt have a way to determine of a geo_types::Triangle is a triangle. I'd rather not have another dependency just for that.

geo-types provides types, not algorithms. The robust crate is minimal, and is provided as a separate crate because its predicates are widely useful to users outside the geo ecosystem.

its algorithm does lots of additional work when the points are approaching collinear

I would characterise it differently: Jonathan Shewchuk's incredibly widely-used algorithm provides an accurate answer to a difficult problem, trading performance for correctness when appropriate.

You say it "looks like" it's going to be a perf hit. Have you determined this empirically?

As a more general comment, I'm not inclined to accept a PR for less robust functionality already provided by a crate we maintain, though it's not solely up to me.

from geo.

geo-types provides algorithms like slope. I am asking to have an 'absolute slope' added.

Have you determined this empirically?

No I havent. Will do.

from geo.