On Sun, Apr 10, 2016 at 6:22 PM, Philip Nienhuis <address@hidden> wrote:
I think that the person who did all the work should have a strong say in where it goes(If they want to have a position on where it goes).Your first argument ("Matlab ... good enough") is, well, a good opinion.Carnë Draug wrote:
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.
But that second argument, "one less thing to argue about", can also be perceived as a way to simply evade discussion.
Extending that a little, what's the whole point of Octave when "Matlab is good enough" ? If all of us here just stop with Octave we'd be free of any arguing whatsoever.
The outcome is of course that many people here think that Matlab could be done better. That "better" can manifest itself in many ways. The aAbility "to do better" is one of the beauties of OSS as well.
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.
No you got me wrong.
Those last six words should be replaced by: "... in a package with matching and more extensive similar functionality".
That, and behind it "non-Matlab users would expect" plus "Octave can do better", is my main reasoning.
That is the case of the functions for polygon operations
and you wanting to have them in geometry.
Yes, Matlab doesn't have a dedicated geometry toolbox. TMW's alternative solution was to dump some polygon functions in the mapping toolbox where they apparently were needed for the first time. Legacy and lock-in did the rest.
Octave does have an alternative solution that I find better: group boolean polygon functions with other polygon functions that already do have a good home. Or would you think the geometry package should rather be cannibalized and absorbed in e.g., the mapping package "because Matlab has it that way and that is good enough"?
BTW, the roundn.m function in mapping is also a fine example of a function that doesn't have an exclusive relation with mapping s.s.
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:
Again, with "natural home" I was not referring to package nomenclature; I was referring to similar functionality already existing in some other dedicated package.
The problem with this is that it is based on opinion.
I found it a "problem" that an arbitrary choice/directive was made, so I challenged it. The result of the ensuing discussion is reasoning that can be weighed: "~ Matlab's way is good enough" and "Matlab users expect ..." (those are the main ones I distilled from your side).
Well, I can understand, appreciate and value those (really). But I weigh them differently than you.
As to the dependencies argument (that I did mention in passing but didn't bother to bring up as it works both ways, see a.o., JuanPi's earlier post):
Matlab has self-contained but often huge toolboxes. For obvious reasons, as you can't expect customers to pay up for some toolbox and then on top of that pay up again for dependency toolboxes.
Octave isn't plagued by commercial business models. I think that is a big benefit of, and for, OSS, because it allows small and dedicated toolboxes/packages that can be maintained by one or only a few volunteers. Small and dedicated packages also help keeping the namespace within reasonable limits.
The resulting unavoidable dependencies[1] are only a nuisance (and then mainly for novice Octave users) because pkg.m has remained to be such a relatively primitive tool to date. See a.o., bug #47405 for one of the consequential issues. "apt-get"-like functionality of pkg.m is yet a dream, but not quite impossible.
[1] and for that matter, shadowing
<snip>
I'm not interested
in arguing which package is better for any function.
Good, let's stop here.
My suggestion:
Let the involved package maintainers sort out & decide where to put the new polygon functions. It appears both JuanPi and I already agree. The octclip maintainer is welcome to jump in as far as I am concerned.
Philip