Why does `Point` exist? about cgmath HOT 8 OPEN

Just to throw my opinion out there, too: I very much appreciate the distinction between Point and Vector in cgmath. In fact, it's one of the biggest positive things about the library IMO. The following is not meant in a threatening way, but if cgmath removes Point, I will probably switch to another library which has two types. And for me, the distinction of the two types actually prevented some real world bugs.

Instead of thinking about removing Point, maybe just try to make it easier to convert between them. One example where the distinction "annoyed" me when I had to calculate the centroid of some points (I am aware cgmath has a function for that, but it only works for a slice of points, not iterators). But yeah, even the current API is fine in my book.

from cgmath.

I think traditionally having Point be distinct from Vector is an effort to encode the distinction between affine spaces and euclidean spaces into the type system. This is usually done to prevent certain types of bugs (for example adding two points together is invalid, but subtracting them is perfectly fine).

I think the graphics community is somewhat split on this topic because each choice has its tradeoffs.

FWIW I think that nalgebra already fills the niche of dense linear algebra with strict types, so probably cgmath can play the role of a simpler API as you propose.

from cgmath.

I see. Well, I guess I'll create a PR for that.

from cgmath.

When I switched to cgmath I expected the distinction between Point and Vector to prevent some bugs in my code, but in practice I don't think I've encountered many, if any, situations where it actually prevented a bug. On the other hand, I've found many cases where I've had to convert between points and vectors, so I'm somewhat in favor of merging the two (only somewhat because the distinction does make sense mathematically).

from cgmath.

Just wanted to explicitly chime in here to say that your feedback is much welcome, and I agree that the niche for rich typing is already taken, and we can have cgmath with simpler types.

from cgmath.

@LukasKalbertodt it really comes down to what niche cgmath tries to settle in. It used to be one of the first libraries with a clear-ish goal. But after a long period of being unmaintained, and with a lot of interesting alternatives appearing, cgmath needs to play a catch-up if it wants to stay afloat. It needs to re-find itself again in the ecosystem.

If you truly care, help with reviews and code cleanup, API shaping for 0.18. Would be interesting to see some basic analysis on what other libraries expose in terms of vector-point distinction.

from cgmath.

I agree overall that cgmath should fill the "simple to use" niche, but I don't think that precludes keeping the Point struct. I've also found it useful. Maybe the solution is to make explicit point/vector conversion more ergonomic?

from cgmath.

I agree overall that cgmath should fill the "simple to use" niche, but I don't think that precludes keeping the Point struct. I've also found it useful. Maybe the solution is to make explicit point/vector conversion more ergonomic?

The conversion is kind of here. Thanks to points implementing EuclideanSpace. The main problem in my opinion would be confusing times a person may have when trying to use the Decomposed struct.

Not only that, I see no benefit in having Point, because OpenGL (and probably DirectX) don't have that. They have only VecN. So, removing Point will not only simplify the api (because it may invoke removal or merging of some traits), but will also make cgmath more familiar to the existing Graphics APIs. And, to my knowledge, cgmath exists to be used together with things like OpenGL, doesn't it? If it is so, the user should have little trouble translating data to the OpenGL implementation and there should be less difference between code in GLSL/HLSL and in Rust

from cgmath.