relate() interface

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

relate() interface

Adam Wulkiewicz
Hi,

Recently a user requested to add a user-defined spatial predicate:
relate() is there in the details from quite some time so I thought it's a good time to make it official. But before that we should think about the interface.

First, the requirements. I think it should be possible to:
- return a DE9IM matrix
- check DE9IM run-time mask
- check DE9IM compile-time mask
- pass ORed masks and use them directly in the check
- possible addition of other IMs though I doubt that anything else than DE9IM will be supported

FYI, all of the above is supported in the details. But the interface need to be polished. I'm thinking about something like this:

// basic, return DE9IM matrix
std::string matrix = relate(g1, g2);

// basic, check DE9IM run-time mask
bool res = relate(g1, g2, "T********");


We need a way to pass ORed masks. We have a few options but I'm thinking about this:

bool res = relate(g1, g2, de9im::mask("FT*******") ||
                          de9im::mask("F**T*****") ||
                          de9im::mask("F***T****"));

Compile-time masks:

typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
bool res = relate<II>(g1, g2);

or just

bool res = relate(g1, g2, II());


In the second case the same technique for ORing masks could be used. Otherwise we'd be forced to gather them in some type like, de9im::or<M1, M2, M3, M4, ...>, mpl::vector<> or boost::tuple<>. Either way the compiler should be able to optimize I think. Besides it's implemented like this anyway in the details. The third parameter is just created by default using the default ctor. This of course can be changed. So again, we have two options:

typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
typedef de9im::static_mask<'*','*','*','*','T','*','*','*','*'> BB;
bool res = relate<de9im::or<II, BB>>(g1, g2);

or

de9im::static_mask<'T','*','*','*','*','*','*','*','*'> ii;
de9im::static_mask<'*','*','*','*','T','*','*','*','*'> bb;

bool res = relate(g1, g2, ii || bb);


What do you think?
Do you like the names?
Any ideas are welcome.

E.g. maybe the names should be:
- de9im::dynamic_mask and de9im::mask (instead of static_mask)
- de9im::dmask and de9im::smask
- de9im::mask_d and de9im::mask_s
- ?

Regards,
Adam

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: relate() interface

Mats Taraldsvik-2


On Tue, Apr 28, 2015 at 1:47 AM, Adam Wulkiewicz <[hidden email]> wrote:
Hi,

Recently a user requested to add a user-defined spatial predicate:
relate() is there in the details from quite some time so I thought it's a good time to make it official. But before that we should think about the interface.

First, the requirements. I think it should be possible to:
- return a DE9IM matrix
- check DE9IM run-time mask
- check DE9IM compile-time mask
- pass ORed masks and use them directly in the check
- possible addition of other IMs though I doubt that anything else than DE9IM will be supported

FYI, all of the above is supported in the details. But the interface need to be polished. I'm thinking about something like this:

// basic, return DE9IM matrix
std::string matrix = relate(g1, g2);

// basic, check DE9IM run-time mask
bool res = relate(g1, g2, "T********");


We need a way to pass ORed masks. We have a few options but I'm thinking about this:

bool res = relate(g1, g2, de9im::mask("FT*******") ||
                          de9im::mask("F**T*****") ||
                          de9im::mask("F***T****"));

Compile-time masks:

typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
bool res = relate<II>(g1, g2);

or just

bool res = relate(g1, g2, II());


In the second case the same technique for ORing masks could be used. Otherwise we'd be forced to gather them in some type like, de9im::or<M1, M2, M3, M4, ...>, mpl::vector<> or boost::tuple<>. Either way the compiler should be able to optimize I think. Besides it's implemented like this anyway in the details. The third parameter is just created by default using the default ctor. This of course can be changed. So again, we have two options:

typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
typedef de9im::static_mask<'*','*','*','*','T','*','*','*','*'> BB;
bool res = relate<de9im::or<II, BB>>(g1, g2);

or

de9im::static_mask<'T','*','*','*','*','*','*','*','*'> ii;
de9im::static_mask<'*','*','*','*','T','*','*','*','*'> bb;

bool res = relate(g1, g2, ii || bb);


What do you think?
Do you like the names?
Any ideas are welcome.

