A generic point type in Base?

[Tomas Lycken]

There’s a multitude of problems defined on a continuous 2D domain, where it makes sense do define a type

immutable Point{T<:Number}
    x::T
    y::T
end

It’s common, yet simple, enough to be the example on parametric types in the manual. Yet I can’t find any type like this in Base.

Of course, since the implementation is trivial it’s easy to just carry one with the project, but I think it would make sense to include such a type in Base so that all packages can use the same 2D point type, thereby making it much easier to communicate these points between applications.

Is there a reason this has been excluded, or is it just that no-one has tried to include it yet? What are the opinions on including such a type? Are there others, that might provide similar benefits?

// Tomas

​

[Peder Axensten]

I work with several libraries handling points and other geometrical objects in C++. The multitude of point types is a hurdle. 

I would suggest to take a good look at the geometry library in Boost (of C++ fame) for in-deprh concepts of geometric objects. 

You want to specify the coordinate type, but probably also the dimension of the point. Maybe also the coordinate system of the point (cartesian being the default). 

When you have a generic point type, you can write access functions such as getZ and setZ (that only works on cartesian points with dimension 3 or higher) or getLatitude (for spherical points of dimension 2 or higher).

Building on points it is natural to implement boxes other objects with volume and funtions for how they relate (like inside, overlapping, touching etc.).

Hälsar Peder

[Ivar Nesje]

I think a common Point type for use in different Julia libraries would make sense. The problem is how to decide what to include and what not to include. It would feel weird if Base provided a Point type with no methods defined, so that packages would start to overload conflicting versions of the common operators. Do you think Base should provide a complete set of auxiliary functions (abs, distance, coordinate system transformations, etc.)?

I don't think this belongs in Base, but it would be great if we had a barebones package that could serve as a foundation for other packages to share types and the simple operations on the objects. If such a package got traction and proved useful, it could be included in the set of default packages that will be installed by default.

Ivar

[Stefan Karpinski]

This is definitely needed. Some kind of Geometry package that has basic geometric objects like points, lines, line segments, polygons, etc. Then you work towards having all the packages that need this kind of type use that. One of the big questions is whether Point should be parameterized by the number of dimensions. Or should a 2-d point with coordinate type T just be (T,T)? In that case, we need to ensure that it is stored as just a pair of values of type T.

[Tobi]

I think this is closely related to the question if and how we will get fixed-size vector/array support in Base.

In https://github.com/JuliaLang/julia/blob/master/base/graphics.jl there is by the way already a Vec2 type that seems to be supposed to represent a point.

[Mauro]

There is a Point and some geometry things in graphics.jl

>>> <http://docs.julialang.org/en/latest/manual/types/#parametric-composite-types>.

>>> Yet I can’t find any type like this in Base.
>>>
>>> Of course, since the implementation is trivial it’s easy to just carry
>>> one with the project, but I think it would make sense to include such a
>>> type in Base so that all packages can use the same 2D point type,
>>> thereby making it much easier to communicate these points between
>>> applications.
>>>
>>> Is there a reason this has been excluded, or is it just that no-one has
>>> tried to include it yet? What are the opinions on including such a type?
>>> Are there others, that might provide similar benefits?
>>>
>>> // Tomas
>>> ​
>>>
>>>

--

[Ivar Nesje]

Another argument against adding this to Base (if it were not already there), is that it would be impossible to find. :P

Ivar

[Tomas Lycken]

:)

It seems to me that some of the geometry stuff in graphics.jl should be lifted out into a more general Geometry module, which can (for instance) have higher-dimensional points as well (I imagine at least 3D and 4D are useful to physics people like me). Whether that is actually in Base or just in a package (which, preferably, would be included in a "standard installation" and precompiled, when that comes along) doesn't matter at all to me.

However, I take this discussion to mean that currently there are no general geometry objects that I should use if I start working on a package that could have use for this - instead, I'll have to define my own types with methods for them, hope that the API I choose is close enough to whatever is built later, and adjust the package when something comes along.

// T

[Ivar Nesje]

See also the issue that prompted the addition of the graphics.jl file into Base

https://github.com/JuliaLang/julia/issues/1609

[Johan Sigfrids]

Maybe there should be a GeometryBase package similar to the StatsBase package.

[Peder Axensten]

I think the main thing is that the point class is generic enough, so that it will be able to accomodate the needs of more specialized libraries. Access functions to read and set individual coordinates by index should certainly be included. Could this be in Base?

For cartesian points (and only them!), I think probably absolute value, euclidean distance (and maybe other distances), dot-product, addition, and subtraction would be uncontroversial, as well as multiplication and division by scalars. Maybe this should be in library Cartesian?

For spherical, ellipsoidal, and other points, it would probably be better to implement them in specific libraries?

In Boost, the coordinate system of a point is only a template argument. So it is there as a "tag" if you want to overload functions according to this, but occupies no memory. Being very interested in Julia, but not yet an active developer, I don't know how to best "tag" this here. But I'm sure it is doable. 

Hälsar Peder

[Steve Kelly]

In my MeshSlicer package I've been using ImmutableArrays (Vector2 and
Vector3) for this purpose. It works very well and has the appropriate
operations defined. Meshes.jl is also a good reference for using
ImmutableArrays with geometric algorithm.

https://github.com/twadleigh/Meshes.jl
https://github.com/twadleigh/ImmutableArrays.jl