
Geometry : 
Subject: Re: [geometry] nsphere concept
From: Barend Gehrels (barend_at_[hidden])
Date: 20130601 04:50:21
n 162013 4:33, Adam Wulkiewicz wrote:
> Barend Gehrels wrote:
>> On 3152013 23:28, Adam Wulkiewicz wrote:
>>>
>>> Yes, I saw how nsphere is implemented and accessed. I find it
>>> nonintuitive because Nth radius is returned by get_radius<N>() and
>>> Nth 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 lengthmeasurement (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 generalpurpose 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. Oneargument 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 nsphere.
> 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
Geometry list run by mateusz at loskot.net