what is an algorithm

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

what is an algorithm

Barend Gehrels
Hi,

Now we've update the structure, I was thinking about the algorithm
folder. To crowded or fine? It is sometimes hard to decide what is what.
Is "loop" an algorithm? Now in util.

OGC distinguishes algorithms:
- "query" contains within, touches, overlaps, disjoint, etc. This makes
sense to me
- "analysis" contains distance, buffer, ConvexHull, intersection, union.
This is also useful, there are two kinds:
    -  pointset spatial relationships (and, or, xor, not -->
intersection, union, sym_difference)
    - other things as distance and buffer
- other, uncategorized such as envelope, dimension


GGL:
I've put some in core (e.g. topological_dimension, because it is
completely compiletime), some in util (loop) and most in algorithms.

Besides OGC algorithms we have and get more:
- simplify
- spline
- diameter (defined by the most furthest point-pair of a polygon,
linestring, etc)
- closest_pair (idem but most closest point-pair)
- combine  a bounding box growing if points are added)
- etc.

The easiest is to have them all in one folder algorithms, users then
don't have to think about what kind it is. Do you agree with that? The
folder will have dozens of files, but that is how it is, the boost/mpl
folder contains 182 files.

I'm using the GGL more and more in projects and have several pieces in
different states which will go there, coming time. As mentioned earlier:
touches, relate, disjoint, buffer, union but also diameter (see above),
remove_indentations, remove_small_holes (this last one should be
templatized by a selection struct), ...

Regards, Barend




Reply | Threaded
Open this post in threaded view
|

what is an algorithm

Mateusz Loskot
Administrator
Barend Gehrels wrote:
> Now we've update the structure, I was thinking about the algorithm
> folder. To crowded or fine?

A little :-) and there is potential it will get crowded in future.

> It is sometimes hard to decide what is what.

For some of them it is not enough to decide their place based on
algorithm defined as a procedure provided to operate on GGL
data and types.

Second issue is to help users to recognize algorithms
easier by proper structure of folders.

> Is "loop" an algorithm? Now in util.

It's unclear to me how it's different to for_each.

> OGC distinguishes algorithms:
> - "query" contains within, touches, overlaps, disjoint, etc. This makes
> sense to me

Aren't they called spatial predicates or just predicates?
They return binary answer, so perhaps "predicate" is a good name for
directory. Predicate is used in C++ std library terminology.

> - "analysis" contains distance, buffer, ConvexHull, intersection, union.

Right.

> This is also useful, there are two kinds:
>    -  pointset spatial relationships (and, or, xor, not -->
> intersection, union, sym_difference)
>    - other things as distance and buffer
> - other, uncategorized such as envelope, dimension

All of them here and above are geometry algorithms - this could be
an indicator for selecting how to structure them.

> GGL:
> I've put some in core (e.g. topological_dimension, because it is
> completely compiletime), some in util (loop) and most in algorithms.

for_each is also a general purpose algorithm, similar to loop.

> Besides OGC algorithms we have and get more:
> - simplify
> - spline
> - diameter (defined by the most furthest point-pair of a polygon,
> linestring, etc)
> - closest_pair (idem but most closest point-pair)
> - combine  a bounding box growing if points are added)
> - etc.
>
> The easiest is to have them all in one folder algorithms, users then
> don't have to think about what kind it is. Do you agree with that? The
> folder will have dozens of files, but that is how it is, the boost/mpl
> folder contains 182 files.

It would be good to have it scattered in some categories, but on the
other hand if categories are not obvious (or natural), then possible
structure may be ambiguous to users.
Looks like this is an issue in GGL, so I like the idea of single
collection of files as you are suggesting.
Or, may be a few obvious categories could be identified like
OGC algorithms. This way GIS-oriented users could easily identify
where to look for what they need.

> I'm using the GGL more and more in projects and have several pieces in
> different states which will go there, coming time. As mentioned earlier:
> touches, relate, disjoint, buffer, union but also diameter (see above),
> remove_indentations, remove_small_holes (this last one should be
> templatized by a selection struct), ...

Great.
I'm still familiarizing with GGL, but next I'd like to get into WKB IO.
What you think?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

what is an algorithm

Barend Gehrels


Mateusz Loskot wrote:

> Barend Gehrels wrote:
>  
>> Now we've update the structure, I was thinking about the algorithm
>> folder. To crowded or fine?
>>    
>
> A little :-) and there is potential it will get crowded in future.
>
>  
>> It is sometimes hard to decide what is what.
>>    
>
> For some of them it is not enough to decide their place based on
> algorithm defined as a procedure provided to operate on GGL
> data and types.
>
> Second issue is to help users to recognize algorithms
> easier by proper structure of folders.
>
>  
>> Is "loop" an algorithm? Now in util.
>>    
>
> It's unclear to me how it's different to for_each.
>  
Sure, I was not clear enough. I didn't explain that for me also the
util/loop was strange. It used to be a sort of helper-algorithm and
therefore it was there. But it is about the same as for_each. Only
difference is that it can break out.
The loop was one of the first developed, being used in algorithms as
within, area etc. However, it makes them also more complex and I know
prefer using iterators.

>  
>> OGC distinguishes algorithms:
>> - "query" contains within, touches, overlaps, disjoint, etc. This makes
>> sense to me
>>    
>
> Aren't they called spatial predicates or just predicates?
> They return binary answer, so perhaps "predicate" is a good name for
> directory. Predicate is used in C++ std library terminology.
>  
Good idea.

