Re: regarding location of Matlab compatible polygon functions

[Philip Nienhuis]

Carnë Draug wrote:
> On 25 March 2016 at 17:14, Philip Nienhuis <address@hidden> wrote:
> > Carnë Draug 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.
> >
> >      ? "...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?
>
> This is not a Matlab compatibility issue.  We are already not compatible
> because we require the user to load the package.  Following the same structure
> as Matlab when it comes for this packages means we have one less thing
> to worry about.
>
> Consider:
>
> At the moment we have a geometry package.  The argument then goes that these
> functions should go in geometry.  But if we didn't had geometry they would
> happily go into mapping.

Seems I fail to see the obvious. Why would they "obviously" go into 
"mapping" then (and why "happily")?  Maybe what you describe would have 
rather been a nice occasion to create a geometry package. Or a polygon 
package, who knows.

A situation like that exists now and is called the "octclip" package. 
That might also be a nice home for more polygon operations - but 
geometry is better IMO.


>                          Let's imagine that in 1-2 years we create the
> polygons package.  If the decision is that functions go in the most logical
> package by name, we will want want to move those functions to polygons.
> However, that would break code that was only loading geometry so we shouldn't
> do it.  And then functions end up again in a non-optimally named package and
> users will be confused (by the way, I disagree with the premise that new users
> will be confused.  I think they are capable enough to find the right package
> for a function).

"...capable enough..." wouldn't that equally hold for Matlab users? 
Wouldn't they be able to find the right OF package?


> Point is it can always be made a case for moving a function to a package with
> a more specific name.

We're not discussing package names.
We are discussing moving function "F" to either:
- some package "A" that from functionality point of view would be a 
natural home (IMO), or
- moving "F" to some other package "B", only because Matlab's toolbox 
"B" happens to contain "F".

IOW functionality that for non-Matlab users looks obviously similar 
should be dispersed over two or maybe more packages only/mainly for the 
sake of Matlab user experience.

Come on...

> In another case, it can be argueed that while method "foo" is very useful in
> field X, it is also useful in field Y.  Should we then move the function or
> create a package only for a function that implements foo?  Will we end with
> packages with a single function that are named isarray [1]?
>
> Following this rule for this set of functions means one less thing to discuss.
> And while Mathworks places a few functions in some really odd places, in
> general they are logical.  At the same time, it also matches the place where
> Matlab users would expect them.

"...Matlab users would expect..." seems to be the core of your 
argumentation.

How about Scilab user's expectations when they start using Octave? 
Python user's expectations? Calerga Sysquake user's expectations? Or 
those of R users? Sage? MathCad?

I do not care quite as much as you about Matlab user's expectations 
beyond "Matlab code should run in Octave with minimal and preferrably no 
adaptation".
My perception is that you equate, or extend, "Matlab compatibility" to 
"Matlab user expectation". Again in my perception, those are two quite 
separate beasts.


Then the other issue:
Was Octave created to be a Matlab clone, gratis or not?

When I show the Octave GUI to colleagues who otherwise use Matlab, many 
of them react with "... all pirated from Matlab...". That hurts; yet I 
know it is just about cosmetics.
But extending that sort of snooping to division of functions over 
toolboxes/packages based only on toolbox names and ignoring the logic 
and functionality itself, hurts me more.


But .... there is a solution.
For this special case at hand here I have an alternative and perhaps 
much better proposal:

Why don't we simply rename the mapping package into "cartography" 
package? Problem solved: no more undue Matlab user's expectations.

Thoughts ?

Philip