Breaking: removed Vector2D, Point2D, LineSegment2D, und using consistently 3D variants

[JohanLarsson]

What is going on here? This breaks everyone. I like types, separate types for 2d and 3d is a feature.

[jkalias]

Hi @JohanLarsson ,

As mentioned in #200 , I think we had a big mess of duplicate and redundant code for 2D and 3D cases. My intention is that we have a solid foundation in 3D, which covers all cases, since 2D is a special case of 3D. The removed 2D types are almost 100% covered by their 3D counterparts, which are no longer suffixed 3D.

The most recent β release is 0.7.0, already tagged in this repo. However, the original maintainer (@cdrnet , maybe you?) have still not given me any access rights to publish the relevant NuGet, which is still in 0.6.0

My plan was to fix this 2D/3D inconsistency as fast as possible, before we reach a stable release. So all these changes (and the ones coming) would be part of 0.8.0, giving enough time to people to test things out and settle things down.

Please let me know what you think.

[jkalias]

I like types, separate types for 2d and 3d is a feature.

I have nothing against types per se, I am only of the opinion, that 3D geometry is the only thing we need.

[jkalias]

How should we proceed then? Should we revert all recent breaking changes up to this commit or is it ok if I move on with the refactoring/restructuring of types to eliminate 2d for the next v0.8.0?

For example, Point3D would be CartesianPosition (so we can introduce later CylindricalPosition), Vector3D would be CartesianVector and PolyLine2D/3D would simply be Curve.

[Anlo2846]

Apart from breaking lots of code for us, I don't think that this is a good change. Sure, we could set Z=0 for 2D but it would not be obvious when we're dealing with 2D or 3D geometry just looking at our code. Also, I guess that there are some operations that are not available for 3D geometry which needs to throw exceptions instead of having the compiler stop us from trying.

[jkalias]

My apologies, it seems I created more frustration than I planned to and these changes are not accepted by the community. Am I correct?

Should I then revert all recent breaking commits, as mentioned earlier? Is there any other person with admin rights and/or higher say than mine who wants to offer their point of view? @cdrnet , @Rickasaurus , @jvangael , @JohanLarsson ??

[TacetDiscipulus]

Hi,

I have not contributed to this project so who knows what my opinion counts for.

The fact of the matter is that 2D and 3D geometry are different things and deserve different types. This breaks a significant number of projects that I am involved in and I know from speaking to others it will break code for a vast number of people who rely on this library.

Here are my mathematical 2 cents. Anyone who was ever lectured a first year Linear Algebra course at a university knows that it is a virtual certainty that the difference between R^2 and R^3 will have to be explained at least a few times. Upon first exposure students have a hard time seeing that the vector (a, b) != (a, b, 0). R^2 is NOT a special case of R^3 where Z = 0 (2D is NOT a special case of 3D where Z = 0). They are fundamentally different things, for example there is no such thing as the CrossProduct in 2D, sure there is a pretend version that can be useful at times, but a rigorously defined CrossProduct simply does not exist when working in two dimensional vectors.

R^2 can be embedded in R^3 but it is absolutely not the same thing, or a special case where Z=0. They are mathematically distinct concepts.

When doing code reviews it will be far from obvious what dimension is being worked in, this will force devs to way over comment their code to ensure anyone who looks later has a clue as to what is going on.

Since the types are immutable it allows for significant floating point error to enter. The formulas for Euclidean, Manhattan, or any other metric in a 2D system simply do not include a Z component of a vector because a 2D vector has no Z component. However should floating point error or any other type of error allow a Z with a non zero value it then makes makes Length, Distance between points, etc, completely unreliable.

It is my opinion that the library and community are best served by maintaining a set of classes for 2D and a separate set of classes for 3D.

I will give credit where credit is due, adding the trig related functions to Angle.cs was much needed. It always seemed strange to have an angle unit but have to write " Math.Cos(angle.Radians)" instead of just calling angle.cos.

If the author(s) of the changes feel strongly about the issue the library does have an MIT license, they are free to and some might welcome a new library derived from this one that is based on how they see to make improvements, is that not a reasonable option?

[jkalias]

The fact of the matter is that 2D and 3D geometry are different things and deserve different types. This breaks a significant number of projects that I am involved in and I know from speaking to others it will break code for a vast number of people who rely on this library.

Thank you for taking the time to reply, this is exactly what I was hoping for. That people really using the library raise up their voices and give some feedback.

Here are my mathematical 2 cents. Anyone who was ever lectured a first year Linear Algebra course at a university knows that it is a virtual certainty that the difference between R^2 and R^3 will have to be explained at least a few times. Upon first exposure students have a hard time seeing that the vector (a, b) != (a, b, 0). R^2 is NOT a special case of R^3 where Z = 0 (2D is NOT a special case of 3D where Z = 0). They are fundamentally different things, for example there is no such thing as the CrossProduct in 2D, sure there is a pretend version that can be useful at times, but a rigorously defined CrossProduct simply does not exist when working in two dimensional vectors.

My understanding of Linear Algebra at university was exactly the opposite. One starts with general statements and theorems, which hold in any dimension. Linear Algebra is in any case its own thing, not confined to geometry problems or matrices.

R^2 can be embedded in R^3 but it is absolutely not the same thing, or a special case where Z=0. They are mathematically distinct concepts.

I don't really see a distinction here. R^2, R^3 or any other R^n for that matter are all normed vector spaces.

It is my opinion that the library and community are best served by maintaining a set of classes for 2D and a separate set of classes for 3D.

Thank you for your feedback.

I will give credit where credit is due, adding the trig related functions to Angle.cs was much needed. It always seemed strange to have an angle unit but have to write " Math.Cos(angle.Radians)" instead of just calling angle.cos.

If the author(s) of the changes feel strongly about the issue the library does have an MIT license, they are free to and some might welcome a new library derived from this one that is based on how they see to make improvements, is that not a reasonable option?

Concluding, I will revert all breaking changes of the last several days up to this commit and reimplement the trig related functions for Angle.

My apologies for taking the library to a direction which didn't align to the community expectations. I would be grateful in the future, if people were a bit more actively involved and shared more feedback.

[jkalias]

They are fundamentally different things, for example there is no such thing as the CrossProduct in 2D, sure there is a pretend version that can be useful at times, but a rigorously defined CrossProduct simply does not exist when working in two dimensional vectors.

This is not true. There is considerable debate on what the proper definition of “cross product” is. The physics based definition we are all familiar with is not mathematically rigorous. In the realm of 2D/3D geometrical algebra , in which the geometric product is more fundamental than the inner or outer product, the outer (cross) product is simply a signed surface spanned by two vectors. Thus not only is it defined, but it makes sense and is also needed for the algebra to be complete.

In addition to that, the current API of Vector2D already defines a cross product with another Vector2D or UnitVector2D, so this is in contradiction to your primary argument.

Anyway, I know this is not relevant anymore, I just wanted to put my thoughts down for future reference.