E.g. maybe the names should be:
- de9im::dynamic_mask and de9im::mask (instead of static_mask)
- de9im::dmask and de9im::smask
- de9im::mask_d and de9im::mask_s
- ?

Regards,
Adam

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry



_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: relate() interface

Mats Taraldsvik-2
In reply to this post by Adam Wulkiewicz
Hi,

On Tue, Apr 28, 2015 at 1:47 AM, Adam Wulkiewicz <[hidden email]> wrote:
Hi,

Recently a user requested to add a user-defined spatial predicate:
relate() is there in the details from quite some time so I thought it's a good time to make it official. But before that we should think about the interface.

First, the requirements. I think it should be possible to:
- return a DE9IM matrix
- check DE9IM run-time mask
- check DE9IM compile-time mask
- pass ORed masks and use them directly in the check
- possible addition of other IMs though I doubt that anything else than DE9IM will be supported

FYI, all of the above is supported in the details. But the interface need to be polished. I'm thinking about something like this:

// basic, return DE9IM matrix
std::string matrix = relate(g1, g2);

What about using std::bitset? It has a constexpr constructor and can convert to/from a std::string (with custom characters indicating true / false). No dynamic allocations necessary :)

http://en.cppreference.com/w/cpp/utility/bitset

Binary logic is also supported out of the box.
 

// basic, check DE9IM run-time mask
bool res = relate(g1, g2, "T********");


We need a way to pass ORed masks. We have a few options but I'm thinking about this:

bool res = relate(g1, g2, de9im::mask("FT*******") ||
                          de9im::mask("F**T*****") ||
                          de9im::mask("F***T****"));

Compile-time masks:

typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
bool res = relate<II>(g1, g2);

or just

bool res = relate(g1, g2, II());


In the second case the same technique for ORing masks could be used. Otherwise we'd be forced to gather them in some type like, de9im::or<M1, M2, M3, M4, ...>, mpl::vector<> or boost::tuple<>. Either way the compiler should be able to optimize I think. Besides it's implemented like this anyway in the details. The third parameter is just created by default using the default ctor. This of course can be changed. So again, we have two options:

typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
typedef de9im::static_mask<'*','*','*','*','T','*','*','*','*'> BB;
bool res = relate<de9im::or<II, BB>>(g1, g2);

or

de9im::static_mask<'T','*','*','*','*','*','*','*','*'> ii;
de9im::static_mask<'*','*','*','*','T','*','*','*','*'> bb;

bool res = relate(g1, g2, ii || bb);


What do you think?
Do you like the names?
Any ideas are welcome.

E.g. maybe the names should be:
- de9im::dynamic_mask and de9im::mask (instead of static_mask)
- de9im::dmask and de9im::smask
- de9im::mask_d and de9im::mask_s
- ?

Regards,
Adam

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry



_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: relate() interface

Adam Wulkiewicz
Hi Mats,

Mats Taraldsvik wrote:
Hi,

On Tue, Apr 28, 2015 at 1:47 AM, Adam Wulkiewicz <[hidden email]> wrote:
Hi,

Recently a user requested to add a user-defined spatial predicate:
relate() is there in the details from quite some time so I thought it's a good time to make it official. But before that we should think about the interface.

First, the requirements. I think it should be possible to:
- return a DE9IM matrix
- check DE9IM run-time mask
- check DE9IM compile-time mask
- pass ORed masks and use them directly in the check
- possible addition of other IMs though I doubt that anything else than DE9IM will be supported

FYI, all of the above is supported in the details. But the interface need to be polished. I'm thinking about something like this:

// basic, return DE9IM matrix
std::string matrix = relate(g1, g2);

What about using std::bitset? It has a constexpr constructor and can convert to/from a std::string (with custom characters indicating true / false). No dynamic allocations necessary :)

http://en.cppreference.com/w/cpp/utility/bitset

Binary logic is also supported out of the box.

Unfortunately a matrix or a mask should be able to contain at least 5 different "digits" (*, T, F, 1, 2). See: http://en.wikipedia.org/wiki/DE-9IM
Other dimensions could be there too so effectively there could be 12 or 13 "digits". They're not in the standard but this way we'd support n-dimensional non-standard geometries like Point, Box or N-sphere.

