CGAL users discussion list

[Jakob van Bethlehem <>]

Hello,

Just in case someone besides has already picked up the patch, I noticed a potential problem. I'm just not sure yet what is the cause of the problem; either this patch or some other part of the P3DT3 
class. Anywaysz: here's what I noticed:
 - when using insert_with_info and the resulting tessellation is still in the 27-sheet coverage space, but the info is only attached to the vertices inside the fundamental domain (namely those you 
added through the insertion) This may or not be desirable, for me that is no problem.
 - however, related (or not), also the offsets for periodic points are always null, even for vertices outside the fundamental domain. I don't have a minimum explicit example, but here's a rough 
indication:

// assuming I built up some vector 'vec' of not too many pair<Point, Info> 
objects,
// and PDT is a correct typedef of a Periodic_3_Delaunay_triangulation_3 
class,
// the following would call the insert_with_info() function:
PDT tess(vec.begin(), vec.end());

// next loop over all cells:
auto cell = tess.cells_begin();
auto last = tess.cells_end();
for (; cell != last; ++cell)
{
  int idx;
  // now for idx=0,1,2,3 and for each cell
  // tess.periodic_point(cell->vertex(idx)).second.is_null() returns true 
even though the tessellation is still
}

Since cells_begin() loops over all cells, including those in the 27-sheeted covering I'd expect that is_null() would only be true for vertices inside the domain, but it actually is true for all cells 
and all vertices of those cells.
I'm not sure though whether this observation is related to the patch I 
created. I have not tested yet what happens using the normal insert(). Maybe 
I can find some time to do that later.

Sincerely,
Jakob


On 03/02/2012 05:13 PM, Jakob van Bethlehem wrote:
> Hej,
>
> Following up yet again, I found a minor problem in my patch for 
> Periodic_3_triangulation_3.h. That patch should be replaced with the attached 
> version.
> (btw, these are patches against the 3.9 release version, which I tried to 
> message across by adding the '-3.9' postfix)
>
> Sincerely,
> Jakob van Bethlehem
>
>
> On 03/01/2012 06:10 PM, Jakob van Bethlehem wrote:
> > Hello,
> >
> > Following up on my question earlier today, I created patches the allow 
> > insertion of vertices with info into a Periodic_3_Delaunay_triangulation_3 
> > from eg a vector of such vertices. I'm not sure what
> > is the custom when posting patches, but I created a separate patch for both 
> > files involved: Periodic_3_triangulation_3.h and 
> > Periodic_3_Delaunay_triangulation_3.h. Also it is not purely a patch that
> > adds the new functionality:
> >
> > * there was a minor issue in the normal insert(InputIterator, InputIterator) 
> > routine in Periodic_3_Delaunay_triangulation_3: points already inserted from 
> > the 'points' vector during an initial
> > insertion were re-inserted during the insert_in_conflict() call.
> > * the special 'is_large_point_set' value, IMHO, should also be present in the 
> > constructor, passing that value on to the call to insert()
> > * the new functionality of inserting points with info: I followed the same 
> > procedure as in Delaunay_triangulation_3.h and didn't have to invent anything 
> > 'new'.
> >
> > Some other thoughts that came up while working on this:
> > - Why is this 'insert-with-info' routine only defined in the 
> > Delaunay-classes? I wasn't able to find any reason why the exact same 
> > function wouldn't work in the respective parent classes
> > Triangulation_3 and Periodic_3_triangulation_3
> > - When the insert_with_info() routines get presented with the (unfortunate) 
> > situation that 'is_large_point_set==true', but the input set is actually 
> > small, it will result in a SegmentationFault
> > somehow. I haven't been able to figure out why this happens, but it seems to 
> > me that this is not the wanted outcome :P I may have some time later to have 
> > a look at this, but since in my application
> > this situation will not occur, unfortunately it will probably end up pretty 
> > low on my priority list.
> >
> > Sincerely,
> > Jakob van Bethlehem