Geometry Boost List: Re: [geometry] nsphere concept

Subject: Re: [geometry] nsphere concept
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-05-28 17:32:21

Hi Adam,

On 27-5-2013 1:30, Adam Wulkiewicz wrote:
> Hi,
>
> Adam Wulkiewicz wrote:
>>
>> I have some thoughts about the nsphere that I'd like to share. For now I
>> think of two changes:
>>
> <snip>
>>
>> template <
>>    typename Point,
>>    typename Radius = coordinate_type<Point>::type
>> class ball;
>>
> <snip>
>>
>> get<centre, I>(sph)
>> get<radius, I>(sph)
>>
>
> To show you what I'm talking about I've implemented it and added to 
> extensions/ball (I've given it ID 95, don't know if it's ok).
>
> 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).

>
> What is the reason of this? Would it be reasonable to use some type 
> defined in
>
> core_dispatch::indexed_access
>
> e.g.
>
> core_dispatch::indexed_access<G, I, D>::value_type

That is another option.

Regards, Barend