But AFAIU your point is that you'd prefer to store the matrix or mask in a static memory. The most simple thing would be to have char[9]. And this is how it's done internally. Of course we could think about compressing it somehow in the future.
Those two the most basic variants was proposed only for users convenience. But maybe indeed more clear would be to force the users to always use the matrix representation from de9im namespace:

de9im::matrix m = relate(g1, g2);

?

 

// basic, check DE9IM run-time mask
bool res = relate(g1, g2, "T********");


this one could look the same or we could always require the creation of the de9im::mask explicitly so:

bool res = relate(g1, g2, de9im::mask("T********"));


We need a way to pass ORed masks. We have a few options but I'm thinking about this:

bool res = relate(g1, g2, de9im::mask("FT*******") ||
                          de9im::mask("F**T*****") ||
                          de9im::mask("F***T****"));

Compile-time masks:

typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
bool res = relate<II>(g1, g2);

or just

bool res = relate(g1, g2, II());


In the second case the same technique for ORing masks could be used. Otherwise we'd be forced to gather them in some type like, de9im::or<M1, M2, M3, M4, ...>, mpl::vector<> or boost::tuple<>. Either way the compiler should be able to optimize I think. Besides it's implemented like this anyway in the details. The third parameter is just created by default using the default ctor. This of course can be changed. So again, we have two options:

typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
typedef de9im::static_mask<'*','*','*','*','T','*','*','*','*'> BB;
bool res = relate<de9im::or<II, BB>>(g1, g2);

or

de9im::static_mask<'T','*','*','*','*','*','*','*','*'> ii;
de9im::static_mask<'*','*','*','*','T','*','*','*','*'> bb;

bool res = relate(g1, g2, ii || bb);


What do you think?
Do you like the names?
Any ideas are welcome.

E.g. maybe the names should be:
- de9im::dynamic_mask and de9im::mask (instead of static_mask)
- de9im::dmask and de9im::smask
- de9im::mask_d and de9im::mask_s
- ?

Regards,
Adam


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: relate() interface

Mats Taraldsvik-2

Hi Adam,

On Apr 28, 2015 1:41 PM, "Adam Wulkiewicz" <[hidden email]> wrote:
>
> Hi Mats,
>
> Mats Taraldsvik wrote:
>>
>> Hi,
>>
>> On Tue, Apr 28, 2015 at 1:47 AM, Adam Wulkiewicz <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> Recently a user requested to add a user-defined spatial predicate:
>>> https://svn.boost.org/trac/boost/ticket/11232
>>> relate() is there in the details from quite some time so I thought it's a good time to make it official. But before that we should think about the interface.
>>>
>>> First, the requirements. I think it should be possible to:
>>> - return a DE9IM matrix
>>> - check DE9IM run-time mask
>>> - check DE9IM compile-time mask
>>> - pass ORed masks and use them directly in the check
>>> - possible addition of other IMs though I doubt that anything else than DE9IM will be supported
>>>
>>> FYI, all of the above is supported in the details. But the interface need to be polished. I'm thinking about something like this:
>>>
>>> // basic, return DE9IM matrix
>>> std::string matrix = relate(g1, g2);
>>
>>
>> What about using std::bitset? It has a constexpr constructor and can convert to/from a std::string (with custom characters indicating true / false). No dynamic allocations necessary :)
>>
>> http://en.cppreference.com/w/cpp/utility/bitset
>>
>> Binary logic is also supported out of the box.
>
>
> Unfortunately a matrix or a mask should be able to contain at least 5 different "digits" (*, T, F, 1, 2). See: http://en.wikipedia.org/wiki/DE-9IM
> Other dimensions could be there too so effectively there could be 12 or 13 "digits". They're not in the standard but this way we'd support n-dimensional non-standard geometries like Point, Box or N-sphere.
>
> But AFAIU your point is that you'd prefer to store the matrix or mask in a static memory. The most simple thing would be to have char[9]. And this is how it's done internally. Of course we could think about compressing it somehow in the future.
> Those two the most basic variants was proposed only for users convenience. But maybe indeed more clear would be to force the users to always use the matrix representation from de9im namespace:
>
> de9im::matrix m = relate(g1, g2);
>
>
> ?
>

