Re: regarding location of Matlab compatible polygon functions

[Carnë Draug]

On 8 April 2016 at 19:25, Philip Nienhuis <address@hidden> wrote:
> 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

No, you got my argument wrong.  The core of my argument is not that Matlab
users would expect this organization (that is just an extra).  My argument
is that Matlab organization is good enough and following it means one less
thing to argue about.

Starting from the beginning:  there is only one reason* to not have functions
in packages with the same organization as Matlab.  That reason is because
someone thinks that specific functions would fit better in a package with
another name.  That is the case of the functions for polygon operations
and you wanting to have them in geometry.

Fair enough, let us move all the functions to packages with a name that
represents their purpose better (or borrowing from your words, "natural
home").  These polygon functions are only the start:

  * Should removeExtraNanSeparators be moved to the NaN package?
  * Should extractfield be moved to the struct package?
  * Should psnr (image package) be moved to signal?
  * Should we have a morphological package that includes those operations
    from the image package?
  * Should the NaN and plotting specific functions in statistics be moved
    to the NaN and plots package?

The problem with this is that it is based on opinion.  You said
it yourself:

   "functionality point of view would be a natural home (IMO)"

note the "IMO".  And earlier on you said:

    "That [octclip] might also be a nice home for more polygon operations
     - but geometry is better IMO."

Again, you say "IMO".  This your opinion.  I don't want to be discussing
this (and by the way, I disagree, octclip is better IMO).  I'm not interested
in arguing which package is better for any function.

Now, let's step back.  What is the reason for placing functions in other
packages?  That is so that users can find the functions they need easily.
However, I think we both agree that users are capable enough to find the
functions themselves, whatever the package name.

Even if Mathworks does not group the functions the way you find better,
their organization is not completely outrageous.  We can use their rules,
which are good enough, or we can waste our time arguing where functions go.

Carnë

* I actually think there is one other reason which is to avoid dependencies.
But that obviously has not bothered you since you have not mentioned it yet
so let's not discuss it.  I'd still argue that avoiding a dependency is not a
reason to avoid this organization, and I'm only adding this note for
sake of completeness.