vector and point confusion. Point subtraction.

[bootchk]

You point out that Apple confuses points and vectors. That comment could be more clear by saying that this project continues that tradition. For example you provide comparison operators between points and vectors. A user must be very careful because that can lead to errors.

Also, you don't provide a subtraction operator between points. But that is the fundamental definition of what a vector is: the difference between two points. And for example, in some maths, addition of points is not defined.

I am not suggesting this is wrong or easily resolved. Just that you might warn users. You see the same thing in other libraries such as PyEuclid. I forked geometryFramed from PyEuclid and there I do distinguish points and vectors.

Thanks for porting to Swift.

[seivan]

I don't quite follow the issues, as there are several ones, I broke them down here below for clarification.

---

You point out that Apple confuses points and vectors. That comment could be more clear by saying that this project continues that tradition. For example you provide comparison operators between points and vectors.

It's a question of perspective, I don't continue the tradition in my opinion. I support backwards compatibility by allowing the user to work with both as agnostic structs.

---

A user must be very careful because that can lead to errors.

Essentially the comparison as well as calculations is on a scalar level and not using specific C-functions that are available. What errors would lead to when comparing two scalar values within the structs? I can't see any issues that could come up, but maybe you had something in mind.

---

Also, you don't provide a subtraction operator between points.

But I do(?) https://github.com/seivan/VectorArithmetic/blob/master/VectorArithmetic/VectorArithmetic.swift#L67-L72

func - <T:VectorOperatable, U:VectorOperatable>(lhs: T, rhs:U) -> T  {
  return T(horizontal: lhs.horizontal-rhs.horizontal, vertical: lhs.vertical-rhs.vertical)
}
func -= <T:VectorOperatable, U:VectorOperatable>(inout lhs: T, rhs:U)  {
  lhs = lhs - rhs
}

[bootchk]

Re: Also, you don't provide a subtraction operator between points.

Looking at your README, it doesn't show "Vector = Point - Point". So maybe it is just missing in the README.

But I tried to subtract two CGPoints and it failed giving: 'Cannot invoke '-' with an argument list of ((CGPoint), (CGPoint)) I expected a vector.

I could be wrong.

[bootchk]

Re: A user must be very careful because that can lead to errors.

I am not saying that it leads to errors within your library. I am saying that if you ease the distinction between points and vectors, you lose the benefit of type safety, which Swift tries to hard to achieve. Consider the addition of points. Most say that doesn't make sense, and indeed it gives a compilation error when using VectorArithmetic (although I expected it would not give a compilation error, it could be related to the point subtraction issue.)

But does a point have a length? "let result = endPointScene.length" doesn't give any compilation errors, where endPointScene is a CGPoint.

Again, I could be wrong and am not an expert.

[raiskila]

Probably a point of confusion here is that while CGPoint, CGVector, and CGSize are treated equally by this library, it may not be apparent when looking at the list of example operations, which are only between a point and a vector.

Thanks for the nice library, BTW!

[bootchk]

I am not sure they are treated equally. Earlier in the thread I reported that CGPoint - CGPoint will not compile. I read the tests, and don't see that test. I could be wrong, and I haven't coded a test in the test suite (just tested it in a stub.)

And my point is that treating them equally may surprise some mathematically inclined coders. For example, you might not expect that the addition of points is defined.

Yes, thanks for the library.

[raiskila]

The following compiles fine for me:

let a = CGPoint()
let b = CGPoint()
let c = b - a

The library extends CGPoint, CGVector, and CGSize to conform to a protocol "VectorOperatable", and the operators are defined for instances of that protocol.

I agree that not all operations between the different types make sense, but I think it might be an acceptable compromise.

[seivan]

@bootchk I'll added new test cases, could you please check it out :)