Ok, I understand. Yes, I think that exposing the de9im type directly is better.

>>  
>>>
>>>
>>> // basic, check DE9IM run-time mask
>>> bool res = relate(g1, g2, "T********");
>
>
> this one could look the same or we could always require the creation of the de9im::mask explicitly so:
>
> bool res = relate(g1, g2, de9im::mask("T********"));
>
>
>>>
>>> We need a way to pass ORed masks. We have a few options but I'm thinking about this:
>>>
>>> bool res = relate(g1, g2, de9im::mask("FT*******") ||
>>>                           de9im::mask("F**T*****") ||
>>>                           de9im::mask("F***T****"));
>>>
>>> Compile-time masks:
>>>
>>> typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
>>> bool res = relate<II>(g1, g2);
>>>
>>> or just
>>>
>>> bool res = relate(g1, g2, II());
>>>
>>> In the second case the same technique for ORing masks could be used. Otherwise we'd be forced to gather them in some type like, de9im::or<M1, M2, M3, M4, ...>, mpl::vector<> or boost::tuple<>. Either way the compiler should be able to optimize I think. Besides it's implemented like this anyway in the details. The third parameter is just created by default using the default ctor. This of course can be changed. So again, we have two options:
>>>
>>> typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
>>> typedef de9im::static_mask<'*','*','*','*','T','*','*','*','*'> BB;
>>> bool res = relate<de9im::or<II, BB>>(g1, g2);
>>>
>>> or
>>>
>>> de9im::static_mask<'T','*','*','*','*','*','*','*','*'> ii;
>>> de9im::static_mask<'*','*','*','*','T','*','*','*','*'> bb;
>>>
>>> bool res = relate(g1, g2, ii || bb);
>>>
>>> What do you think?
>>> Do you like the names?
>>> Any ideas are welcome.
>>>
>>> E.g. maybe the names should be:
>>> - de9im::dynamic_mask and de9im::mask (instead of static_mask)
>>> - de9im::dmask and de9im::smask
>>> - de9im::mask_d and de9im::mask_s
>>> - ?
>>>
>>> Regards,
>>> Adam
>
>
>
> _______________________________________________
> Geometry mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/geometry
>


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: relate() interface

Andrew Hundt
Is there an explanation of what DE9IM is somewhere?


Cheers!
Andrew Hundt

On Tue, Apr 28, 2015 at 12:07 PM, Mats Taraldsvik <[hidden email]> wrote:

Hi Adam,

On Apr 28, 2015 1:41 PM, "Adam Wulkiewicz" <[hidden email]> wrote:
>
> Hi Mats,
>
> Mats Taraldsvik wrote:
>>
>> Hi,
>>
>> On Tue, Apr 28, 2015 at 1:47 AM, Adam Wulkiewicz <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> Recently a user requested to add a user-defined spatial predicate:
>>> https://svn.boost.org/trac/boost/ticket/11232
>>> relate() is there in the details from quite some time so I thought it's a good time to make it official. But before that we should think about the interface.
>>>
>>> First, the requirements. I think it should be possible to:
>>> - return a DE9IM matrix
>>> - check DE9IM run-time mask
>>> - check DE9IM compile-time mask
>>> - pass ORed masks and use them directly in the check
>>> - possible addition of other IMs though I doubt that anything else than DE9IM will be supported
>>>
>>> FYI, all of the above is supported in the details. But the interface need to be polished. I'm thinking about something like this:
>>>
>>> // basic, return DE9IM matrix
>>> std::string matrix = relate(g1, g2);
>>
>>
>> What about using std::bitset? It has a constexpr constructor and can convert to/from a std::string (with custom characters indicating true / false). No dynamic allocations necessary :)
>>
>> http://en.cppreference.com/w/cpp/utility/bitset
>>
>> Binary logic is also supported out of the box.
>
>
> Unfortunately a matrix or a mask should be able to contain at least 5 different "digits" (*, T, F, 1, 2). See: http://en.wikipedia.org/wiki/DE-9IM
> Other dimensions could be there too so effectively there could be 12 or 13 "digits". They're not in the standard but this way we'd support n-dimensional non-standard geometries like Point, Box or N-sphere.
>
> But AFAIU your point is that you'd prefer to store the matrix or mask in a static memory. The most simple thing would be to have char[9]. And this is how it's done internally. Of course we could think about compressing it somehow in the future.
> Those two the most basic variants was proposed only for users convenience. But maybe indeed more clear would be to force the users to always use the matrix representation from de9im namespace:
>
> de9im::matrix m = relate(g1, g2);
>
>
> ?
>

