"Type-Safe" Point subtraction

[cdsousa]

Reading https://ajeetdsouza.github.io/blog/posts/type-safe-raytracing-in-modern-cpp/ I wonder if p1::Point - p2::Point should return a Vec rather than a Point. Does that would make any sense?

[SimonDanisch]

This has been discussed multiple times... Sorry, can't find the issue right now :(

[cdsousa]

👍 I've tried to find anything related too, but I couldn't.

[SimonDanisch]

@c42f do you remember where that was?

[c42f]

Does that make any sense?

Yes this does make complete sense; do read about affine spaces for the full detail.

@c42f do you remember where that was?

Hmm good question. I recall having multiple conversations with @andyferris about this over the years but don't remember whether we really wrote it down somewhere. There's JuliaArrays/StaticArrays.jl#3 which is related.

Lately @OTDE has been working on some rendering tools which has brought it back to mind.

Thinking about it again, I've been starting to wonder whether there's enough practical benefit to justify modeling the affine vs vector space distinction in Julia's type system. In C++ there's value in statically proving certain correctness properties via the type system when distinguishing points from vectors (and normals). In Julia we don't get this benefit; instead we may get a very weakened version of it at runtime.

In Julia I think the main value of the point-vs-vector-vs-normal distinction may come from the ability to dispatch to different methods for Vec vs Point. But I'm also not sure how useful this is in generic code? Perhaps for dispatch in plotting, but if it doesn't provide value in generic mathematical code I think it may ultimately be an unhelpful distinction. That is, if a calculation doesn't naturally produce Vec, but one has to convert to Vec especially for plotting dispatch purposes, this means the conversion site is specialized to the plotting task and one may as well just add plotting parameters rather than converting the input data type...