Re: GNU Octave has been accepted as a GSoC 2016 mentor organization

[Juan Pablo Carbajal]

On Tue, Mar 1, 2016 at 10:44 PM, John Swensen <address@hidden> wrote:
>
>> On Mar 1, 2016, at 6:35 AM, Juan Pablo Carbajal <address@hidden> wrote:
>>
>> On Tue, Mar 1, 2016 at 3:04 PM, John Swensen <address@hidden> wrote:
>>>
>>> On Feb 29, 2016, at 12:37 PM, Nir Krakauer <address@hidden> wrote:
>>>
>>>
>>> Please let me know if you're interested in helping evaluate applications and
>>> then mentor any accepted students.
>>>
>>> Student applications will be due March 14-25, see
>>> https://summerofcode.withgoogle.com
>>>
>>> —Nir
>>>
>>>
>>> I haven’t been involved in Octave development a ton lately, but would like
>>> to get more involved now that I am past the grad student/postdoc days and
>>> got a faculty job. I have recently done some work with a couple of different
>>> polygon libraries and think that implementing many of the polygon functions
>>> (e.g. polybool, poly2ccw, poly2cw, poly2fv, polyjoin, polysplit, etc.) and
>>> would be something I could mentor.
>>>
>>> It looks like there is a partial implementation as MEX function (though not
>>> in Octave package format) at
>>> https://sites.google.com/site/ulfgri/numerical/polybool that uses both
>>> ClipperLib and GPC. I think GPC
>>> (http://www.cs.man.ac.uk/~toby/gpc/#Licensing) is out of the question
>>> because of their "free for private/hobbyist/education and non-free for
>>> products/commercial" licensing. ClipperLib
>>> (http://www.angusj.com/delphi/clipper.php) used the Boost Software License.
>>> The Boost::Geometry (https://github.com/boostorg/geometry) and
>>> Boost::Polygon
>>> (http://www.boost.org/doc/libs/1_60_0/libs/polygon/doc/index.htm) libraries
>>> could also be used and are license-friendly.
>>>
>>> Unfortunately, based on my evaluation of all three of these, GPC is by far
>>> the most robust solution that can handle self intersections and nearly
>>> parallel lines very, very well, but is likely not license-compatible with
>>> Octave. ClipperLib is the easiest to use and Boost::Geometry is the most
>>> powerful (but a bit confusing because of how much templating is going on).
>>>
>>> Let me know if this sounds interesting and you want to add me to the list of
>>> potential mentors.
>>>
>>> John S.
>>>
>> John S.
>> It sounds like a good project. do you think it is possible to put it
>> as an improvement of the package geometry? There are some of the
>> functions already there, but as m-files, maybe we can .oct some of
>> those.
>>
>> Also Philip Nienhuis had some ideas about the clipping library that I
>> haven't had time to test.
>
> It definitely could be incorporated into the geometry package, as that seems 
> the most logical place to put it. However, I think we should have the student 
> aiming for the Matlab-compatible functions of polybool, ispolycw, poly2ccw, 
> poly2cw, poly2fv, polyjoin, and polysplit. These could either be implemented 
> used the various polygon function already existent in the Geometry package, 
> or could use one of the existing polygon libraries with an amenable license.
>
> John S.
>
>
>
Ok, I understand, these functions are already in matlab so the place
to put them is definitely in core in the package geometry there. No
need to mix it with the forge package geometry.