Geometry Boost List: Re: [geometry] nsphere concept

Subject: Re: [geometry] nsphere concept
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-06-01 19:09:29

Barend Gehrels wrote:
> n 1-6-2013 4:33, Adam Wulkiewicz wrote:
>>
>> If we had the general get<>() we still would be forced to use
>> different traits e.g. coordinate_type and radius_type. It would be
>> nice if there were also a general indexed value_type or access_type
>> trait.
>
> Besides "nice" I don't see the advantage. I see this as an argument for
> the reverse. get<> delivers something described by coordinate_type. Now
> you need two types for it.
>

Please replace "nice" with "convinient". Assuming that we had this 
general get(), we most probably won't, but then it would be convinient 
to have general type definition. The user wouldn't be forced to know 
which trait was used for which index.

>> Now get<>() is used to access point/position coordinates. But it may
>> change soon.
>
> Nice is, (assuming this is the answer to your question "why" before)
> certainly not a good reason.
>

The point and position are the keywords here. What I had in mind was 
that they might be used not only to access points' coordinates. In 
vectors there are coordinates but they don't define a position, in 
matrices there are elements, in quaternions components, in rays 
direction coordinates, in euler angles there are angles, etc.

>>
>> I've already used it to access vector, matrix and quaternion elements,
>> which aren't position coordinates.
>
> You are now talking about other libraries, giving access to an element
> in their structured collection in a uniform way. They don't have a get<>
> to return the size of the matrix in two dimensions, I suppose.
>
> We give access to coordinates (our elements in our structured
> collection) in a uniform way.
>

I'm talking about Boost.Geometry. NSphere is now the only one, probably 
the first one concept storing data other than points' coordinates. We 
probably would like to define other ones in the future. So our 
coordinate_type would be in fact the type of some main stored data.

I've implemented vectors, matrix and quaternion concepts because one 
should probably be able to use arbitrary linear algebra library to 
transform Geometries. Do you think that those or similar concepts should 
be a part of Boost.Geometry? Or should only data defined by Points be 
allowed?

I've used coordinate_type and get to define components. Is this correct? 
What should we do in the case of e.g. AxisAngle rotation representation? 
Should axis coordinates be accessed by get<>() and angle by e.g. 
get_angle<0>()? And then in the case of EulerAngles rotation (assuming 
that it will be a concept) should they be accessed by get<>() or 
get_angle<>()?

>
>> Oriented boxes could store center point and Dim*vectors with
>> coordinates of different type than the point. Planes and Rays could
>> store a point and a vector. Even if they all used the same
>> coordinate_types, points would be positions and vectors would be
>> directions or directions multiplied by lengths.
>>
>> Regarding nsphere. One-argument get<>() is used to access Geometry's
>> position coordinate. The same function is used in the case of Nsphere.
>> In the case of Points it's ok since they have coordinates which can be
>> indexed. But Nsphere really hasn't coordinates, it may have the center
>> which has coordinates.
>
> "It may have the center" is too vague. It hás the center which has
> coordinates. And yes, get<> is used to get the center of the n-sphere.
>

So if Geometry store some number of points they are accessed using 
indexed_access. If only one point is stored, one-argument access should 
be used, like if it was a Point?

>> Any other point of sphere (or rather ball) may be good to indicate
>> it's position, the center is probably just the best one. Using get<>()
>> to access center's coordinates is an elliptical construction. This
>> however probably just depends on the point of view.
>>
>> get_radius<>() is ok, it's just redundant.
>
>
> No, it is not redundant. It returns the radius, which is a unique
> property of a geometry, not being a coordinate.
>

I've written this assuming that there would be this general get<>().

> As you see I'm not convinced. I see not any reason to change, I only see
> confusion, unnecessary complexity and possible problems.
>

I agree.

> This is, for example, big disadvantage by doing everything with get: our
> generic algorithms work on geometry::get<Index, Dimension>, for example
> to transform coordinates, move them by (5,5) or scale them by (2,2). As
> soon as get<> is implemented to nspheres, their coordinates AND radius
> will be increased by (5,5) just like with the coordinates of a box. And
> for scale too. (OK, admitted, for scale, automatically increasing the
> radius with the same amount as the coordinates might - sometimes - be a
> valid scenario, but certainly not always - you want to control this - it
> is a different thing)
>

Well, this is not entirely true. This reasoning works for Geometries 
which are points containers. In other cases you probably will use 
get<>() and set<>() in some specific way, depending on the thing you'd 
like to do. For example to rotate a polygon you'd rotate all of its 
points but rotating min and max Box's point won't result in what you'd 
like to achieve.

I admit that this change isn't necessary, confusing and even limiting. 
Suppose we introduced the 3D Capsule or Cylinder concept. We'd then 
probably want to access points' coordinates using indexed get<>() and 
radiuses for each point using indexed get_radius<>(). If we now used 
get<>() to access radius it would be hard to implement consistent interface.

Regards,
Adam