On Thu, 17 Oct 2013 02:16:52 +0100, Sean Owen wrote:
On Wed, Oct 16, 2013 at 11:23 PM, Gilles
<gil...@harfang.homelinux.org>wrote:
Consequently, the lexicographic comparator will definitely be slower
since
it
will needlessly spend time ordering the values.
Yeah if value's compareTo() is expensive, this could hurt. Here, for
an
Integer value it's going to be a rounding error compared to memory
movement. I think.
I question the correctness of the change in "sortInPlace" (with the
above
argument), and the immediate usefulness _for_ CM (since a user
interested
in a pair functionality should probably use Lang's implementation).
You did not expose your use-cases so I cannot judge whether a user
would
have reasons to prefer CM's implementation.
If you're right that this stretch of code doesn't care about ordering
of
values, then it can't be wrong-er, merely slow-er, to bother ordering
by
value. Right? My point was only that the correctness worry can't be a
reason against this change. (In the abstract, java.util.Comparator
says you
need to compare on values too if equals() does, and we hope this code
never
changes to subtly depend on this correctness, but right now it
doesn't seem
to.)
IMHO, there is no point in arguing about possibilities. I suggested a
way to
have a more factual answer (i.e. with "PerfTestUtils").
"sortInPlace" should not be made any slower only for the sake of using
a
_generally_ correct implementation of "Comparator". The implementation
in
"sortInPlace" is quite correct for the task at hand.
I thought it went without saying that the use case is external
callers. The
single potential internal usage it was just a potential bonus. Is it
beyond
CM's scope to include a little utility class? meh, I hadn't thought
so but
I can see that point of view, and that alone is good enough for me.
It's
just bike-shedding beyond this point.
Well, you don't answer to my questions about usage; how am I supposed
to answer
yours about being, or not, in the scope?
Here the first line of the goals statement of CM:
---CUT---
Commons Math is a library of lightweight, self-contained mathematics
and
statistics components addressing the most common problems not available
in the
Java programming language or Commons Lang.
---CUT---
Then in Commons Lang API docs, I find
http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/Pair.html
Therefore, for an external user of the Pair functionality, everything
is in
CL already.
Stays the issue of whether a user of CM would have to instantiate a
CM's "Pair"
because he needs to call CM's code with such a "Pair", while also
requiring to
use the same object with code where the ordering must be done on values
too.
Hence my question about usage, out of curiosity, but also because an
answer
could be useful in order to enhance the user guide, as we unfortunately
add a
lot of little utilities without upgrading the repository of examples of
how to
use them (in a mathematical context).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
