On Thu, Nov 28, 2013 at 12:42 PM, Emmanuel Bourg ebo...@apache.org wrote:
Rationale: each instance variable gets initialized twice, to the same
value. Java initializes each instance variable to its default value (0
or null) before performing any initialization specified in the code. So
in this
On Sun, Nov 24, 2013 at 7:22 AM, Phil Steitz phil.ste...@gmail.com wrote:
Are there any objections to changing the API sigs from foo(double[] values)
to foo(double... values) ?
Yes. I am -0 for adding new methods that take varargs; -1 for
removing the double[] versions.
Phil note that
For background, see https://issues.apache.org/jira/browse/MATH-1053
The issue is what to do when QRDecomposition is used on a tall, skinny
matrix (m rows n cols), and getSolver().getInverse() is called.
Right now a DimensionMismatchException is thrown, which is almost
certainly not intended.
On Sun, Nov 3, 2013 at 4:17 AM, Ted Dunning ted.dunn...@gmail.com wrote:
Does this actually matter after the JIT takes hold? And if the JIT doesn't
care to optimize this away, does it even matter?
Unclear. There aren't hard guarantees about what the JIT does, but
transformations like this
On Sun, Nov 3, 2013 at 1:43 PM, Gilles gil...@harfang.homelinux.org wrote:
A case that occurs often is zero (as double).
I prefer 0d.
(I'm certainly not going to propose to change it, but my personal
preference is 0.0 because it's obviously decimal even to newbies and
can't be confused with a
In Math, is there any appetite for large patches containing many
instances of particular micro-optimizations? Examples:
- Replace:
a[i][j] = a[i][j] + foo;
with:
a[i][j] += foo;
… which is faster/leaner in the byte code by a little bit. It might
make a difference in many nested, tight
until
it's clear we're getting too fine-grained.
I'll do this over time since some changes will affect the same files
or sections of code.
On Sat, Nov 2, 2013 at 3:03 PM, Gilles gil...@harfang.homelinux.org wrote:
On Sat, 2 Nov 2013 14:52:34 +, Sean Owen wrote:
In Math, is there any appetite
In MATH-1045 (https://issues.apache.org/jira/browse/MATH-1045) we have
discussed adding a zero threshold tolerance to EigenDecomposition just
like QRDecomposition has. This involves adding a new constructor with
a new double parameter.
Just one problem: there's already such a constructor:
created by getSolver().
Imho, it would be more logical to chose the singularity threshold when
calling getSolver() for the respective decomposition, that way we could
also add it to the EigenDecomposition class.
Thomas
On Wed, Oct 23, 2013 at 1:23 PM, Sean Owen sro...@gmail.com wrote
one stops early, always.
On Wed, Oct 23, 2013 at 4:50 PM, Ted Dunning ted.dunn...@gmail.com wrote:
On Wed, Oct 23, 2013 at 3:14 PM, Sean Owen sro...@gmail.com wrote:
EigenDecomposition resembles QR in this respect, as far as they are
implemented here. This argues for them to treat arguments
On Sat, Oct 19, 2013 at 5:51 PM, Phil Steitz phil.ste...@gmail.com wrote:
Investigation / tests / documentation much appreciated.
Thanks for looking into this!
OK Phil I'll have another go. I would like to propose three patches
(three JIRAs?)
1. The javadoc updates discussed on this thread,
On Thu, Oct 17, 2013 at 11:05 AM, Gilles gil...@harfang.homelinux.org wrote:
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 buy that -- but my
On Wed, Oct 16, 2013 at 1:13 AM, Phil Steitz phil.ste...@gmail.com wrote:
On 10/15/13 2:51 PM, Sean Owen wrote:
Hello all,
I'd like to propose a few small additions to the Pair class in Common
Math3: a factory method, to avoid redundant generics-related
eclarations, a
toString
On Wed, Oct 16, 2013 at 9:52 AM, Gilles gil...@harfang.homelinux.orgwrote:
I think the Comparator can also replace a
custom one in MathArrays.
Are you sure?
Yes, at least tests pass. There are two anonymous comparator classes there
which compare by key. The new Comparator compares by key
You are right that it adds 1 or 2 more branches per comparison. The new
Comparator would at least be consistent with equals(), though it probably
doesn't matter for correctness in practice.
I am interested in closing this minor issue so I suggest you ignore this
part if you guess that this
On Wed, Oct 16, 2013 at 11:23 PM, Gilles gil...@harfang.homelinux.orgwrote:
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
Hello all,
I'd like to propose a few small additions to the Pair class in Common
Math3: a factory method, to avoid redundant generics-related eclarations, a
toString() method, and a basic Comparator.
It's already pretty well summarized, simple as it is, at
17 matches
Mail list logo