>  
>> - "analysis" contains distance, buffer, ConvexHull, intersection, union.
>>    
>
> Right.
>
>  
>> This is also useful, there are two kinds:
>>    -  pointset spatial relationships (and, or, xor, not -->
>> intersection, union, sym_difference)
>>    - other things as distance and buffer
>> - other, uncategorized such as envelope, dimension
>>    
>
> All of them here and above are geometry algorithms - this could be
> an indicator for selecting how to structure them
>  
>  
>> GGL:
>> I've put some in core (e.g. topological_dimension, because it is
>> completely compiletime), some in util (loop) and most in algorithms.
>>    
>
> for_each is also a general purpose algorithm, similar to loop.
>  
Sure.

>  
>> Besides OGC algorithms we have and get more:
>> - simplify
>> - spline
>> - diameter (defined by the most furthest point-pair of a polygon,
>> linestring, etc)
>> - closest_pair (idem but most closest point-pair)
>> - combine  a bounding box growing if points are added)
>> - etc.
>>
>> The easiest is to have them all in one folder algorithms, users then
>> don't have to think about what kind it is. Do you agree with that? The
>> folder will have dozens of files, but that is how it is, the boost/mpl
>> folder contains 182 files.
>>    
>
> It would be good to have it scattered in some categories, but on the
> other hand if categories are not obvious (or natural), then possible
> structure may be ambiguous to users.
> Looks like this is an issue in GGL, so I like the idea of single
> collection of files as you are suggesting.
> Or, may be a few obvious categories could be identified like
> OGC algorithms. This way GIS-oriented users could easily identify
> where to look for what they need.
>  
I've thought about that also but the Boost folks are not that interested
in OGC. They just want geometry and things handling geometry. Creating
an OGC distinction is for GIS users maybe natural and handy, but other
users (who still want e.g. "distance") will look very strange at that.
Besides that many non-OGC things (as simplify) are great for GIS users
as well.

So I'm currently still favouring creating one folder. Bruno?

>  
>> I'm using the GGL more and more in projects and have several pieces in
>> different states which will go there, coming time. As mentioned earlier:
>> touches, relate, disjoint, buffer, union but also diameter (see above),
>> remove_indentations, remove_small_holes (this last one should be
>> templatized by a selection struct), ...
>>    
>
> Great.
> I'm still familiarizing with GGL, but next I'd like to get into WKB IO.
> What you think?
>  
Would be great!

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090425/1914ca81/attachment-0001.html
Reply | Threaded
Open this post in threaded view
|

what is an algorithm

Mateusz Loskot
Administrator
Barend Gehrels wrote:

> Mateusz Loskot wrote:
>> Barend Gehrels wrote:
>>  
>>> Is "loop" an algorithm? Now in util.
>>>    
>>
>> It's unclear to me how it's different to for_each.
>  
> Sure, I was not clear enough. I didn't explain that for me also the
> util/loop was strange. It used to be a sort of helper-algorithm and
> therefore it was there. But it is about the same as for_each. Only
> difference is that it can break out.
> The loop was one of the first developed, being used in algorithms as
> within, area etc. However, it makes them also more complex and I know
> prefer using iterators.


I see. Thanks for giving some background.

>>> The easiest is to have them all in one folder algorithms, users then
>>> don't have to think about what kind it is. Do you agree with that? The
>>> folder will have dozens of files, but that is how it is, the boost/mpl
>>> folder contains 182 files.
>>>
>>
>> It would be good to have it scattered in some categories, but on the
>> other hand if categories are not obvious (or natural), then possible
>> structure may be ambiguous to users.
>> Looks like this is an issue in GGL, so I like the idea of single
>> collection of files as you are suggesting.
>> Or, may be a few obvious categories could be identified like
>> OGC algorithms. This way GIS-oriented users could easily identify
>> where to look for what they need.
>
> I've thought about that also but the Boost folks are not that interested
> in OGC. They just want geometry and things handling geometry. Creating
> an OGC distinction is for GIS users maybe natural and handy, but other
> users (who still want e.g. "distance") will look very strange at that.
> Besides that many non-OGC things (as simplify) are great for GIS users
> as well.

Your reasoning makes sense to me.

> So I'm currently still favouring creating one folder.

I support this idea.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

what is an algorithm

Bruno Lalande
In reply to this post by Barend Gehrels
Hi,

> I've thought about that also but the Boost folks are not that interested in
> OGC. They just want geometry and things handling geometry. Creating an OGC
> distinction is for GIS users maybe natural and handy, but other users (who
> still want e.g. "distance") will look very strange at that. Besides that
> many non-OGC things (as simplify) are great for GIS users as well.
>
> So I'm currently still favouring creating one folder. Bruno?

Yep, that's my opinion too. An OGC compliant classification would help
OGC users but would confuse non-OGC users. As long as there's no
obvious way to classify algorithms, I prefer to have them all in one
list. The list will be long but at least, easy to search.

Regards
Bruno
Reply | Threaded
Open this post in threaded view
|

what is an algorithm

Mateusz Loskot
Administrator
Bruno Lalande wrote:

> Hi,
>
>> I've thought about that also but the Boost folks are not that interested in
>> OGC. They just want geometry and things handling geometry. Creating an OGC
>> distinction is for GIS users maybe natural and handy, but other users (who
>> still want e.g. "distance") will look very strange at that. Besides that
>> many non-OGC things (as simplify) are great for GIS users as well.
>>
>> So I'm currently still favouring creating one folder. Bruno?
>
> Yep, that's my opinion too. An OGC compliant classification would help
> OGC users but would confuse non-OGC users. As long as there's no
> obvious way to classify algorithms, I prefer to have them all in one
> list. The list will be long but at least, easy to search.


+1

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
Mateusz Loskot
http://mateusz.loskot.net