Arrangement_2::insert_foo_bar preconditions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Arrangement_2::insert_foo_bar preconditions

chgans
Hi there,

The various arrangement insert functions (not the free/global ones),
that takes a predecessor half-edge as a parameter don't check for for
the geometric correctness of the operation, eg they will happily
insert (in the circular list around a vertex) an edge 'e' before
another edge 'pred' even if the x_monotone_curve 'c' associated with
'e' is not geometrically on the left/right of the x_monotone_curve
'c_pred' associated with 'pred'.
What is checked instead is 'e->face() == pred->face()', which is
equivalent to the above only when they don't share the same face. If
they share the same face, then chaos is allowed.

If i'm not wrong using the
Kernel::counterclockwise_in_between_2_object() is a better alternative
to ensure the edge 'e' fulfill the geometrical requirement of the
insert operation into the topology structure.

First of all, I would like to know if what I said above makes sense, a
sort of precondition: "do I understand how it's suppose to work?" ;)

If I am right, then i'm curious to know why it is so. Is it omitted
because it's obvious, too expensive to check for, cannot always been
checked in a generic way (eg.: circular kernel) or any other reason?

My bet is that the CounterclockwiseInBetween_2 concept is only
available in the linear kernels (it's not listed in "Function Object
Concepts" chapter of the  2D Arrangements documentation). Thought i'm
still interesting to hear anyone's opinion on that matter.

As a user of an non-linear arrangement, if for example I have to use
insert_at_vertices(c, e1, e2), and I don't want my app to crash, then
i need a way to check for the validity of the insertion. If i can
validate this myself in a way that doesn't require something the
arrangement doesn't have access to, then couldn't this validation be
moved into the arrangement itself?

Regards,
Chris

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Arrangement_2::insert_foo_bar preconditions

Efi Fogel


   ____  _        ____             _
  /_____/_) o    /__________  __  //
 (____ (   (    (    (_/ (_/-(-'_(/
                         _/



On 8 March 2017 at 13:04, Ch'Gans <[hidden email]> wrote:
Hi there,

The various arrangement insert functions (not the free/global ones),
that takes a predecessor half-edge as a parameter don't check for for
the geometric correctness of the operation, eg they will happily
insert (in the circular list around a vertex) an edge 'e' before
another edge 'pred' even if the x_monotone_curve 'c' associated with
'e' is not geometrically on the left/right of the x_monotone_curve
'c_pred' associated with 'pred'.
What is checked instead is 'e->face() == pred->face()', which is
equivalent to the above only when they don't share the same face. If
they share the same face, then chaos is allowed.

If i'm not wrong using the
Kernel::counterclockwise_in_between_2_object() is a better alternative
to ensure the edge 'e' fulfill the geometrical requirement of the
insert operation into the topology structure.

First of all, I would like to know if what I said above makes sense, a
sort of precondition: "do I understand how it's suppose to work?" ;)

It seems that you do understand. 

If I am right, then i'm curious to know why it is so. Is it omitted
because it's obvious, too expensive to check for, cannot always been
checked in a generic way (eg.: circular kernel) or any other reason?

My bet is that the CounterclockwiseInBetween_2 concept is only
available in the linear kernels (it's not listed in "Function Object
Concepts" chapter of the  2D Arrangements documentation). Thought i'm
still interesting to hear anyone's opinion on that matter.

As a user of an non-linear arrangement, if for example I have to use
insert_at_vertices(c, e1, e2), and I don't want my app to crash, then
i need a way to check for the validity of the insertion. If i can
validate this myself in a way that doesn't require something the
arrangement doesn't have access to, then couldn't this validation be
moved into the arrangement itself?

The CounterclockwiseInBetween_2 is a kernel operation, as you say, that is not required by the traits concept; thus there is no guarantee that it is available. As a matter of fact, for those traits classes that do not derive from a kernel, it is not available. You kind of said it.


Regards,
Chris

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss



Reply | Threaded
Open this post in threaded view
|

Re: Arrangement_2::insert_foo_bar preconditions

chgans
On 9 March 2017 at 05:21, Efi Fogel <[hidden email]> wrote:

>
>
>    ____  _        ____             _
>   /_____/_) o    /__________  __  //
>  (____ (   (    (    (_/ (_/-(-'_(/
>                          _/
>
>
>
> On 8 March 2017 at 13:04, Ch'Gans <[hidden email]> wrote:
>>
>> Hi there,
>>
>> The various arrangement insert functions (not the free/global ones),
>> that takes a predecessor half-edge as a parameter don't check for for
>> the geometric correctness of the operation, eg they will happily
>> insert (in the circular list around a vertex) an edge 'e' before
>> another edge 'pred' even if the x_monotone_curve 'c' associated with
>> 'e' is not geometrically on the left/right of the x_monotone_curve
>> 'c_pred' associated with 'pred'.
>> What is checked instead is 'e->face() == pred->face()', which is
>> equivalent to the above only when they don't share the same face. If
>> they share the same face, then chaos is allowed.
>>
>> If i'm not wrong using the
>> Kernel::counterclockwise_in_between_2_object() is a better alternative
>> to ensure the edge 'e' fulfill the geometrical requirement of the
>> insert operation into the topology structure.
>>
>> First of all, I would like to know if what I said above makes sense, a
>> sort of precondition: "do I understand how it's suppose to work?" ;)
>
>
> It seems that you do understand.
>>
>>
>> If I am right, then i'm curious to know why it is so. Is it omitted
>> because it's obvious, too expensive to check for, cannot always been
>> checked in a generic way (eg.: circular kernel) or any other reason?
>>
>> My bet is that the CounterclockwiseInBetween_2 concept is only
>> available in the linear kernels (it's not listed in "Function Object
>> Concepts" chapter of the  2D Arrangements documentation). Thought i'm
>> still interesting to hear anyone's opinion on that matter.
>>
>> As a user of an non-linear arrangement, if for example I have to use
>> insert_at_vertices(c, e1, e2), and I don't want my app to crash, then
>> i need a way to check for the validity of the insertion. If i can
>> validate this myself in a way that doesn't require something the
>> arrangement doesn't have access to, then couldn't this validation be
>> moved into the arrangement itself?
>
>
> The CounterclockwiseInBetween_2 is a kernel operation, as you say, that is
> not required by the traits concept; thus there is no guarantee that it is
> available. As a matter of fact, for those traits classes that do not derive
> from a kernel, it is not available. You kind of said it.

Thanks for the clarification, I hadn't fully realised that the traits
concept doesn't even require a kernel per se.

Chris

>
>>
>> Regards,
>> Chris
>>
>> --
>> You are currently subscribed to cgal-discuss.
>> To unsubscribe or access the archives, go to
>> https://sympa.inria.fr/sympa/info/cgal-discuss
>>
>>
>

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss