Re: regarding GSoC 2016

[Juan Pablo Carbajal]

On Fri, Mar 25, 2016 at 6:14 PM, Philip Nienhuis <address@hidden> wrote:
> Carnë Draug wrote:
>>
>> On 25 March 2016 at 07:57, PhilipNienhuis <address@hidden> 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;
>>>
>>>
>>>> address@hidden
>>>
>>>
>>>> &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.