Subject: Re: [geometry] nsphere concept
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-05-28 17:32:21
On 27-5-2013 1:30, Adam Wulkiewicz wrote:
> Adam Wulkiewicz wrote:
>> I have some thoughts about the nsphere that I'd like to share. For now I
>> think of two changes:
>> template <
>> typename Point,
>> typename Radius = coordinate_type<Point>::type
>> class ball;
>> 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
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<G, I, D>::value_type
That is another option.
Geometry list run by mateusz at loskot.net