regarding GSoC 2016

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

regarding GSoC 2016

Neeraj Battan
KaKila: Hi, thanks for having a look at my proposal. Can you please tell me which are the core projects?

Reply | Threaded
Open this post in threaded view
|

Re: regarding GSoC 2016

Juan Pablo Carbajal-2
On Thu, Mar 24, 2016 at 12:54 PM, Neeraj Battan
<[hidden email]> wrote:
> KaKila: Hi, thanks for having a look at my proposal. Can you please tell me which are the core projects?
>

Everything that doesn't say "Package" is most likely core. Exception
is in "Infracstructure" the package manager.
With your profile I would also consider that project.

Reply | Threaded
Open this post in threaded view
|

Re: regarding GSoC 2016

Carnë Draug
On 24 March 2016 at 12:05, Juan Pablo Carbajal <[hidden email]> wrote:

> On Thu, Mar 24, 2016 at 12:54 PM, Neeraj Battan
> <[hidden email]> wrote:
>> KaKila: Hi, thanks for having a look at my proposal. Can you please tell
>> me which are the core projects?
>>
>
> Everything that doesn't say "Package" is most likely core. Exception
> is in "Infracstructure" the package manager.
> With your profile I would also consider that project.
>

The projects page should be cleared up then.  The logical operations on
polygons are listed under missing core functions but would actually go
into the mapping package.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: regarding GSoC 2016

PhilipNienhuis
Carnë Draug wrote
On 24 March 2016 at 12:05, Juan Pablo Carbajal <[hidden email]> wrote:
> On Thu, Mar 24, 2016 at 12:54 PM, Neeraj Battan
> <[hidden email]> wrote:
>> KaKila: Hi, thanks for having a look at my proposal. Can you please tell
>> me which are the core projects?
>>
>
> Everything that doesn't say "Package" is most likely core. Exception
> is in "Infracstructure" the package manager.
> With your profile I would also consider that project.
>