Ok, I understand. Yes, I think that exposing the de9im type directly is better.

>>  
>>>
>>>
>>> // basic, check DE9IM run-time mask
>>> bool res = relate(g1, g2, "T********");
>
>
> this one could look the same or we could always require the creation of the de9im::mask explicitly so:
>
> bool res = relate(g1, g2, de9im::mask("T********"));
>
>
>>>
>>> We need a way to pass ORed masks. We have a few options but I'm thinking about this:
>>>
>>> bool res = relate(g1, g2, de9im::mask("FT*******") ||
>>>                           de9im::mask("F**T*****") ||
>>>                           de9im::mask("F***T****"));
>>>
>>> Compile-time masks:
>>>
>>> typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
>>> bool res = relate<II>(g1, g2);
>>>
>>> or just
>>>
>>> bool res = relate(g1, g2, II());
>>>
>>> In the second case the same technique for ORing masks could be used. Otherwise we'd be forced to gather them in some type like, de9im::or<M1, M2, M3, M4, ...>, mpl::vector<> or boost::tuple<>. Either way the compiler should be able to optimize I think. Besides it's implemented like this anyway in the details. The third parameter is just created by default using the default ctor. This of course can be changed. So again, we have two options:
>>>
>>> typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
>>> typedef de9im::static_mask<'*','*','*','*','T','*','*','*','*'> BB;
>>> bool res = relate<de9im::or<II, BB>>(g1, g2);
>>>
>>> or
>>>
>>> de9im::static_mask<'T','*','*','*','*','*','*','*','*'> ii;
>>> de9im::static_mask<'*','*','*','*','T','*','*','*','*'> bb;
>>>
>>> bool res = relate(g1, g2, ii || bb);
>>>
>>> What do you think?
>>> Do you like the names?
>>> Any ideas are welcome.
>>>
>>> E.g. maybe the names should be:
>>> - de9im::dynamic_mask and de9im::mask (instead of static_mask)
>>> - de9im::dmask and de9im::smask
>>> - de9im::mask_d and de9im::mask_s
>>> - ?
>>>
>>> Regards,
>>> Adam
>
>
>
> _______________________________________________
> Geometry mailing list
> [hidden email]
> http://lists.boost.org/mailman/listinfo.cgi/geometry
>


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry



_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: relate() interface

Barend
Hi Andrew,

Andrew Hundt schreef op 28-4-2015 om 18:08:
Is there an explanation of what DE9IM is somewhere?

Sure, that was in the post you replied to ;-)


>
>
> Unfortunately a matrix or a mask should be able to contain at least 5 different "digits" (*, T, F, 1, 2). See: http://en.wikipedia.org/wiki/DE-9IM



Regards, Barend


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: relate() interface

Andrew Hundt

Is there an explanation of what DE9IM is somewhere?
Sure, that was in the post you replied to ;-)


> Unfortunately a matrix or a mask should be able to contain at least 5 different "digits" (*, T, F, 1, 2). See: http://en.wikipedia.org/wiki/DE-9IM



Missed it, thanks!

Cheers!
Andrew Hundt 


_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: relate() interface

Adam Wulkiewicz
In reply to this post by Mats Taraldsvik-2
Hi,

2015-04-28 18:07 GMT+02:00 Mats Taraldsvik <[hidden email]>:

