Geometry Boost List: Re: [geometry] nsphere concept

Subject: Re: [geometry] nsphere concept
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-06-01 04:50:21

n 1-6-2013 4:33, Adam Wulkiewicz wrote:
> Barend Gehrels wrote:
>> On 31-5-2013 23:28, Adam Wulkiewicz wrote:
>>>
>>> Yes, I saw how nsphere is implemented and accessed. I find it
>>> nonintuitive because N-th radius is returned by get_radius<N>() and
>>> N-th center point coordinate is returned by get<N>(). Other geometries
>>> which contain some points like box or segment uses indexed access,
>>> e.g. get<0, N>(). I feel that it would be more suitable for
>>> nsphere/ball too.
>>
>> I did not look it up when I wrote my previous reply, but apparently the
>> original nsphere already has what I suggested...
>>
>> OK, to be honest I find a separate function much more intuitive. bg::get
>> returns a coordinate. But a radius is not a coordinate. So that is why
>> we took a different function there, and it makes sense. It feels strange
>> to me to return a coordinate (the center) and a length-measurement (the
>> radius) using one function, just by changing the index. And yes, it
>> gives problems too for different coordinate type / radius type (these
>> should also differ...)
>>
>> For box/segment, get is indeed indexed, but in both cases it returns
>> real coordinates and not another geometry property.
>>
>
> Yes, as I've written it would require the change of the purpose of the 
> get<>() function. Now it's the function returning coordinates. After 
> the change it would be a general-purpose accessor. Returning various 
> types isn't really a problem, tuple's get<>() does it.

For tuple it is the main purpose. It is designed to give access to 1..N 
elements in a generic way.

>
> 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.

get<> / coordinate_type belong together.
get_radus / radius_type belong together.

This is consistent.

>
> Why should we consider it?
>
> 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.

>
> 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.

This is similar.

> 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.

> 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.

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

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)

Regards, Barend