The projects page should be cleared up then.  The logical operations on
polygons are listed under missing core functions but would actually go
into the mapping package.
IMO they better fit in the geometry package. That already contains several functions that operate on polygons.
Until recently oc_polybool() actually was in there, it was removed (as JuanPi told me) because its author wanted so (it's now in octclip).

Philip
Reply | Threaded
Open this post in threaded view
|

Re: regarding GSoC 2016

Carnë Draug
On 25 March 2016 at 07:57, PhilipNienhuis <[hidden email]> wrote:

> Carnë Draug wrote
>> On 24 March 2016 at 12:05, Juan Pablo Carbajal &lt;
>
>> ajuanpi+dev@
>
>> &gt; wrote:
>>> On Thu, Mar 24, 2016 at 12:54 PM, Neeraj Battan
>>> &lt;
>
>> neeraj.battan@.ac
>
>> &gt; wrote:
>>>> KaKila: Hi, thanks for having a look at my proposal. Can you please tell
>>>> me which are the core projects?
>>>>
>>>
>>> Everything that doesn't say "Package" is most likely core. Exception
>>> is in "Infracstructure" the package manager.
>>> With your profile I would also consider that project.
>>>
>>
>> The projects page should be cleared up then.  The logical operations on
>> polygons are listed under missing core functions but would actually go
>> into the mapping package.
>
> IMO they better fit in the geometry package. That already contains several
> functions that operate on polygons.
> Until recently oc_polybool() actually was in there, it was removed (as
> JuanPi told me) because its author wanted so (it's now in octclip).
>
> Philip

The functions proposed on the projects page are polybool, ispolycw, poly2ccw,
poly2cw, poly2fv, polyjoin, and polysplit.  They all belong to the Matlab
mapping toolbox therefore would go into the Octave mapping package.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: regarding GSoC 2016

Nir Krakauer-2
In reply to this post by PhilipNienhuis

> The functions proposed on the projects page are polybool, ispolycw, poly2ccw,
> poly2cw, poly2fv, polyjoin, and polysplit.  They all belong to the Matlab
> mapping toolbox therefore would go into the Octave mapping package.

> Carnë


Thanks for the clarification, I rearranged the project page in the Wiki accordingly.
Reply | Threaded
Open this post in threaded view
|

Re: regarding GSoC 2016

John Swensen-3

On Mar 25, 2016, at 5:36 AM, Nir Krakauer <[hidden email]> wrote:


> The functions proposed on the projects page are polybool, ispolycw, poly2ccw,
> poly2cw, poly2fv, polyjoin, and polysplit.  They all belong to the Matlab
> mapping toolbox therefore would go into the Octave mapping package.

> Carnë


Thanks for the clarification, I rearranged the project page in the Wiki accordingly.

Sorry about that. It was my fault. For some reason I though those functions were in the core of Matlab, not in one of the toolboxes.


Reply | Threaded
Open this post in threaded view
|

Re: regarding GSoC 2016

PhilipNienhuis
In reply to this post by Carnë Draug
Carnë Draug wrote:

> On 25 March 2016 at 07:57, PhilipNienhuis <[hidden email]> wrote:
>> Carnë Draug wrote
>>> On 24 March 2016 at 12:05, Juan Pablo Carbajal &lt;
>>
>>> ajuanpi+dev@
>>
>>> &gt; wrote:
>>>> On Thu, Mar 24, 2016 at 12:54 PM, Neeraj Battan
>>>> &lt;
>>
>>> neeraj.battan@.ac
>>
>>> &gt; wrote:
>>>>> KaKila: Hi, thanks for having a look at my proposal. Can you please tell
>>>>> me which are the core projects?
>>>>>
>>>>
>>>> Everything that doesn't say "Package" is most likely core. Exception
>>>> is in "Infracstructure" the package manager.
>>>> With your profile I would also consider that project.
>>>>
>>>
>>> The projects page should be cleared up then.  The logical operations on
>>> polygons are listed under missing core functions but would actually go
>>> into the mapping package.
>>
>> IMO they better fit in the geometry package. That already contains several
>> functions that operate on polygons.
>> Until recently oc_polybool() actually was in there, it was removed (as
>> JuanPi told me) because its author wanted so (it's now in octclip).
>>
>> Philip
>
> The functions proposed on the projects page are polybool, ispolycw, poly2ccw,
> poly2cw, poly2fv, polyjoin, and polysplit.  They all belong to the Matlab
> mapping toolbox therefore would go into the Octave mapping package.

     ? "...Matlab ... therefore..." ?

That "therefore" comes a little quick for me.

Until now I'm only sure that Octave strives to be Matlab-compatible in
the sense of being able to run Matlab code. Good!
But when did who decide that Octave should mimic Matlab beyond code
compatibility and also copy less handy aspects? IOW, where is the basis
for "... therefore..."?

My motive is simply this:
I find it much more natural to have functions sorted and divided into
add-on packages according to what they do, rather then where they happen
to be located in some commercial product that is required to keep a
sometimes clumsy legacy around just because of its business model.

New Octave users, not coming from Matlab, would expect functions
operating on points, lines and polygons to be grouped together, and not
scattered over separate "toolboxes" / add-on packages.
Matlab users OTOH would quickly enough get used to "other" function
locations. After all, Octave's "toolboxes" have no price tag hence no
obstacle for installation AFAICS.

Octave's mapping toolbox already has a (suggested) dependency on the
geometry package for other functions than polygon operations.

It's not that I'm pertinently against polygon operation functions in the
mapping package. My motive is just what I wrote above.

But I feel that the "decision", or lack of clear decision, about how far
Octave should go to become a verbatim Matlab clone and thus also follow
less logical/natural TMW decisions, is very implicitly made.  If the
majority agrees, OK, then I'll shut up on this subject.

Thoughts?

Philip


Reply | Threaded
Open this post in threaded view
|

Re: regarding GSoC 2016

Juan Pablo Carbajal-2
On Fri, Mar 25, 2016 at 6:14 PM, Philip Nienhuis <[hidden email]> wrote:

> Carnë Draug wrote:
>>
>> On 25 March 2016 at 07:57, PhilipNienhuis <[hidden email]> wrote:
>>>
>>> Carnë Draug wrote
>>>>
>>>> On 24 March 2016 at 12:05, Juan Pablo Carbajal &lt;
>>>
>>>
>>>> ajuanpi+dev@
>>>
>>>
>>>> &gt; wrote:
>>>>>
>>>>> On Thu, Mar 24, 2016 at 12:54 PM, Neeraj Battan
>>>>> &lt;
>>>
>>>
>>>> neeraj.battan@.ac
>>>
>>>
>>>> &gt; wrote:
>>>>>>
>>>>>> KaKila: Hi, thanks for having a look at my proposal. Can you please
>>>>>> tell
>>>>>> me which are the core projects?
>>>>>>
>>>>>
>>>>> Everything that doesn't say "Package" is most likely core. Exception
>>>>> is in "Infracstructure" the package manager.
>>>>> With your profile I would also consider that project.
>>>>>
>>>>
>>>> The projects page should be cleared up then.  The logical operations on
>>>> polygons are listed under missing core functions but would actually go
>>>> into the mapping package.
>>>
>>>
>>> IMO they better fit in the geometry package. That already contains
>>> several
>>> functions that operate on polygons.
>>> Until recently oc_polybool() actually was in there, it was removed (as
>>> JuanPi told me) because its author wanted so (it's now in octclip).
>>>
>>> Philip
>>
>>
>> The functions proposed on the projects page are polybool, ispolycw,
>> poly2ccw,
>> poly2cw, poly2fv, polyjoin, and polysplit.  They all belong to the Matlab
>> mapping toolbox therefore would go into the Octave mapping package.
>
>
>     ? "...Matlab ... therefore..." ?
>
> That "therefore" comes a little quick for me.
>
> Until now I'm only sure that Octave strives to be Matlab-compatible in the
> sense of being able to run Matlab code. Good!
> But when did who decide that Octave should mimic Matlab beyond code
> compatibility and also copy less handy aspects? IOW, where is the basis for
> "... therefore..."?
>
> My motive is simply this:
> I find it much more natural to have functions sorted and divided into add-on
> packages according to what they do, rather then where they happen to be
> located in some commercial product that is required to keep a sometimes
> clumsy legacy around just because of its business model.
>
> New Octave users, not coming from Matlab, would expect functions operating
> on points, lines and polygons to be grouped together, and not scattered over
> separate "toolboxes" / add-on packages.
> Matlab users OTOH would quickly enough get used to "other" function
> locations. After all, Octave's "toolboxes" have no price tag hence no
> obstacle for installation AFAICS.
>
> Octave's mapping toolbox already has a (suggested) dependency on the
> geometry package for other functions than polygon operations.
>
> It's not that I'm pertinently against polygon operation functions in the
> mapping package. My motive is just what I wrote above.
>
> But I feel that the "decision", or lack of clear decision, about how far
> Octave should go to become a verbatim Matlab clone and thus also follow less
> logical/natural TMW decisions, is very implicitly made.  If the majority
> agrees, OK, then I'll shut up on this subject.
>
> Thoughts?
>
> Philip
>
>
I share Philip's views on this. But of course when a matlab user
writes code that says "load mapping" (or whatever they do) I guess
compatibility would mean that code runs in octave as well... well... I
understand and like that we do not want to change algorithms written
for matlab because we do not match the functions and interfaces, but I
do not see how changing a single line (which as no code dependencies)
can be such a hassle.