On Apr 28, 2015 1:41 PM, "Adam Wulkiewicz" <[hidden email]> wrote:
>
>
> Mats Taraldsvik wrote:
>>
>> Hi,
>>
>> On Tue, Apr 28, 2015 at 1:47 AM, Adam Wulkiewicz <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> Recently a user requested to add a user-defined spatial predicate:
>>> https://svn.boost.org/trac/boost/ticket/11232
>>> relate() is there in the details from quite some time so I thought it's a good time to make it official. But before that we should think about the interface.
>>>
>>> First, the requirements. I think it should be possible to:
>>> - return a DE9IM matrix
>>> - check DE9IM run-time mask
>>> - check DE9IM compile-time mask
>>> - pass ORed masks and use them directly in the check
>>> - possible addition of other IMs though I doubt that anything else than DE9IM will be supported
>>>
>>> FYI, all of the above is supported in the details. But the interface need to be polished. I'm thinking about something like this:
>>>

>>> // basic, return DE9IM matrix
>>> std::string matrix = relate(g1, g2);
>>
>>
>> What about using std::bitset? It has a constexpr constructor and can convert to/from a std::string (with custom characters indicating true / false). No dynamic allocations necessary :)
>>
>> http://en.cppreference.com/w/cpp/utility/bitset
>>
>> Binary logic is also supported out of the box.
>
>
> Unfortunately a matrix or a mask should be able to contain at least 5 different "digits" (*, T, F, 1, 2). See: http://en.wikipedia.org/wiki/DE-9IM
> Other dimensions could be there too so effectively there could be 12 or 13 "digits". They're not in the standard but this way we'd support n-dimensional non-standard geometries like Point, Box or N-sphere.
>
> But AFAIU your point is that you'd prefer to store the matrix or mask in a static memory. The most simple thing would be to have char[9]. And this is how it's done internally. Of course we could think about compressing it somehow in the future.
> Those two the most basic variants was proposed only for users convenience. But maybe indeed more clear would be to force the users to always use the matrix representation from de9im namespace:
>
> de9im::matrix m = relate(g1, g2);
>
>
> ?
>

Ok, I understand. Yes, I think that exposing the de9im type directly is better.


I decided to implement it as a separate function:

de9im::matrix m = relation(g1, g2);
 
This way it's more clear that the purpose of the function is different. Two use-cases aren't mixed. Furthermore this way it should be simpler to add more parameters, e.g. Strategy in the future.

If there were other matrices added in the future the use case could look like this:

de4im::matrix m = relation<de4im>(g1, g2);

It's probable that the above call would be faster since less matrix elements would be calculated.

>>  
>>>
>>>
>>> // basic, check DE9IM run-time mask
>>> bool res = relate(g1, g2, "T********");
>

I haven't implement this yet. It could be added if needed.
 
>
> this one could look the same or we could always require the creation of the de9im::mask explicitly so:
>
> bool res = relate(g1, g2, de9im::mask("T********"));
>

So this is required now.
 
>
>>>
>>> We need a way to pass ORed masks. We have a few options but I'm thinking about this:
>>>
>>> bool res = relate(g1, g2, de9im::mask("FT*******") ||
>>>                           de9im::mask("F**T*****") ||
>>>                           de9im::mask("F***T****"));
>>>
>>> Compile-time masks:
>>>
>>> typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
>>> bool res = relate<II>(g1, g2);
>>>
>>> or just
>>>
>>> bool res = relate(g1, g2, II());
>>>
>>> In the second case the same technique for ORing masks could be used. Otherwise we'd be forced to gather them in some type like, de9im::or<M1, M2, M3, M4, ...>, mpl::vector<> or boost::tuple<>. Either way the compiler should be able to optimize I think. Besides it's implemented like this anyway in the details. The third parameter is just created by default using the default ctor. This of course can be changed. So again, we have two options:
>>>
>>> typedef de9im::static_mask<'T','*','*','*','*','*','*','*','*'> II;
>>> typedef de9im::static_mask<'*','*','*','*','T','*','*','*','*'> BB;
>>> bool res = relate<de9im::or<II, BB>>(g1, g2);
>>>
>>> or
>>>
>>> de9im::static_mask<'T','*','*','*','*','*','*','*','*'> ii;
>>> de9im::static_mask<'*','*','*','*','T','*','*','*','*'> bb;
>>>
>>> bool res = relate(g1, g2, ii || bb);

This is unchanged.
Actually using the operator|| for static_masks is required. The compiler should optimize the code as if ORed masks type was created explicitly.

Regards,
Adam

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Loading...