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