Hi.
On Sun, 14 May 2017 08:38:38 -0400, Raymond DeCampo wrote:
On Sat, May 13, 2017 at 9:33 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
Hello Ray.
On Sat, 13 May 2017 07:29:13 -0400, Raymond DeCampo wrote:
On Fri, May 12, 2017 at 6:49 PM, Gilles
<gil...@harfang.homelinux.org>
wrote:
On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote:
On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins
<chtom...@gmail.com>
wrote:
> On May 12, 2017, at 11:49 AM, Raymond DeCampo <r...@decampo.org>
wrote:
>
> I still think that we should leave geometric concepts out of
> commons-numbers.
Are we defining numbers using the fundamental theorem of
Algebra?
Maybe,
that’s what should go in core?
Clearly that would leave out the quaternions, matrices (which
have an
implicit geometrical bias), and other constructions out of
numbers from
the
Complex Field.
It's less about what the definition of "number" is and more
about
setting
some boundaries as to what belongs and what does not. Geometry
is a
convenient boundary in my eyes.
If PlaneAngle belongs in numbers, shouldn't Plane from CM also
belong?
And
if Plane is in, shouldn't Line be there? And so on and so on.
It's
tougher to draw the line (no pun intended) with PlaneAngle
included.
Matrices are not exclusively used in a geometric setting so I
don't see
a
problem there.
And the same goes for "angle". [I've a class that uses the method
"MathUtils.normalizeAngle" from "Commons Math" and nothing from
its
"o.a.c.m.geometry" package.]
The point is that matrices as a mathematical concept have utility
outside
of geometry not that a program might make use of them without using
o.a.c.m.geometry.
I don't quite follow.
My point is only that "angle" is used a lot without it being part
of a full-fledged geometry package.
My point is that an angle is always used in a geometrical context and
matrices are not. It's a very simple point.
[In CM, "normalizeAngle" is not in the package "geometry" simply
because of that common use. And IIRC there is no "Angle" class in
the "geometry" package... Here I'm not discussing whether it would
have been better to have it there...]
For such a simple and useful concept, it's unreasonable to wait for
the rethinking of the whole of the "geometry" package to happen...
What's the rush to add this to numbers if equivalent functionality
already
exists in java.lang.Math and CM MathUtils?
There is no rush; I'm doing the clean-up that must be done anyway.
"MathUtils" should be deleted (or made private) from CM, for the
reason
given previously.
"Commons Numbers" can be easily released in the coming weeks (not so
for
CM), and I really don't understand the reluctance to include such
common
resources as an angle normalization routine.
If what you are worried about is that an ideal plane geometry
library
I think I have made it clear what I am worried about.
would probably contain such a class a "PlaneAngle", I agree with
you;
however, adding it now in CM without thoroughly reviewing the
package
(with the input from actual users of that package) is a waste of
time.
[Been there, done that, with the "optim" package...]
As for the module, do we mind a few more bytes?
It leaves room for expansion (not that I intend to do it
personally),
and it avoids that "core" becomes the place where we put every
little
thing that does not belong elsewhere. [If it turns out that
"core"
contains only two classes, a question might be whether those
should
not also belong to their own module with a name that better
reflects
its content.]
It's not the "bytes" it's the overhead. Having a module containing
only
one class is extreme.
What is the overhead?
More html pages on the site?
Lastly, if "Commons Numbers", as several other components, is also
taken
as a companion to the JDK, then having "toRadians()" and
"toDegrees()"
methods defined in "java.lang.Math" makes "PlaneAngle" a natural
fit.
I do not see this argument at all. The JDK java.lang.Math class is
a
collection of static utilities which are loosely related.
Following this
line of organization is a recipe to repeat the problems with CM.
Second,
I
do not think of CM or "Commons Numbers" as companions to the JDK.
The JDK
does not provide enough math-related code for this to be a
companion.
Commons-lang and commons-collections are companions.
Sorry, I don't follow.
Obviously, "Commons Numbers" contains stuff that is not in
"java.lang.Math".
For some functionality, namely "PlaneAngle", "Commons Numbers"
provides an
OO alternative to the static methods in the JDK class, and it
provides a
ready-to-use "normalize()" method that is not in the JDK. [I've used
the
word
"companion" in that sense only. But let's drop the discussion on
the use
of
words, please. What I'm interested in, is that "Commons Numbers"
groups
utilities that stand on their own. That they were formerly in CM is
a non
issue, except that anything that makes CM "lighter" in a Good Thing
(TM).]
I appears to me that we are talking past each other at this point.
Perhaps a more fruitful discussion would be to define what the
boundaries
are for commons-numbers. Perhaps you could propose what your vision
is
since you are dissatisfied with mine.
Quite the contrary, in an ideal world, I'd completely agree with
strictly
limiting the scope of a component.
However, we are in the less-than-ideal world of "Commons" (for good or
bad).
Please recall that I wanted to limit the scope of "Commons RNG", but in
the
absence of consensus about creating yet another component, it has not
been
possible: either I'd put in "sampling" (even though _not_ in scope
according
to my argument), or I'd have had to forego providing this
functionality.
The same goes for all the packages which I've called to be factored out
of
"Commons Math".
Ideally, we'd create one component per functionality. But practically,
the
PMC is against this approach; and the main argument was unrelated to
scope
(more work for release reviews).
Hence, on the one hand, there seems to be a limit on the number of
components
and on the other, there is the need to fix "Commons Math" (in the sense
which
I've also developed extensively elsewhere).
The sole compromise I see currently is to (slightly) loosen the
threshold of
acceptance into "Commons Numbers", creating modules as necessary in
order to
stress the separation of scopes.
A second discussion concerning the minimum size for a module might
also be
called for but that might be best saved for a different thread.
Cf. Matt's comments on this; IIUC his point, the whole range of
practices
exists, from one single file for a whole library, to one file per
function.
Unless I'm deeply mistaken, the evolution of practice is towards the
latter.
So, indeed, size does not matter. :-)
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
