CGAL users discussion list

["Max" <>]

>> >
>> >The system is supposed to behave the same way with the indexed items.
>> >The only difference should be in input and output of coordinates. If you
>> >have bugs, then send them to me. I will do the debugging. It's important
>> >for me to make the indexed items as reliable as possible.
>> 
>> The context of the error is as the attached sreenshot.
>> If it's not enough, I'll prepare a minimum program that can reproduce the 
>> problem. 
>
>That would be good. I'm curious about the problem. 

I attach the test program for reproducing the problem.
To make the code as small in size as possible, I've commented out 
the irrelevant code. The sample data file is also attached.
I hope I'm not making stupid mistake. :-)

>
>> One thing to note: I'm reading a nef_3 from a .nef file. 
>> And I've refreshed the .nef file from an identical .off model (very simple)
>> using the nef_3 type with the indexed items type. (I've not found any 
>> significant 
>> difference in format from the two .nef files written from two identical 
>> nef_3
>> with different items types)
>
>What is the question of this paragraph? Are you wondering that the nef
>files are the same although you use different kernels? That's intended.

I already know the content of .nef files written with different kernels
are different. and I also guess there's difference in contents between 2 
.nef files written with different items types. But I cannot detect any 
significant diff's.

>I spent lots of time to write input and output functions that convert
>and normalize coordinates. 
Yes, writting the i/o module of nef_3 is a hard work.

>Actually I have code that even sorts the
>output such that it is always the same, but I only use that for testing
>purpose.

That's a good news. And I think it's a good idea to make it open.
It's a good idea to keep a uniform format of .nef files for different
kernel types and items types, as long as it's possible practically 
and theoritically.
 
>
>> 
>> Sorry, it's a typo, it should be:
>>     Plane_3 p;
>>      Nef_3 N;
>>     Nef_3 result = N.intersection(p).intersection(p.opposite());
>
>I got that fault in the first place. My comments where on the corrected
>version. Do you already have an impression of how much the indexed items
>help you? Is Nef still a bad bottleneck? How much of a speed up do you
>need?

You mean this idiom is ok for my need?

I have not got an impression of the indexed items yet, because
the program just refused to work. I hope, after I get the indexed items
working, it will not be the bottleneck. :-)

>
>Peter
>
>
>
>-- 
>You are currently subscribed to cgal-discuss.
>To unsubscribe or access the archives, go to
>https://lists-sop.inria.fr/wws/info/cgal-discuss
>

Attachment: tmp.cpp
Description: Binary data

Attachment: 1.off
Description: Binary data