-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Semantics of point + vec #102
Comments
I introduced them mainly for visual debugging. The more refined the type system, the easier it is to create default visualizations. It also becomes easier to recognize intend when reading code. |
How would you handle this in the general case? Users would manually define how their types promote? Is there something like function translate{N}(dx::Vec{N}, x::FixedVector{N})
(x_promoted, dx_promoted) = promote(x, dx) # Force same data type
x_promoted + (typeof(x_promoted))(dx_promoted) # Force same base type
end But I don't have any nice design ideas here, beyond passing |
@SimonDanisch - just to check I understand you - you're saying that it all comes down to dispatch: you want the visualization of It leaves me a bit confused though - I still don't know exactly what kind of object With all the above in mind, it seems that |
Exactly, we're not there yet ;) promote_array_type(::typeof(cross), ::Type{Vec}, ::Type{Vec}) = Normal Since Functions are Functors ;) |
Right, it's easy to make the old What's the plan with 0.4 compatibility for FixedSizeArrays? At work we'll probably be using 0.4 until 0.5 starts to become stableish. Sorry for providing mostly complaints here, and not much in the way of PRs yet! |
I want to keep supporting 0.4 as long as possible! We can make promote_op work with 0.4 Functors as well ;) |
Can you tag a version that works with v0.4.x, so that v0.4 can continue to be supported? |
It's not really in sight that we stop supporting 0.4 ;) if it happens, we should sure do that! |
Has anyone discussed the mathematical semantics of Point, and how it relates to Vec? This came up in #101, where the mathematical nature of
Point
might define how Point and Vec interoperate.Is there a good reason to even have
Point
andVec
as different concepts? It makes sense to me ifPoint
is meant to be something in an affine space, but as a FSA it's got a whole bunch of operations which don't make sense on points. For example,Point + Point
andscalar*Point
really don't make a lot of mathematical sense unless you have a blessed origin in your space. If you do have a blessed origin, you actually have a vector space, in which case we may as well be usingVec
instead.To summarize, does
Point
have a well defined reason for existence, or should we just replace it withVec
?The text was updated successfully, but these errors were encountered: