Geometry Boost List: Re: [geometry] nsphere concept

Subject: Re: [geometry] nsphere concept
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-05-31 18:42:57

On 31-5-2013 23:28, Adam Wulkiewicz wrote:
> Barend Gehrels wrote:
>>>
>>> Indexes names are slightly different and of course may be changed. For
>>> now it's like this:
>>>
>>> bg::get<bg::center_point, 0>(b);
>>> bg::get<bg::center_point, 1>(b);
>>> bg::get<bg::radius_value, 0>(b);
>>>
>>> There is one problem though. get() and set() assume that the type of
>>> returned value is always coordinate_type. So radius type will be
>>> converted if it's different.
>>
>> Yeah, that is true. I realized that also at that time. The get<Index,
>> Dimension> was created for a box and after that reused for the nsphere
>> concept.
>>
>> By the way, I did not yet react on that, but nsphere was the outcome of
>> an intensive discussion about the naming of such a thing...
>>
>> OK, one solution is to make an explicit traits class for this. So not
>> just bg::get but get_radius, or something like that.
>>
>> We also have to take into account the ellipse (2 axis) and ellipsoid (3
>> axis) or a higher dimensional shape. So Radius might have a dimension.
>> However, your proposal supports that.
>> And it might not be axis aligned... (we then go further than our box,
>> which is axis aligned).
>>
>
> 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.

Regards, Barend