Re: polygon function placement (was: regarding GSoC 2016)

[Nir Krakauer]

On Mar 25, 2016 6:19 PM, "Juan Pablo Carbajal" <address@hidden> wrote:
>
> 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.

I don't have a problem putting these functions in the Geometry package, especially if we can get think of use cases for them that are not related to mapping. If the Mapping package already has Geometry as a dependence, there would be no loss of compatibility. In general the rule has been that functions that are in MATLAB toolboxes go in Forge packages rather than core Octave, but we don't need a one-to-one correspondence between toolboxes and packages where another arrangement makes sense.