{"action":"created","issue":{"url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/102","repository_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl","labels_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/102/labels{/name}","comments_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/102/comments","events_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/102/events","html_url":"https://github.com/SimonDanisch/FixedSizeArrays.jl/issues/102","id":151572507,"number":102,"title":"Semantics of Point","user":{"login":"c42f","id":601473,"avatar_url":"https://avatars.githubusercontent.com/u/601473?v=3","gravatar_id":"","url":"https://api.github.com/users/c42f","html_url":"https://github.com/c42f","followers_url":"https://api.github.com/users/c42f/followers","following_url":"https://api.github.com/users/c42f/following{/other_user}","gists_url":"https://api.github.com/users/c42f/gists{/gist_id}","starred_url":"https://api.github.com/users/c42f/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/c42f/subscriptions","organizations_url":"https://api.github.com/users/c42f/orgs","repos_url":"https://api.github.com/users/c42f/repos","events_url":"https://api.github.com/users/c42f/events{/privacy}","received_events_url":"https://api.github.com/users/c42f/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2016-04-28T07:56:36Z","updated_at":"2016-04-29T00:48:18Z","closed_at":null,"body":"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.\r\n\r\nIs there a good reason to even have `Point` and `Vec` as different concepts?  It makes sense to me if `Point` 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` and `scalar*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 using `Vec` instead.\r\n\r\nTo summarize, does `Point` have a well defined reason for existence, or should we just replace it with `Vec`?"},"comment":{"url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/comments/215603386","html_url":"https://github.com/SimonDanisch/FixedSizeArrays.jl/issues/102#issuecomment-215603386","issue_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/102","id":215603386,"user":{"login":"andyferris","id":2974526,"avatar_url":"https://avatars.githubusercontent.com/u/2974526?v=3","gravatar_id":"","url":"https://api.github.com/users/andyferris","html_url":"https://github.com/andyferris","followers_url":"https://api.github.com/users/andyferris/followers","following_url":"https://api.github.com/users/andyferris/following{/other_user}","gists_url":"https://api.github.com/users/andyferris/gists{/gist_id}","starred_url":"https://api.github.com/users/andyferris/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/andyferris/subscriptions","organizations_url":"https://api.github.com/users/andyferris/orgs","repos_url":"https://api.github.com/users/andyferris/repos","events_url":"https://api.github.com/users/andyferris/events{/privacy}","received_events_url":"https://api.github.com/users/andyferris/received_events","type":"User","site_admin":false},"created_at":"2016-04-29T00:48:18Z","updated_at":"2016-04-29T00:48:18Z","body":"How would you handle this in the general case? Users would manually define how their types promote? Is there something like `promote_rule` to give guidance to `promote()`? Or a three-argument `promote()` or similar? Ideally, this could be a bit easier than, e.g.:\r\n\r\n```julia\r\nfunction translate{N}(dx::Vec{N}, x::FixedVector{N})\r\n    (x_promoted, dx_promoted) = promote(x, dx) # Force same data type\r\n    x_promoted + (typeof(x_promoted))(dx_promoted) # Force same base type\r\nend\r\n```\r\n\r\nBut I don't have any nice design ideas here, beyond passing `Val{1}` or `Val{2}` to `promote` as a third argument."}}